mboost-dp1
Linux & Rust
Hehe, jeg troede for en stund at LPC 2022 henviste til en NXP ARM chip, der findes LPC 1xxxx 2xxx 3xxx serier osv. jeg har selv arbejdet med en af dem ;)
Det er en spændende udvikling at Rust gør fremskridt mod at blive et fuldgyldigt sprog for Linux kernel og kernel moduler. Også interessant at GCC Rust er "en ting", det havde jeg ikke regnet med.
Det er en spændende udvikling at Rust gør fremskridt mod at blive et fuldgyldigt sprog for Linux kernel og kernel moduler. Også interessant at GCC Rust er "en ting", det havde jeg ikke regnet med.
Virkelig?arne_v (3) skrev:Mere end en implementation øger tilliden til sprogets fremtid.
Synes ikke rigtigt det har været tilfældet for andre sprog
#4
Det vil jeg mene.
Fortran, Cobol, Pascal, C, C++ har alle mange implementeringer.
PL/I var for meget IBM og slog ikke helt igennem.
Ada83 havde mange implementeringer men Ada95 er mest ACT. Ada83 var betydeligt mere lovende end Ada95 (der er også andre grunde til det end ACT dominans, men ACT situationen hjalp ikke).
JavaScript har mange implementeringer.
Java havde oprindeligt mange implementationer. Idag er det mest forskelling builds af OpenJDK, men det var først efter at momentum var nået.
C# har kæmpet meget med "MS only" image. Det var en stor hæmsko for sprogets udbredelse i mange år.
Kotlin kæmper med at være for meget JetBrains.
Swift med for meget Apple.
Eneste sprog med stor success og stort set alle på samme implementation jeg kan komme i tanke om er Python (der er andre implementeringer end standard CPython men de er sjældne).
Det vil jeg mene.
Fortran, Cobol, Pascal, C, C++ har alle mange implementeringer.
PL/I var for meget IBM og slog ikke helt igennem.
Ada83 havde mange implementeringer men Ada95 er mest ACT. Ada83 var betydeligt mere lovende end Ada95 (der er også andre grunde til det end ACT dominans, men ACT situationen hjalp ikke).
JavaScript har mange implementeringer.
Java havde oprindeligt mange implementationer. Idag er det mest forskelling builds af OpenJDK, men det var først efter at momentum var nået.
C# har kæmpet meget med "MS only" image. Det var en stor hæmsko for sprogets udbredelse i mange år.
Kotlin kæmper med at være for meget JetBrains.
Swift med for meget Apple.
Eneste sprog med stor success og stort set alle på samme implementation jeg kan komme i tanke om er Python (der er andre implementeringer end standard CPython men de er sjældne).
Mener du brower implementationer (compilers) eller i sprog implementation (CJS vs. ES6) ? Fordi CJS vs. ES6 er en negativ ting.arne_v (5) skrev:JavaScript har mange implementeringer.
Jeg har svært ved at se OpenJDK som noget der har påvirket Java positivt.arne_v (5) skrev:Java havde oprindeligt mange implementationer. Idag er det mest forskelling builds af OpenJDK, men det var først efter at momentum var nået.
Hvilket jo er en positiv ting, specielt når sproget er i en rivende udvikling.arne_v (5) skrev:Swift med for meget Apple.
For sprog der kun ændre sig minimalt en gang hver 10-20 år (C++, Java), så betyder det ikke så meget, men en alternativ implementation af Swift ville have været et helvede for brugerne af sproget.
Claus Jørgensen (6) skrev:arne_v (5) skrev:
JavaScript har mange implementeringer.
Mener du brower implementationer (compilers) eller i sprog implementation (CJS vs. ES6) ? Fordi CJS vs. ES6 er en negativ ting.
Jeg mener JS engine implementeringer. V8, SpiderMonkey etc..
Claus Jørgensen (6) skrev:arne_v (5) skrev:
Java havde oprindeligt mange implementationer. Idag er det mest forskelling builds af OpenJDK, men det var først efter at momentum var nået.
Jeg har svært ved at se OpenJDK som noget der har påvirket Java positivt.
OpenJDK har:
- opfyldt Jonathan Schwartz's mål med at sikre at Oracle ikke kunne gøre noget grimt med Java efter købet af Sun
- reduceret omkostningerne til vedligehold fordi alle nu bruger samme code base
Min pointe er at Java's udviklingsmodel da Java kom frem er helt anderledes end idag.
Claus Jørgensen (6) skrev:arne_v (5) skrev:
Swift med for meget Apple.
Hvilket jo er en positiv ting, specielt når sproget er i en rivende udvikling.
For sprog der kun ændre sig minimalt en gang hver 10-20 år (C++, Java), så betyder det ikke så meget, men en alternativ implementation af Swift ville have været et helvede for brugerne af sproget.
Tradeoff.
en implementation => mulighed for hurtigere ændringer
flere implementationer => mere tillid til fremtiden og flere brugere
arne_v (7) skrev:Claus Jørgensen (6) skrev:arne_v (5) skrev:
Swift med for meget Apple.
Hvilket jo er en positiv ting, specielt når sproget er i en rivende udvikling.
For sprog der kun ændre sig minimalt en gang hver 10-20 år (C++, Java), så betyder det ikke så meget, men en alternativ implementation af Swift ville have været et helvede for brugerne af sproget.
Tradeoff.
en implementation => mulighed for hurtigere ændringer
flere implementationer => mere tillid til fremtiden og flere brugere
Du er ikke alene med synspunktet.
Der er mange som mener at modellen med 1 standard og flere implementeringer:
1) går for langsomt
2) ender med over-indviklede løsninger (politiske kompromiser i forbindelse med design by comittee)
#6
C++ ændrer sig hver 3. år (11, 14, 17, 20) omend jeg tror at en betydeligt andel C++ kode stadig bygger med 98.
Java ændrer sig reelt også hver 3. år - 8 (2014), 11 (2018), 17 (2021) - ikke LTS versionerne som kommer hver halve år er bare beta udgaver. Traditionelt skynder man sig ikke med at opdatere - sidste år var det vel 50% 8 og 50% 11 - om et par år er det sikkert 50% 11 og 50% 17. :-)
C++ ændrer sig hver 3. år (11, 14, 17, 20) omend jeg tror at en betydeligt andel C++ kode stadig bygger med 98.
Java ændrer sig reelt også hver 3. år - 8 (2014), 11 (2018), 17 (2021) - ikke LTS versionerne som kommer hver halve år er bare beta udgaver. Traditionelt skynder man sig ikke med at opdatere - sidste år var det vel 50% 8 og 50% 11 - om et par år er det sikkert 50% 11 og 50% 17. :-)
Noget jeg aldrig har forståetarne_v (9) skrev:Traditionelt skynder man sig ikke med at opdatere
Vi opdatere til nyeste Swift udgave så snart den kommer ud. F.eks. Swift 5.7 i dag.
#11
Nogle gør. Andre opdatere løbende fordi de VED at det er bedre end at skulle bruge 6 måneder på en BIG BANG opgradering fra v.2 til v.12 engang i årtiet.
Personlig synes jeg at C/C++ udviklernes frygt for at bruge nye compilere er helt helt falsk, og ikke har rødder i fakta.
Nogle gør. Andre opdatere løbende fordi de VED at det er bedre end at skulle bruge 6 måneder på en BIG BANG opgradering fra v.2 til v.12 engang i årtiet.
Personlig synes jeg at C/C++ udviklernes frygt for at bruge nye compilere er helt helt falsk, og ikke har rødder i fakta.
#12
Der er nok lidt "overtro" involveret.
For C++ vil tro at de reelle bekymringer drejer sig om:
- kode der ikke compiler fordi der er en ikke-kompatibel ændring i standarden
- kode der ikke compiler fordi kode ikke er ok men den gamle compiler accepterede den fejlagtigt
- manglende stabil ABI garanti so gør at alle biblioteker også skal bygges med den nye compiler
- koden er dårlig med undefined behavior og compiler opdateringen ændrer denne
Der er nok lidt "overtro" involveret.
For C++ vil tro at de reelle bekymringer drejer sig om:
- kode der ikke compiler fordi der er en ikke-kompatibel ændring i standarden
- kode der ikke compiler fordi kode ikke er ok men den gamle compiler accepterede den fejlagtigt
- manglende stabil ABI garanti so gør at alle biblioteker også skal bygges med den nye compiler
- koden er dårlig med undefined behavior og compiler opdateringen ændrer denne
#13
3/4 af de ting er jo ikke et gyldigt grundlag for at lade være med at opdatere. Det er jo bare inkompetance.
Og ABI stabilitet kan godt lade sig gøre i opdatering af sprog. Men selv når der ikke er ABI stabilitet er det jo ikke et uløseligt problem.
#14
Problemer der kan løses. Ikke rigtig en undskyldning for at lade være, specielt ikke når man tænker over alle de _positive_ ting i nyere version af Java.
3/4 af de ting er jo ikke et gyldigt grundlag for at lade være med at opdatere. Det er jo bare inkompetance.
Og ABI stabilitet kan godt lade sig gøre i opdatering af sprog. Men selv når der ikke er ABI stabilitet er det jo ikke et uløseligt problem.
#14
Problemer der kan løses. Ikke rigtig en undskyldning for at lade være, specielt ikke når man tænker over alle de _positive_ ting i nyere version af Java.
#15
Alt kan løses.
Men det er ikke altid at benefit overstiger cost. Der er nye features men hvor meget hjælper de faktisk.
Resultatet er at hvis man er "heldig" sker opdateringen som en del af en batch med diverse funktionelle ændringer.
Hvis man er "uheldig" sker opdateringen først når den gamle version er på vej mod EOL og bliver en sikkerhedsrisiko.
Du kan sikkert finde andre termer end "heldig" og "uheldig". :-)
Alt kan løses.
Men det er ikke altid at benefit overstiger cost. Der er nye features men hvor meget hjælper de faktisk.
Resultatet er at hvis man er "heldig" sker opdateringen som en del af en batch med diverse funktionelle ændringer.
Hvis man er "uheldig" sker opdateringen først når den gamle version er på vej mod EOL og bliver en sikkerhedsrisiko.
Du kan sikkert finde andre termer end "heldig" og "uheldig". :-)
Men C# og Swift har det altid været værd at opdatere.arne_v (16) skrev:Men det er ikke altid at benefit overstiger cost.
Men at overhovedet tænke på det i cost/benefit, og ikke i "best engineering practice" er meget gammeldags.
Jeg undgår bevist arbejdsgivere der tænker på den måde.
#17
Du skal nok regne med at de fleste virksomheder vil interessere sig for cost/benefit - det drejer sig jo i sidste instans om penge.
Det koster penge at opdatere.
Det koster også penge at vedligeholde kode som er unødvendigt kompleks fordi den ikke bruger nye features i sproget.
Den sidste effekt er formentligt betydeligt mindre end hvad mange udviklere umiddelbart tror - de fleste nye features er måske nok "nice to have" men betyder reelt ikke så meget for vedligehold.
På den anden side er den sidste effekt kumulativ. Omkostningen ved at opdatere er konstant og dermed lineær over tid. Omkostningen ved at have kode i gamle versioner stiger fra år til år og vokser derfor kvadratisk over tid.
Jeg kender folk i comp.os.vms som sidder med business code skrevet tilbage i 80'erne i Macro-32 (assembler!).
Du skal nok regne med at de fleste virksomheder vil interessere sig for cost/benefit - det drejer sig jo i sidste instans om penge.
Det koster penge at opdatere.
Det koster også penge at vedligeholde kode som er unødvendigt kompleks fordi den ikke bruger nye features i sproget.
Den sidste effekt er formentligt betydeligt mindre end hvad mange udviklere umiddelbart tror - de fleste nye features er måske nok "nice to have" men betyder reelt ikke så meget for vedligehold.
På den anden side er den sidste effekt kumulativ. Omkostningen ved at opdatere er konstant og dermed lineær over tid. Omkostningen ved at have kode i gamle versioner stiger fra år til år og vokser derfor kvadratisk over tid.
Jeg kender folk i comp.os.vms som sidder med business code skrevet tilbage i 80'erne i Macro-32 (assembler!).
De virksomheder jeg har arbejdet for, inklusiv Microsoft snakker ikke budget med programmørene. Vi har fuld frihed til at bestemme om vi opdatere sproget eller ej.arne_v (18) skrev:Du skal nok regne med at de fleste virksomheder vil interessere sig for cost/benefit - det drejer sig jo i sidste instans om penge.
Det koster penge at opdatere.
Så igen, du skal arbejde for en meget gammeldaws virksomhed hvis ordet penge er et emne der bliver bragt op i en teknisk diskussion.
Det er måske sejt for dem, men jeg ser det som en ultimativ negativ ting :parne_v (18) skrev:Jeg kender folk i comp.os.vms som sidder med business code skrevet tilbage i 80'erne i Macro-32 (assembler!).
Claus Jørgensen (20) skrev:De virksomheder jeg har arbejdet for, inklusiv Microsoft snakker ikke budget med programmørene. Vi har fuld frihed til at bestemme om vi opdatere sproget eller ej.arne_v (18) skrev:Du skal nok regne med at de fleste virksomheder vil interessere sig for cost/benefit - det drejer sig jo i sidste instans om penge.
Det koster penge at opdatere.
Så igen, du skal arbejde for en meget gammeldaws virksomhed hvis ordet penge er et emne der bliver bragt op i en teknisk diskussion.
Afhænger af om du betragter project planlægning, scope og resource allokering for en teknisk diskussion.
Det er formentligt ikke en diskussion som udviklerne generelt deltager i, men diverse software managers, product managers, projekt ledere, arkitekter og måske tech leads.
Der træffes beslutninger om prioritering hele tiden. Hvilke nye funktionelle features skal tilføjes, hvilke UX forbedringer skal laves, hvilke performance forbedringer skal implementeres, hvilken teknisk gæld skal løses. Skal et team tilføjes flere resourcer fordi produktet er kritisk eller skal nogle overføres til andre teams fordi de er vigtigere.
Jeg har aldrig arbejdet for Microsoft, men jeg har svært ved at forestille mig udviklerne fortælle product managers at deres nye feature som de vurderer som vigtigt for konkurrencedygtigheden må vente et eller flere sprints fordi der skal laves en compiler & runtime opdatering.
Claus Jørgensen (20) skrev:Det er måske sejt for dem, men jeg ser det som en ultimativ negativ ting :parne_v (18) skrev:Jeg kender folk i comp.os.vms som sidder med business code skrevet tilbage i 80'erne i Macro-32 (assembler!).
Det er jeg enig i.
Det var et eksmepel på den kumulative effekt af teknisk gæld når den er værst.
Det er præcist hvad vi gjorde, og hvad vi stadigvæk gør i mit nuværende arbejde.arne_v (21) skrev:Jeg har aldrig arbejdet for Microsoft, men jeg har svært ved at forestille mig udviklerne fortælle product managers at deres nye feature som de vurderer som vigtigt for konkurrencedygtigheden må vente et eller flere sprints fordi der skal laves en compiler & runtime opdatering.
F.eks. opgradering til Xcode 14 i dette her sprint (som sluttede i dag)
MS er også med på Rust vognen:
https://www.theregister.com/2022/09/20/rust_micros...
(og Stroustrup mener ikke overraskende at C++ er godt)
https://www.theregister.com/2022/09/20/rust_micros...
(og Stroustrup mener ikke overraskende at C++ er godt)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund