Google-ping raser: Java og C++ er forældede og for indviklede

Unix-pionéren Rob Pike mener, at det er tid til at gøre op med dominerende programmeringssprog som Java og C++. De er for svære at bruge og ude af trit med nutidens multicore-processorer.

Én af de helt store kanoner inden for Unix-verdenen, Rob Pike, langer nu ud efter den brede masse af professionelle programmeringssprog - ikke mindst Java og C++ - som han mener er alt for komplicerede og ude af trit med nutidens behov, skriver Infoworld.

Rob Pike har blandt andet skrevet The Unix Programming Environment, som er én af bestsellerne inden for Unix-litteraturen.

Han er nu ansat hos Google, hvor han har været én af hoveddrivkræfterne i udviklingen af programmeringssproget Go.

Bredsiden blev skudt af på den netop afholdte open source-konference Oscon.

»Jeg mener, at den slags sprog (Java, C++ og lignende, red.) er for svære at bruge, for subtile og for indviklede,« sagde Rob Pike på konferencen ifølge Infoworld.

Han tilføjede, at kompleksiteten af sprog som Java og C++ blot forværres over tid, efterhånden som de bliver mere udbredte i industrien og kompliceres af et væld af nye funktioner.

Rob Pike fremviste et eksempel med en deklarering af en variabel i en stump kode i C++, hvor variablen strakte sig over næsten en hel linje på skærmbilledet.

»Hvordan kan det være, at vi tillader den slags at blive standarden for, hvordan programmering læres på uddannelserne og bruges i industrien,« lød kommentaren fra Rob Pike ifølge Infoworld.

Ikke overraskende nævnte Rob Pike også Googles eget sprog, Go, som søger at fusionere den hurtige udviklingstid, man kender fra dynamiske og 'lettilgængelige' sprog som Python, med ydelsen fra oversatte og mere komplicerede sprog som C og C++.

**Læs også: **Google mikser dyder fra Python og C++ i nyt programmeringssprog

Selvom bredsiden også var ment som en provokation, fastholdt Rob Pike, at det er nødvendigt at finde løsninger på kompleksiteten og omfanget at de meste gængse programmeringssprog.

Samtidig pegede han også på, at for eksempel Java og C++ er udviklet i en tid, hvor processorer blot havde én kerne.

Dermed er sprogene ikke særligt velegnede til at skrive kode til nutidens multicore-processorer, der stiller programmører overfor nye udfordringer med at skrive programmer, der udnytter parallelismen i den slags processorer.

Hvad mener du selv om programmeringssprog som Java, C++ og C#? Er de blevet for komplicerede i takt med deres udbredelse? Giv dit besyv med i debatten nedenfor.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (50)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Slot

Jeg kan lide alle tre sprog, og skriver programmer og biblioteker i dem, både i skolen og i fritiden. Jeg kan godt lide dem, men jeg er da altid frisk på at se nogle forslag på hvordan fremtiden skal se ud. Jeg synes dog at det er sjovt at man nu vil til at forske i kompleksiteten af programmeringssprog. For mig bliver der dannet et indre billede af at man som sprogforsker om 500 år sidder side om side med andre kommunikationsforskere, og forsker oldtidens programmeringssprog, for at se hvor udtrykkene kommer fra :)

Jeg synes helt klart at Java er det nemmeste af de tre sprog, derefter kommer C# og tilsidst C++. C++ synes jeg er sværest at lære, da man her skal have styr på meget mere. Faktisk en hel toolchain, hvis man da ikke bruger et IDE, som klarer det for en. Bare det gør at man kan få fejl fra flere sider af, som man i starten kan blive trynet meget af.

Lars Tørnes Hansen

Java og C#: Jeg er ca lige god i de 2 sprog.
C++ derimod er noget jeg helst ikke rører ved: Der er lidt for mange undtagelser til at man hurtigt bliver rigtig god.

Jeg må sige at jeg foretrækker de funktionelle programmeringssprog.

Det er især Erlang til fler-trådet programmering (Actor baseret concurrrency, istedet for den type concurrency Dijkstra kom op med (Semafor: http://da.wikipedia.org/wiki/Semafor_%28datalogi%29 , http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD123.html )

Derefter Common Lisp, som kan compile kode der i hastighed ligger et sted imellem C og C++ - hastigheden er naturligvis afhængig af hvor godt man selv koder: http://www.gigamonkeys.com/book/conclusion-whats-next.html -> "Make It Work, Make It Right, Make It Fast"

Jeg bruger gerne funktionelle sprog sammen med C kode, hvis der er noget der bare skal køre rigtig hurtigt.

Christian W. Moesgaard

Jeg skriver faktisk lige i øjeblikket i C++ med OpenGL og SFML bibliotekerne.

Det er et stort kaos. Pointer til pointer ind i namespace rundt omkring et struct som egentlig minder om en class der indeholder addressen så jeg kan kravle op og ned af stolper og finden enden af tråden som filtres ind med renderingstråden og skaber en renderingspipeline til grafikkortet, som først virker korrekt med en serie initialiseringer som egentlig bare er enums tillagt særlig betydning og en GCC compiler som smider "Illegal Operation" i hovedet på mig 9/10 gange jeg prøver at compile.

Ej okay, overdrivelse! :P C++ kan altså godt være et mareridt, det er ikke for nybegynderne.
Men hvorfor så bruge C++ og andre "indviklede" sprog?
Fordi man kan mere, og fordi sproget afvikles hurtigt.
Mere er der ikke i det.

Jacob Nordfalk

Hej Jesper (kender jeg dig, fra fysik?) og Christian

MHT nem/svær: C++ kan gøres ædende svær (templates).

Java kan gøres nem, bare ikke til Android. Det afhænger af meget andet end sproget hvor "nemt noget er". F.eks. udviklingsværktøjer, biblioteker.

Apropos. Der er lige kommet et sprog til Android hvor man peger og klikker - henvendt til gymnasieelever der skal lære deres første programmering.

Se http://appinventor.googlelabs.com/

Jesper H. V. Lauritsen

Hej Jacob!! Send lige en PM. Eller find mig på linkedin (navnet burde være nok...)

Jeg skal forresten hygge mig i weekenden med at lægger Android på en HTC HD2 (original WInMo 6.5). Og så skal jeg da klart lige prøve deres AppInventor. Den ser sjov ud... :o)

En universel sandhed: Sproget er blot værktøjet - vælg det der passer bedst til opgaven!

Mikkel Meyer Andersen

Jacob Nordfalk:
Nu er det jo ikke fordi at Java bliver mere svært af at man anvender det til Android. Der er bare nogle (af og til uforståelige) omveje, man må tage - men det er Androids skyld nærmere end det er Javas efter min mening.

Efter de indledende SDK-frustrationer synes jeg sagtens, at man også på Android kan udnytte OOP's mange forcer. Jeg er i hvert fald super glad for at anvende Java til Android-udvikling (på trods af diverse spøjse ting).

Einar Petersen

Jeg havde i længere tid gået og fiflet med Java som vi benyttede på studiet, men som jeg aldrig rigtigt følte mig hjemme i. Jeg kunne godt se fidusen med OO men savnede lidt af den frihed jeg havde mærket i Basic/PDS/XBasic nogle af de oprindelige sprog jeg stiftede bekendskab med, alt for mange deklartioer af variabler og klammer samt tung syntaks. Så var det der Pyhton, jeg havde læst om sproget men aldrig fået tid til at kigge på det trods stor lyst dertil da det lød som et programmeringssprog der bedre passede til mit temprament. Så en dag faldt jeg tilfældigvis over en række tutorials, hhv. python, wxpython og gamepy, han begynder helt fra download af sproget mm. http://www.youtube.com/watch?v=4Mf0h3HphEA&feature=PlayList&p=EA1FEF17E1... og kører så igennem en række funktionaliteter.

Førnævnte er lavet af en ung fyr der kalder sig thenewboston og ligger på youtube, det er uncut, dvs. det er ikke sminkede tutorials, på få lektioner formår han at få mange af sprogets koncepter ind under hunden på dig, således at du kan komme i gang.

Til den der synes Java er nemt kan jeg kun anbefale Python.

Til dem der synes Java er svært ligeså.

Det er skønt at programmeringssproget selv finder ud af om det nu er en string, en int eller en float man deklarerer.

Jeg synes også at parsingfunktioner vedr. førnævnte og input af data fra tastatur mm. er tusind gange nemmere med Python end f.eks. med Java.

Skulle jeg begynde på Python i dag ville jeg dog overveje Python 3 da man ser ud til at have elimineret en række Unicode problematikker der eksisterede i hvert fald under Windows, som man skal programmere sig ud af i lavere versioner (slap for dem da tingene bare funkede under Linux).

Den unge herre har ydermere også sit eget forum hvor brugere incl. ham selv hjælper noobs som mere erfarne, som han selv siger det, sammen kan vi lave de fedeste programmer.

Han har i øvrigt også lavet en række tutorials i andet regi Java, C++, Adobe After Effects, 3D MAX, C programmering, Dreamweaver, Objective C, PHP, blot for at nævne nogle enkle.

Jeg kan kun give Rob Pike ret i at det er rent vanvid at man selv skal sidde og deklarere alting, når vi burde have computere og IDE's der skulle være i stand til at håndtere den slags for os.

Vores brug af computere skal gøre tingene lettere ikke beværlliggøre og begrænse den kreative udfoldelse eller dagligdagen.

Dette er også noget vi kan se man forsøger at gøre med Google's nye værktøj "for folket" til at lave Android apps med.

Det er skønt at se den slags udvikling som gør IT mere tilgængelig og ser frem til endnu mere på den front.

Til dem der endnu ikke har prøvet Python eller andre sprog som nævnt i artiklen, give it a try.

Om end ikke andet så blot for at snuse til det.

Einar Petersen

Ha ha, kiggede lid på scores og lagde mærke til at den ærede Hr. forfatter godt nok har fået nogle drøje hug.

Det var en frisk måde at lave første indspark på, du fik i hvert fald et smil frem på mine læber.

Alle dem der har givet pil nedad må have mistet deres humoristiske sans her i sommervarmen.

I øvrigt en ganske fin bog, den lurede vi også i imedens jeg gik på studiet.

Skønt at se Danske forfattere med indsigt i emnerne lægge sin viden ud på internettet til fri afbenyttelse, blot synd at nogle fik sig et surt opstød, ah well you can't please them all.

En pil opad til dig for et frisk pust!

Keep up the good work!

Jesper Louis Andersen

Java, C++ og C# er alle for store og komplekse sprog. Det er ikke den måde man skal forbedre et programmeringssprog på.

Han har efter min mening også ret mht. Python, Ruby, Perl, Lua, etc: Dynamisk typning skal holdes i umådelig kort snor, ellers går det helt galt på store projekter.

Hans eget bud, sammen med Ken Thompson og Robert Greisemer, hedder Google Go. Det er et interessant indspark i verdenen af imperative programmeringssprog.

Ud over at have ryddet op i C-syntaksen (tak for det), er der tilføjet closures (tak for det) og anvendt en variant af strukturel subtyping til objekthierakier (tak for det). Det sidste giver dig stort set "duck-typing" i et statisk typet sprog og læner sig nok mere op af Alan Kay's oprindelige ideer mht. OOP. Dertil har de set lyset og tilføjet garbage collection.

En anden feature de har tilføjet er concurrency i form a letvægtsprocesser (kaldet goroutiner) og en message-passing kommunikation baseret på kanaler. Denne concurrency-model drager paralleller til CSP og er på mange måder interessant.

Men der hvor Go efter min mening er gået galt i byen er flere subtile ting: Mange har brokket sig over manglende generics, men det har jeg personligt ikke fundet som et stort problem ved sproget. Derimod ser jeg det som et stort problem at NULL ikke er blevet nakket. NULL er en fejl hvis en pointer per default kan være det. Det skal man bede eksplicit om. Et andet problem er at du pt ikke kan distribuere et go-program over flere forskellige fysiske maskiner som man kan i eksempelvist Erlang. Og det tredje problem er at alle fejl er fatale. Hvis du har 10000 goroutiner og een af dem fejler, så dør hele programmet. Det løste Erlang i midten af halvfemserne og det er en vigtig ting at en mindre fejl i en mindre del af systemet ikke har global effekt.

En anden mindre fejl efter min mening er at goroutiner ikke er dataisolerede fra hinanden. Det er op til programmøren at skille data i heap'en fra hinanden så kun een goroutine piller i data på samme tid. Det er dog ikke svært, hvis bare man følger visse simple regler. Det større problem ved en løsning er derimod at garbage-collectoren skal køre på tværs af alle goroutines over hele heap'en. Erlang benytter en GC per process. Prisen er naturligvis at et message-pass betyder et copy, men det er egentlig et mindre problem (desuden er det veje uden om det copy for visse typer data).

Jesper Louis Andersen

[code=text]
func (pkt *packetFunctions)
readlengthCodedBinary(reader *bufio.Reader)
(num uint64, n int, err os.Error)
[/code]

Jeg synes nu ikke det er svært at læse. Du erklærer en funktion med navn readlengthCodedBinary på typen packetFunctions. Denne funktion tager en bufio.Reader parameter og returnerer en tripel.

Okamel, lettere parafraseret:

[code=ocaml]
module type PACKETFUNCTIONS =
sig
type t
val readlengthCodedBinary : t -> reader ->
(uint64, int, OSErr.t)
end;;
[/code]

Jesper H. V. Lauritsen

Hæ... nu sagde jeg jo ikke det var svært at læse/forstå.

I artiklen står "Rob Pike fremviste et eksempel med en deklarering af en variabel i en stump kode i C++, hvor variablen strakte sig over næsten en hel linje på skærmbilledet."

Givet - jeg kender ikke go. Men det jeg ser i mit eksempel er en funktion der tager et pointer argument, dvs. at værdien der peges på reelt kan ændres, men samtidig returnerer funktionen en værdi. Ad! Måske jeg tager fejl?

Henrik Schmidt

Jeg er meget enig i mange af hans pointer. Især, at design patterns kan løse problemer, der i virkeligheden skyldes, at sproget ikke er udtryksfuldt nok. Desuden har han bestemt ret i, at det er fjollet, at man skal bruge en IDE for at komme udenom fx. Javas "verbosity".

Han nævner bl. a. Scala som en modreaktion, og Scala er bestemt et sexet sprog, men det er ikke simpelt. Scalas typesystem er komplekst, og man skal være på hjemmebane både i objekt-orienterede og funktionelle sprog for at kunne udnytte sprogets muligheder effektivt. Oderskys introducerende bog om sproget er på omkring 700 sider, og det er ikke som at læse en begynderbog i java; man bliver rent faktisk nødt til at koncentrere sig undervejs.

Når det så er sagt, så er et udfordrende sprog ikke nødvendigvis en dårlig ting. Det tvinger* en til at tilgå problemstillinger fra en anden vinkel, hvilket, efter min mening, er en af de bedste måder at udvikle sig på som programmør.

Så i bund og grund er jeg ikke helt sikker på, at hans argument holder. Til gengæld tvivler jeg på, at Scala nogensinde bliver et stort sprog - simpelthen på grund af dets kompleksitet.

*Man kan naturligvis kode Fortran i ethvert sprog.

Jesper Louis Andersen

I artiklen står "Rob Pike fremviste et eksempel med en deklarering af en variabel i en stump kode i C++, hvor variablen strakte sig over næsten en hel linje på skærmbilledet."

Det konkrete problem som Pike fremhæver er den klassiske gentagen af den samme information i en typisk variabeldeklaration. Her er C++ eksemplet han benyttede:

[code=cpp]
foo::Foo *myFoo = new foo::Foo(foo::FOO_INIT)
[/code]

Jeg vil tro at i Java ville eksemplet være:

[code=java]
Foo myFoo = new Foo(FOO_INIT)
[/code]

Desuden bemærker Pike at "Foo" identifieren var meget længere oprindeligt. Go forsøger at løse ovenstående problem ved at lave en simpel form for typerekonstruktion. "new Foo(FOO_INIT)" må nødvendigvis have type Foo, så det kan unlades i Go når variablen erklæres ved anvendelse af ":=" operatoren:

[code=text]
myFoo := new Foo(FOO_INIT)
[/code]

Metoden er relativt simpel. Højresiden er en expression (udtryk) og når det skal typecheckes skal man alligevel regne typen ud. Der er ikke langt fra det punkt og så spare programmøren for at skrive typen eksplicit.

Givet - jeg kender ikke go. Men det jeg ser i mit eksempel er en funktion der tager et pointer argument, dvs. at værdien der peges på reelt kan ændres, men samtidig returnerer funktionen en værdi. Ad! Måske jeg tager fejl?

Både og. I eksemplet du har vist er "pkt" og "reader" ganske rigtigt pointere. "pkt" er det objekt der pt arbejdes på, "reader" en et objekt passed by reference. "pkt" svarer sådan set til "this" i Java i det her tilfælde. Koden for java ville være noget i retning af:

[code=java]
import OS.Error;

public class PacketFunction {
...
private readLengthCodedBinary(Reader reader) {
... // "this" can be referenced here
... // would have been pkt.bar(..) in Go
return new Triple<..,..,new Error(...)>;
}
}
[/code]

Så sproget er ikke meget værre end Java, hvor der fra funktionen kan pilles i "reader" og i "this". Hver gang du sidder med en reference til et objekt i Java er det akkurat det samme som sker. Pointere i Go har iøvrigt den detalje at der ikke kan laves aritmetik på dem, så de virker på mange måder som en reference i Java. Pointeraritmetik og Garbage collection er forholdsvist komplekst :)

Poul-Henning Kamp Blogger

Men der hvor Go efter min mening er gået galt i byen er flere subtile ting:

Værsgo: Der har du forklaringen på hvorfor C++ og Java er blevet de syntaxmonstre de er: Man har fundet den ene subtile ting efter den anden og forsøgt at lappe dem.

Folk der designer sprog gør klogt i at sikre sig at de forstår hvad det var Kurt Gödel mumlede om...

Poul-Henning

Torben Mogensen Blogger

Jeg giver PHK ret: C++ og Java er syntaks- (og semantik-) monstre. I C++'s tilfælde skyldes det til dels, at man startede fra C, som selv har en del syntaktiske særheder og ønskede bagudkompatibilitet. I Javas tilfælde skyldtes det, at man ville lægge sig tæt op ad C++'s syntaks for at gøre det nemmere for C++programmører at skifte til Java. Det var klart en fejl, for dels er C++'s syntaks styg og dels er syntaks det nemmeste at lære i et nyt sprog (hvis den ellers er nogenlunde konsistent). Det blev så ikke bedre af, at der er hældt flere og flere ting i både C++ og Java, som har gjort syntaksen endnu mere styg.

Jeg kan dog ikke lige se, hvad Gödel har med pæn syntaks at gøre. Han kodede al sin syntaks som heltal, så specielt læseligt var det ikke. Hans ufuldstændighedssætning har klart nok relevans for programmering (da dens datalogiske ækvivalens er, at ikke alt kan programmeres). Hans måde at konstruere beviser på minder i øvrigt en del om funktionel programmering, så på den led er der måske noget at hente for sprogdesignere.

Hvis jeg skal nævne sprog med pæn syntaks, så er Scheme, Pascal og SML ikke dårlige. Man kan diskutere læseligheden i Schemes konsistente brug af præfix syntaks med parenteser, men det er nemt at lære, og man er aldrig i tvivl om, hvad, der hører sammen. Pascal er bevidst designet til at kunne parses af en LL(1) parser og beskrevet med syntaksdiagrammer, der gør dette nemt. Derudover er syntaksen konsekvent og giver f.eks. en bedre adskillelse af navne og typer, når man erklærer variable, end f.eks. C. Funktionstyper dog undtaget.

SML følger Pascals enkle og konsistente syntaktiske tradition, men har mere konsekvent adskilt typer og navne i erklæringer. Der er nogle enkelte knaster (f.eks. at man skal bruge typeinformation for at adskille variable og parameterløse konstruktorer i mønstre), men sammenlignet med mange nyere sprog, er det ikke slemt. C++ har f.eks langt mere udbredt afhængihed af typeinformation i sin syntaksanalyse. Semantisk set er SML også langt enklere end f.eks. Java og C++.

Poul-Henning Kamp Blogger

Jeg kan dog ikke lige se, hvad Gödel har med pæn syntaks at gøre.

Det var ikke syntaxens pænhed men sprogets størrelse jeg hentydede til. Hvis man vil fange de "subtile ting" der blev klaget over ovenfor, får man per definition et større sprog.

Gödels relevans er at man aldrig kan fange alle de subtile ting i samme sprog. Denne indsigt bør få sprogdesigneren til at overveje, gerne i god tid, hvornår det bedst kan betale sig at sige fra.

Med hensyn til C -> C++ -> Java fødekæden, er problemet i mine øjne at man har haft for få & små ambitioner.

C++ skulle være en bedre C.

"C with classes" hed det første gang jeg hørte om det.

Java skulle være en bedre C++.

Ingen af de to sprog har nogensinde prøvet at være sig selv.

Taget i betragtning at C er vores universelle assembler sprog, kunne det derfor kun gå galt med den strategi.

Men Torben, jeg synes det er pudsigt at du først, korrekt, påpeger at syntaxen er det mindste problem og derefter hænger dig i netop den detajle ved forskellige sprog.

Jeg er meget mere interesseret i hvad du mener om de forskellige sprogs evne til at kommunikere programmørens intention klart, fejlfrit og effektivt.

Poul-Henning

Yoel Pedersen

PHK - det er sandsynligvis et spørgsmål med et indlysende svar, men vil du til enhver tid anbefale C som programmeringssprog, uanset opgavens art (og her ser jeg bort fra indlysende undtagelser som fx web-programmering i PHP o.l. - jeg tænker i stedet på server-applikationer i Unix-verdenen)?

Når jeg spørger, er det fordi jeg har snust til C, en smule mere til C++ og en del til Java. C virker umiddelbart ufattelig bøvlet at arbejde med, men måske er det kun et spørgsmål om at fatte hvad det går ud på. En ting er, at man nok er nødt til at arbejde i C eller C++ hvis man skal arbejde med hardware-specifik kodning, men hvis man "blot" skal udarbejde velskrevne og effektive serverapplikationer i Unix-verdenen, er C da altid det bedste valg? Kan en dreven C-programmør udviske forskellen i tidsforbrug mellem et program udviklet i et RAD-miljø vs. et program udviklet i C?

Poul-Henning Kamp Blogger

PHK - det er sandsynligvis et spørgsmål med et indlysende svar, men vil du til enhver tid anbefale C som programmeringssprog, uanset opgavens art[...]

Hvilken del af "universel assembler" forstod du ikke ? :-)

Nej, jeg mener at C kun bør bruges til klassiske maskinnære systemprogrammerings opgaver, f.eks hvor data typer kan ændre sig på måder som det ikke er nemt at forklare noget sprog.

Netop derfor mener jeg også at hvis det havde været meningen at C++ skulle være et højniveausprog, burde Bjarne have stoppet efter sin C-with-classes prototype og startet på et helt nyt sprog, istedet for at bolte mere og mere på en syntax der ikke var bygget til formålet.

At Java så fortsatte denne idioti viser bare hvor sygeligt neurotiske vi i IT verdenen er omkring bagud kompatibilitet...

Poul-Henning

PS: Jeg mener også at C kunne forbedres ved at droppe nogle af de idiotisk generaliseringer (sizeof(void*) != sizeof(const void *) f.eks) og tilgengæld tilføje ting vi faktisk har brug for, som f.eks endian-specifikation af interface variabler og den slags.

Jesper Louis Andersen

Jeg er meget mere interesseret i hvad du mener om de forskellige sprogs evne til at kommunikere programmørens intention klart, fejlfrit og effektivt.

Det kommer til dels an på opgaven. Hvis du laver noget maskinnært, så skal sproget have support for dette eller være tilpas fleksibelt til at det bliver nemt at beskrive. Du og jeg ved, at det i det maskinnære er vigtigt med en konstruktion til eksplicit at beskrive datalayout i hukommelsen.

Erlang har for eksempel en bit-stream parser indbygget som lader dig specificere netværksprotokoller effektivt, med angivelse af bits og endianess for hvert element. Du kan parse hele IPv4-headeren på et par linier.

Hvis du derimod laver symbolsk behandling af abstrakte syntaks-træer, så skal sproget have en konstruktion som effektivt lader dig beskrive og manipulere disse. Algebraiske datatyper, som ML og Haskell har, er en oplagt metode til at behandle denne type problemer.

Visse algoritmer kan bedst beskrives som rekursive kald funktionelt. Mens andre er forholdsvist svære at passe ned i det skema og er nemmere at beskrive imperativt. Et sprog som ML er virkeligt stærkt fordi det er imperativt med en meget kraftfuld funktionel del ovenpå. Det giver dig en enorm frihed til at beskrive en algoritme på den mest oplagte vis i et givent tilfælde. effektiv ML bruger imperative konstruktioner hvor det giver mening. Alt andet ville være dumt.

Effektivitet generelt er interessant. Altså, "når du har skrevet programmet, kører det så hurtigt?". Og følgespørgsmålet: "Kører det hurtigt nok?". Man skal opveje denne effektivitet mod udviklingstid, mængden af fejl i programmet og så videre.

Hvis man kigger på "The Great Computer Language Shootout", så kan man få et hurtigt billede af hvad man kan med en syntetisk lille benchmark for forskellige sprog:

http://shootout.alioth.debian.org/u64q/which-programming-languages-are-f...

men man skal passe på: Nogen af de indsendte programmer er optimerede til et niveau hvor du "Koder C i X-Lang" og er oplagt set ikke en eksponent for typiske programmer i sproget. Anil Madhavapeddy skrev MLSSH, en OpenSSH-klon i Ocaml. Den performer, ifølge hans phd,

http://anil.recoil.org/papers/anil-thesis-singlesided.pdf

i en hastighed som er kompetitiv med C. Uden kryptering er MLSSH hurtigere. Med kryptering slået til er det ambitiøst at sætte sig op med OpenSSLs AES-192 bit cipher, men resultatet er ikke helt ringe endda.

Mit eget indspark er at jeg har skrevet det samme program i Haskell og Erlang. På TGCLS ovenfor, der burde det se ud som om at Haskell-implementationen er langt bedre end Erlang. I praksis viser det sig dog at de performer stort set ens og indenfor en faktor 10 af tilsvarende C/C++ programmer. Haskell-implementationen er forholdsvist optimeret, mens Erlang-implementationen er stort set uoptimeret. Jeg forventer derfor at det er forholdsvist nemt at komme indenfor en faktor 3-4 af C/C++ - og det er egentlig "hurtigt nok" for mig. At Haskell ikke er hurtigere tilskriver jeg pt at der spildes mere med Memory-båndbredden i Haskell end der gør i Erlang grundet lazy evaluation. Og det er dyrt på en moderne arkitektur: En beregning på CPU'en er gratis hvis du sidder og venter på at data kommer til den fra cache eller main-memory. Selv cache-hits koster en del efterhånden. Mine performance-counter-målinger ser umiddelbart ud til at bekræfte teorien.

Pointen er, at man bør kigge på "rigtige" programmer i stedet for små legetøjsbenchmarks. Som regel har alle sprog nogle svagheder som først kommer til orde når man prøver at lave noget større i dem. Erlang er f.eks. svagt til CPU-bundne opgaver, hvilket TGCLS viser, men hvis programmet man skriver benytter størstedelen af tiden med at kommunikere, så er det en anden sag: Erlangs VM er noget pænt optimeret C til datakommunikation. Det vil sige at du får oversat dine bit-stream parsere til effektiv kode og du får epoll()/kqueue() gratis. Endvidere får du asynkron IO oven i hatten. Derfor performer IO-bundne programmer temmeligt godt.

Og slutteligt læselighed: Generelt synes jeg at C-kode eller Go-kode er langt mere læseligt end Java eller C++-kode. Jeg synes også det er mere læseligt end Python-kode i mange tilfælde. Ruby og Perl kræver noget tilvænning og det er for lang tid siden jeg har programmeret i nogen af dem til at jeg kan læse det effektivt.

Haskell har lidt det samme problem som Perl: Der er en stor sæk af kombinatorer man skal kende for at man kan læse koden effektivt. Erlang og ML er rimeligt ligetil at læse kode på: Begge sprog er simplere end C forstået på den måde at der er færre keywords og finurligheder. Men du kan lave mere abstrakte ting i de sprog.

Har Go så ramt? Det tror jeg egentlig det har. Dels er det ikke så fjernt fra C++/Java/C#. Det er ikke fjernt fra C. Og det Go jeg har kodet for at lege med det har været legende nemt at skrive. Det føles lidt som at skrive Python, bare med en ordentlig sprogimplementation :) Dertil kommer at det kan beskrive concurrency effektivt. Det betyder ikke nødvendigvis at du får optimal ydelse på flere CPU'er, men det betyder at du kan holde dem i gang og få noget speedup forholdsvist nemt.

Kevin Johansen

Ja, C++ verdenen venter stadig på 1x standarden, så er C++ også med på multikerne-moden...
Men, eh, Java har altså været der siden JSR-133 (fra version 1.5).

Med hensyn til Go vs. whatever...
Det er sådan set meget nemt; du har to kasser, den ene måler 20x20x20 og har nogle mægtig fine lego-klodser med farvet plastik og halvstøbte ditten og datten i sig. Den anden måler 100x100x100 og har kun 1-2x2-4 klodser i...50 farver. Med den første kan du bygge fine, flotte rumskibe på ingen tid. Men der kommer altid den dag hvor du vil bygge en star destroyer. Og så må du over i den store kasse! :P

Et sprog (C++) der opdaterer standarden en gang hver 10+. år kan vel næppe siges at være udsat for lappeløsninger og fixes af "subtile" fejl.

Jeg siger ikke at Java, C++ eller C er det eneste rigtige, eller at Go eller C# eller F# eller [whatever] er det. Det gælder jo om at finde værktøjet til opgaven.
Apropo, så vidt jeg kan se så er der ikke noget ved Go der som sådan gør concurrency bedre (jo end C++, men concurrency findes ikke i C++). Jeg kan ikke se hvordan du undgår, uden memory barriers, at CPU'en/erne laver sine egne optimeringer?

Poul-Henning Kamp Blogger

C++ verdenen venter stadig på 1x standarden, så er C++ også med på multikerne-moden...
[...]
Et sprog (C++) der opdaterer standarden en gang hver 10+. år kan vel næppe siges at være udsat for lappeløsninger og fixes af "subtile" fejl.

Det lyder temmelig FanBoi agtigt.

Man kan fint programmere MP i C++, det har man altid kunnet gøre og at standardiseringsprocessen har trækkraft som en Lada der mangler 3 tændrør siger absolut intet om kvaliteten af hvad den producerer.

Tværtimod mener mange.

Poul-Henning

Henrik Schmidt

Poul-Henning:

Netop derfor mener jeg også at hvis det havde været meningen at C++ skulle være et højniveausprog, burde Bjarne have stoppet efter sin C-with-classes prototype og startet på et helt nyt sprog, istedet for at bolte mere og mere på en syntax der ikke var bygget til formålet.

At Java så fortsatte denne idioti viser bare hvor sygeligt neurotiske vi i IT verdenen er omkring bagud kompatibilitet...

Kan du ikke komme med et (eller flere) konkrete eksempler på, hvor syntaksen kommer i vejen? Jeg synes faktisk den er rimelig naturlig.

Kim Madsen

Selv om jeg gerne så eet sprog som var universelt anvendeligt og det simpleste at bruge i alle sammenhænge, så er det efter min mening et formentlig uløseligt paradoks.

Der er to retninger, for et universelt anvendeligt sprog:

  • Der vælges en lavere fællesnævner, og manglerne udbedres ved eksterne funktions biblioteker.
  • Der vælges at bygge funktionalitet ind i sproget, som forsøger at dække de forskellige behov der er på forskellige platforme og tiers.

C er et ekempel på den første type universelle sprog, og C++ og vel især Java et eksempel på det andet.

C har efter min mening klart sin berettigelse, til opgaver hvor man ellers ville have brugt assembler (kerne udvikling, driver udvikling etc.) hvor hver CPU cycle tæller, og hvor man har behov for at vide eksakt hvad der genereres af kode ud fra en given stump source.

Men til GUI orienteret RAD udvikling er hverken C, C++ eller Java særligt anvendelige, da de benytter yderst komplekse biblioteker for at løse opgaven og sprogene ikke har indbyggede konstruktioner der giver den bedste integration med det visuelle miljø (designer etc).
I den verden er Delphi (Pascal baseret) klart den nemmeste efter min mening. XAML (.Net) og MXML (Adobe Flex/Flash) beskrivelser er også stærke i den sammenhæng, netop fordi der i sprogene (C#, ActionScript) er indbygget syntax for nem integration med beskrivelserne.

Et andet eksempel er Matlab. Det er ikke kun et udviklinsmiljø, men også et programmerings sprog. Og det exellere i at give en matematisk tilgang til kodning. Altså arbejde med matricer, vektorer, komplekse tal og input til og plot af resultater fra disse, er integreret i sproget.

Altså er det efter min mening nonsens at snakke om et universelt sprog.

Istedet burde man efter min mening have en sprog syntax som tillader andre sprog at blive integreret ind i sourcen.

F.eks. hvis man har et stykke source, hvor dele af sourcen bedst lader sig beskrive i C, men andre dele bedre lader sig beskrive i Matlab eller Lisp, så burde man kunne bruge den notation der er nemmest læselig og mest effektiv til opgaven.

Det stiller selvfølgelig krav til compileren i den forstand at den ikke kun skal kunne compilere et sprog, men mange forskellige sprog. Dette kunne gøres ved plugins el. lign.
Og det stiller selvfølgelig også krav til udvikleren at denne forstår de forskellige sprogs fordele og ulemper, og bruger dem fornuftigt.

med venlig hilsen

Kim Madsen
kbm@kbmitexperts.dk

Poul-Henning Kamp Blogger

Kan du ikke komme med et (eller flere) konkrete eksempler på, hvor syntaksen kommer i vejen? Jeg synes faktisk den er rimelig naturlig.

Jeg ved dårligt hvor jeg skal begynde og slutte...

Du kan starte med at man overtog C's lidt specielle operatorsæt (og disses præcedens)

Hvad skal C++ med bit-shift som '<<' ? Burde der ikke i stedet have været en basetype der var et rigtig bitmap ?

Burde x ? y : x joken[1] ikke være droppet ? Eller i det mindste have været erstattet af rigtige Lambda-udtryk ?

Burde C preprocessoren ikke have været droppet totalt med det samme, eller alternativt og smartere: Erstattet af en kompetent macro/meta facilitet ?

Det havde samtidig elimineret den fuldstændigt ulæselige template syntax, der kun ser sådan ud "fordi vi løb tør for underlige tegn i ASCII tabellen".

Hele stuntet med "by reference" argumenter burde enten have været droppet, eller have erstattet pointere, at have begge dele er lodret tåbeligt.

Ligeledes er C's ASCIIZ streng-representation stik modsat alt andet i C++, dertil utroligt lavniveau og fejlskabende i forhold til C++'s nutidige fokus.

Årsagen er at Bjarne "bare prøvede at forbedre C lidt" han prøvede ikke at skrive et ny sprog til en opgaver der krævede højere niveau end C.

Men i mangel af andre sådanne sprog, blev C++ omkring 1990 udråbt til frelseren der skulle udrense COBOL og PL/1 fra de store firmaers EDB afdelinger. Hurtigt derefter blev C++ ISO standardiseret og kvalt i baglængs compatibilitet og skyttegravskrige imellem compilerproducenterne, længe inden sproget var færdigt[2].

At Java prøvede at blive en bedre C++ end C++ var, ved at lappe nogle af disse ting igennem klasse-hierakiet er nærmest pinligt...

At langt de fleste idag finder at $DERES_SPROG er tæt på perfekt, eller som du skriver "rimelig naturligt", skyldes oftest at de slet ikke har erfaring med sprog nok til at vide at ting kan gøres bedre og anderledes.

Der er gode grunde til at COBOL, FORTRAN, PL/1 og ikke mindst BASIC og C stadig er her: Der er ting de er rigtig gode til.

Andre sprog, ALGOL, PASCAL og delvist ADA, har ikke tilbudt nok til at de har været umagen værd.

Poul-Henning

[1] x?y:z er kun i C fordi nogen væddede om der fandtes en valid 3-argument operator, eller om alle "fornuftige" operatorer naturligt havde to argumenter...

[2] Hele name-mangling tingen er et grotesk workaround fordi man ikke gad/turde/ville/fandt det morsomt at udvide ELF/COFF/AOUT formaterne med typeinformationer, en indsats der ville kunne have givet pote i alle sprog...

Henrik Schmidt

Tak for et detaljerigt svar. Jeg har stort set ingen erfaring med C++, så jeg skulle nok have skrevet eksplicit, at det var Java, jeg spurgte til.

Poul-Henning:

Du kan starte med at man overtog C's lidt specielle operatorsæt (og disses præcedens)

Her må jeg melde pas. Jeg ved ikke, hvad man skulle have lavet dem om til.

Hvad skal C++ med bit-shift som '<<' ? Burde der ikke i stedet have været en basetype der var et rigtig bitmap ?

Jeg tror, at jeg har brugt den to gange (hvor den var rar at have), men jeg ser det ikke som et alvorligt problem i sproget.

Burde x ? y : x joken[1] ikke være droppet ? Eller i det mindste have været erstattet af rigtige Lambda-udtryk ?

Jeg bruger den ofte, og vil meget nødig se den forsvinde. Jeg vil gerne have lambdaudtryk, men det er jo ikke et eksempel på noget tåbeligt, man har arvet fra C.

Burde C preprocessoren ikke have været droppet totalt med det samme, eller alternativt og smartere: Erstattet af en kompetent macro/meta facilitet ?

Droppet i Java,

Det havde samtidig elimineret den fuldstændigt ulæselige template syntax, der kun ser sådan ud "fordi vi løb tør for underlige tegn i ASCII tabellen".

Droppet i Java.

Hele stuntet med "by reference" argumenter burde enten have været droppet, eller have erstattet pointere, at have begge dele er lodret tåbeligt.

Pointere droppet i Java.

Ligeledes er C's ASCIIZ streng-representation stik modsat alt andet i C++, dertil utroligt lavniveau og fejlskabende i forhold til C++'s nutidige fokus.

Droppet i Java.

At Java prøvede at blive en bedre C++ end C++ var, ved at lappe nogle af disse ting igennem klasse-hierakiet er nærmest pinligt...

Den forstod jeg ikke. De fleste ting du nævner er helt fjernet.

At langt de fleste idag finder at $DERES_SPROG er tæt på perfekt, eller som du skriver "rimelig naturligt", skyldes oftest at de slet ikke har erfaring med sprog nok til at vide at ting kan gøres bedre og anderledes.

Enig. Jeg erkender helt klart, at jeg muligvis er indoktrineret, da Java var det første OO sprog, jeg lærte. Jeg synes dog stadig, at Java har en rimelig naturlig syntaks, også sammenlignet med andre OO sprog. Ruby ligner meget, Objective C er ikke en forbedring, og JavaScript er bare generelt mystisk.

Guderne skal vide, at man ikke kommer til at elske Java ved at arbejde med det, men efter min mening er lige netop syntaksen nogenlunde til at gå til.

Torben Mogensen Blogger

Kan du ikke komme med et (eller flere) konkrete eksempler på, hvor syntaksen kommer i vejen? Jeg synes faktisk den er rimelig naturlig.

Ligesom PHK, så ved jeg dårligt, hvor jeg skal begynde. Men i stedet for at se på detaljer, hvor syntaksen er kluntet, vil jeg i stedet påpege, at der ikke er to C++ oversættere, der parser syntaksen ens. Syntaksen er ekstremt tvetydig og kontekstfølsom, og selv om standarden har forsøgt at opstille uformelle regler for, hvornår man skal parse på den ene eller den anden måde, er reglerne i sig selv tvetydige og ukomplette, så der er uenighed mellem oversætterproducenter om, hvad der skal gøres.

Specielt i forbindelse med templatekonstruktioner, er syntaksen meget tvetydig. F.eks. kan a<b>(c) enten betyde en instantiering af en template a med templateargumentet b og derefter anvendt på argumentet c eller det kan være en sammenligning mellem af og b, som giver en boolsk værdi, som sammenlignes med c.

Man kan argumentere, at syntaks ikke er vigtig, men der er grænser. Hvis der ikke er enighed om, hvordan noget skal læses, eller hvis kontekstafhængigheder betyder, at man ikke kan læse en stump kode uden at kende en enorm kontekst, så er det slemt.

Det er også slemt, hvis sproget tvinger dig til at gentage den samme information flere gange på subtilt forskellige måder. Specielt erklæringer i C++ løber ofte ind i den slags problemer.

Henrik Schmidt

Jesper:

Jeg kan kun anbefale dig at studere objektmodellen i Javascript. Den er anderledes end den der er at finde i Java eller C++, men den er bestemt ikke en dårlig ide.

Nu var det mere syntaksen jeg hentydede til. Implicitte semikolonner? Yikes.

Men jeg ved godt, at det findes et pænt lille sprog inde i det rod, som JavaScript er. Med andre ord har jeg læste "JavaScript: The Good Parts". :)

Provokation: Prøv at kode Java uden et IDE (NetBeans, intelliJ, Eclipse,...) i en uge eller to. Brug gerne Notepad. Prøv så at gøre det samme med Go, Ruby, Python, OcamML, Javascript,...

Javas syntaks stinker langt væk af "Enterprise".

Jeg medgiver gerne (og har allerede gjort det i denne tråd), at syntaksen er "verbose", men det skyldes jo også manglen på sukker. Alt andet lige, gør det syntaksen simplere (men sproget mere træls at kode i).

Det mest trælse ved Java er IMHO ikke syntaksen (selvom den er træls), men Suns ekstreme konservatisme og fokusering på bagudkompatibilitet. Nye features i sproget skal være kompatible med det nuværende features i en sådan grad, at man laver mere eller mindre mystiske workarounds i stedet for at lave det rigtigt.

Autoboxing bliver brugt i stedet for helt at fjerne primitive typer. Man bruger type erasure i stedet for at fixe VM'en så den kan håndtere generified typer etc. Det skyldes dog ikke arven fra C, men Suns politik i stedet, og Oracle bliver nok ikke meget bedre.

Lasse Lindgård

Prøv som et eksperiment at kode et af dine java programmer om til scala syntaks, hvor du stort set "koder java i scala".

Selv der er der meget vundet. Nogen skriver at koden bliver halveret eller mere, men det kommer nok an på hvad der er for noget kode.

En overset pointe ved scala er at man sådan set bare kan gå i gang med at kode som man plejer (i java)

At der så er nye idiomer og muligheder til rådighed, gør jo ikke noget. Det kan man lære hen ad vejen. Selvfølgeligt at det godt at have læst Odersky's glimrende bog, så man ved hvilke muligheder der findes.

Dem der siger at scala er for komplekst glemmer at de ting som sproget kan der vitterligt er svært at forstå ofte er noget som kræver klodsede frameworks eller patterns at udtrykke i java.

Java er også blevet ganske komplekst, når man skal mestre hele stakken af frameworks og patterns oven i hatten. Scala giver mulighed for at slippe af med lidt af det igen.

Bare lær de 20% af scala som man skal bruge 90% af tiden og glem at mestre resten til senere. Nu bruger jeg ikke scala professionelt endnu, men jeg regner da med at bruge årevis, før jeg finder grund til at bruge alle hjørner af sproget.

Lasse Lindgård

Hvad gør Go så godt i forhold til D?

http://www.digitalmars.com/d/2.0/faq.html

D er også et statisk compileret sprog med garbage collection og simplere syntax end C++.
Og ligesom Go kan D kun interface ordenligt med C (ikke C++), hvorfor at man vel nok kan bruge det til systemprogrammering, men kun i det omfang at man ikke bygger ovenpå noget eksisterende.

F.eks. går jeg ud fra at man ikke uden større sværdslag kan skrive en udvidelse til Linux kernen i hverken Go eller D.

Lars Tørnes Hansen

@Kevin Johansen, 26. juli 2010 01:32

Jeg kan ikke se hvordan du undgår, uden memory barriers, at CPU'en/erne laver sine egne optimeringer?

Actor baseret concurrency med:

*: asynkrone meddelelser,
*: ingen shared memory,
*: modtager af meddelse har en mailbox, hvortil meddelsen bliver leveret i,
* letvægtstråde (a la tidlig Java implementation af tråde)
*: preemtive multitasking af letvægtstråde

får du noget der virker bedre end semaforer.

Erlang - et funktionelt sprog implementerer actor concurrency, som blandt andet gør det muligt at have 10.000 vis af letvægtstråde.

Kig her hvor Apache webserveren dør ved omkring 4000 tråde, hvorimod Yaws (en Erlang webserver) fortætter derudaf op til 80.000+ tråde (på sammme maskine):
http://www.sics.se/~joe/apachevsyaws.html

Jens Madsen

Actor baseret concurrency med:

*: asynkrone meddelelser,
*: ingen shared memory,
*: modtager af meddelse har en mailbox, hvortil meddelsen bliver leveret i,
* letvægtstråde (a la tidlig Java implementation af tråde)
*: preemtive multitasking af letvægtstråde

får du noget der virker bedre end semaforer.

Jeg kan tilføje, at actor based concurrency også er deterministisk.

Til en vis grad, kan man automatisk oversætte mellem sekventielle beskrivelser, og actor based concurrency. Det betyder, at en sekventiel beskrivelse, til en vis grad kan paralleliseres, og at en parallel beskrivelse gøres sekventiel. Et af udfordringerne, er at gøre den parallele beskrivelse sekventiel, da vi altid kun har et begrænset antal processorer. Det er så vigtigt, at kunne udføre de rette processer. Dette valg, kan tage hensyn til forsinkelser, prioriteter, hvor vigtigt en opgave er at få løst, for at f.eks. kunne øge paralleliteten. Prøv at forestille dig, at du laver en almindelig sekventiel beskrivelse, og beskriver hvor stor forsinkelsen må være mellem input og output - her har man metoder, så prioriteringen og rækkefølgen af udførelsen, automatisk tilrettelægges, således at svartiderne opfyldes, hvis det er muligt at kunne opnå. Det er også muligt, at opprioritere eller nedprioritere kode, enten efter erfarring, eller efter brugerens opførsel. Tænk på et f.eks. sekventielt program, der udregner en række felter i et regneark, som tager tid - du kan så ændre på prioriteten af udregningerne, ved at flytte musen, og holde den over et felt. Går man en side frem, så det der skal skrives ud på forrige side slettes, så "spørges" ikke mere efter disse informationer som skulle skrives ud, og beregnerne kan "slettes tilbage", så de ikke tager tid.

Desvære, er der visse typer opgaver, såsom fælles adgang til et register, der ikke kan løses med actor modellen. Her bliver man nød til at bruge de sædvanlige låsningsmetoder, som kendes fra parallelprogrammering. Der er dog kun ganske få af disse opgaver, og det vil normalt kun være opgaver, hvor flere personer samtidigt søger adgang til et register. Hvis det sker på samme computer, eller er computerstyret adgang, kan man løse problemet, ved at deffinere en rækkefølge som adgangen sker i, og så er intet problem - samtidigt er resultatet deterministisk. Problemet eksisterer kun, når at resultatet er ikke deterministisk, f.eks. afhænger af to eksterne brugere, hvor resultatet afhænger af den rækkefølge, de indtaster data i et register.

John Vedsegaard

Programmering er håbløst forældet.

Godt nok findes der masser af smarte "træk og slip" objekter til de forskellige sprog, men næsten al programmering burde kunne laves på den måde.

Mange af de eksisterende objekter er organiseret så dårligt, at hvis man indlejrer dem i sit system, vil det blive så uoverskueligt at det er nemmere at lave det hele fra bunden selv.

Jeg bruger selv Borland Developer Studio, med nogle år på bagen, det er heller ikke for godt, slet ikke hvis man tilføjer udvidelser, omvendt er de medfølgende udvidelser ikke meget værd. Det eneste smarte er at man kan blande flere forskellige sprog sammen i samme compiler.

Programmering burde være så simpelt, at næsten alt kan laves uden egentligt kendskab til programmering. På mange måder er udviklingsværktøjer til internet meget nemmere at bruge, selv om de heller ikke er perfekte til deres formål, egentlige compilere burde være lige så nemme, selvfølgelig med samme mulighed for at ændre i sourcekoden selv.

Lasse Reinholt

Jeg mener det er en totalt idiotisk ide, og kender heller ikke til en eneste compiler der benytter sig af det...

Med IAR kan du vælge pointerstørrelse for hver variabel individuelt med __data16, __data20, osv.

Det er jo for 8-bit microcontrollere med meget lidt hukommelse. For dig er det sikkert ikke en god ide, men det er jo nok uundværligt for mange andre :)

Edit: kan lige henvise til http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf - deres 8-bit AVR understøtter 8, 16 og 24-bit adressering på samme tid (altså uden mode switch).

Jeg er ikke MC udvikler og har kun snuset til det (i Labitat), men jeg ved, at sizeof(const void*) > sizeof(void *) er meget almindeligt.

Hvis du stadig vil kalde det idiotisk, så må du altså komme med en alternativ måde at spare plads på.

Poul-Henning Kamp Blogger

Hvis du stadig vil kalde det idiotisk, så må du altså komme med en alternativ måde at spare plads på.

const pointere handler ikke om at spare plads, men om at fortælle compileren om den behøver bekymre sig for forandringer i indholdet og brokke sig hvis man ændre ting man selv har sagt er uforanderlige i en given kontext.

Størrelsen på pointere burde være en attribut på den enkelte pointer, under hensyntagen til compiler/HW og compilere bør brokke sig hvis der sker ulovlig pointer-arithmetik.

(Vi burde også have base-pointere i C, til arbejde på shared memory, shared libraries osv, men det er en helt anden historie)

Poul-Henning

Lasse Reinholt

const pointere handler ikke om at spare plads, men om at fortælle compileren om den behøver bekymre sig for forandringer i indholdet og brokke sig hvis man ændre ting man selv har sagt er uforanderlige i en given kontext.

Ja, netop. Lad os antage, at vi har en AVR med 256 byte RAM som vi adresserer via 8 bit-registre til ting, som ikke er const.

Den har også 64 K ROM, som vi adresserer med 2*8-bit registre. Fordi det er ROM, ønsker vi lidt af den skrabede semantiske sikkerhed, som C har at tilbyde, og gør variablerne const. Altså opnår vi situationen

sizeof(void *) == 1
sizeof(const void *) == 2

Du skriver nu om compiler warnings ved pointeraritmetik. Jeg kan ikke se, hvad det har med sagen at gøre. At en compiler giver warnings gør det ikke muligt at lade sizeof(const void *) == sizeof(void *) i ovenstående eksempel. Ikke forstået.

1) Hvad er det helt nøjagtigt, du mener er idiotisk ved sizeof(const void *) > sizeof(void *) i ovenstående situation?

2) At kalde noget idiotisk medfører automatisk et krav om en alternativ løsning. Hvad er din alternative løsning?

Poul-Henning Kamp Blogger

Jeg mener at det er idiotisk at binde størrelsen af typen til pointerens qualifiers.

Som jeg skrev ovenfor, burde vi have base-pointere, således at du kunne skrive:

const char crc8[256] = { .... };

const char *crc8 __base(crc8) __size(1);

Således at denne pointer kun behøver at være 8 bit bred, selvom der er 64k ROM.

Compileren har rigelig information til at generere den rigtige kode.

Bredden af en pointer afhænger af hvor meget den skal kunne nå, ikke af dens type.

Poul-Henning

Lasse Reinholt

Som jeg skrev ovenfor, burde vi have base-pointere, således at du kunne skrive:

const char crc8[256] = { .... };

const char *crc8 __base(crc8) __size(1);

Således at denne pointer kun behøver at være 8 bit bred, selvom der er 64k ROM.

Jamen sådan fungerer det netop, bare med en lidt anden syntaks, hvor man erklærer et kode- eller datasegment (det, du kalder base), og pointeren bliver et offset ind i segmentet.

Men nogle segmenter er små og kræver kun 8 bit pointere, mens andre er større og kræver 16 eller 24 bits (typisk const ROM). Som du selv skriver, så afhænger bredden af en pointer af, hvor meget den skal kunne nå.

Som jeg læser dit forslag, ønsker du at gøre alle pointerne identiske ved at reducere dem alle til 8-bit? Du skriver jo direkte "Således at denne pointer kun behøver at være 8 bit bred, selvom der er 64k ROM". Eller har jeg misforstået det?

Udover, at compileren vil bloate maskinkoden, fordi AVR ikke er designet sådan i hardware (igen, den er designet til segmentering med både 8-, 16 og 24- bit adresseregistre), så vil det også sparke os tilbage til samme adresseringshelvede, vi havde i 16-bit real mode på x86, og som flat memory løste.

Log ind eller Opret konto for at kommentere