mboost-dp1
low level programmering- den snart tabte kunst?
Hvis man har læst "The Story of Mel" vil man indse at de skills der nævnes i artiklen er high level skills. Jeg kan desværre ikke finde den originale posting med "The Story of Mel", men der er tusindvis af reposts.
Mange af de områder Andy nævner er i øvrigt stadig meget relevante.
Mange af de områder Andy nævner er i øvrigt stadig meget relevante.
Jeg forstår dog slet ikke, hvorfor bit shifting er på listen. Det bliver da også flittigt brugt i sprog af højere nivo.
Og enhver bygningsingeniør og arkitekt burde lære hvordan man murer, tømre og taglægger en bygning. Og enhver mekaniker burde lære hvordan man designer en elektrisk motor. Og og og og....arne_v (5) skrev:Enhver programmør burde lære en assembler dialekt og lidt C - også selv det bliver Java, C# og PHP på arbejdsmarkedet.
Fjolleri. En webudvikler har ikke brug for at kunne assembler og C, og så er den ikke længere.
Low-level programmering er en ligeså "lost art" som COBOL. Dem som har brug for at arbejde med det, lærer det. Og dem som ikke har, lærer noget andet de har brug for i stedet.
Det er typisk nostalgiste
Windcape (8) skrev:Fjolleri. En webudvikler har ikke brug for at kunne assembler og C, og så er den ikke længere.
Windcape (8) skrev:Low-level programmering er en ligeså "lost art" som COBOL. Dem som har brug for at arbejde med det, lærer det. Og dem som ikke har, lærer noget andet de har brug for i stedet.
Hvis man er ligeglad med om programmer altid virker og hvorvidt de performer godt, så kan man sagtend undvære forståelsen af hvad der sker under motor hjelmen.
Men ellers er det nødvendigt at have en grundliggende forståelse for hvordan nogle ting virker.
Windcape (8) skrev:Og enhver bygningsingeniør og arkitekt burde lære hvordan man murer, tømre og taglægger en bygning.
Det er faktisk ikke ualmindeligt for bygningsingeniører at have en håndværksmæssig baggrund.
Det er dog næppe helt så nødvendigt som low level vide for programmører.
Fordi almen viden om mursten, træ og tag er betydeligt mere udbredt end viden om floating point, cache, on wire formats, on disk formats etc..
Performance har sjældent noget som helst at gøre med assembly eller hvad der ligner.arne_v (9) skrev:Hvis man er ligeglad med om programmer altid virker og hvorvidt de performer godt, så kan man sagtend undvære forståelsen af hvad der sker under motor hjelmen.
Som f.eks. SQL Query Execution Plans. Ikke hvordan man laver bitshifting!arne_v (9) skrev:Men ellers er det nødvendigt at have en grundliggende forståelse for hvordan nogle ting virker.
Windcape (8) skrev:Og enhver bygningsingeniør og arkitekt burde lære hvordan man murer, tømre og taglægger en bygning.
Det er sjovt at du siger det - bygningsingeniører på SDU-TEK skal enten have et svendebrev eller igennem et sommerkursus hvor de lærer at opføre bygninger. På sommerkurset skal de godt nok kun opføre skurvogne på 4m x 4m (ca.) og med fladt tag, men de skal vide hvordan man bygger en bygning.
arne_v (5) skrev:#1
Jeg er meget enig i hans betragtninger.
Uanset hvor high level et sprog man bruger, så er en forståelse for hvad der faktisk sker vigtig.
Enhver programmør burde lære en assembler dialekt og lidt C - også selv det bliver Java, C# og PHP på arbejdsmarkedet.
Er faktisk rigtigt glad for jeg har fået lov til at rode både med C, C#, Java, F# og lidt micro-C og lidt byte kode på min uddannelse. En NullPointerException giver ligesom mere mening, nu man rent faktisk ved, hvad en pointer er ;)
Windcape (8) skrev:[...]
Fjolleri. En webudvikler har ikke brug for at kunne assembler og C, og så er den ikke længere.
Det er typisk nostalgistehippiermennesker som mener at man skal lære alt muligt lowlevel man aldrig har brug for.
Hvis nu alle Flash udviklere vidste lidt om andet end deres åh så fantastiske actionscript og gui programmering, så ville mange af de flash sider man ser idag, rent faktisk køre bedre. Man skal nemlig rydde op efter sig selv i Flash - det er der bare ikke ret mange der ved. Jeg fik det i hvert fald ikke at vide på det Flash programmeringskursus jeg havde.
Så, at man kun bør vide noget om det man lige står med i hænderne er endnu en gang bullshit af proportioner. Man behøver ikke nødvendigvis at være ekspert inden for C programmering, men det hjælper fandme på forståelsen i highlevel sprog, hvis man ved en smule om, hvad der sker inde bagved.
Du var garanteret ét af de børn i skolen, der tudede fordi du skulle lære andet end det du gad at lære... for det er ikke vigtigt at vide noget om sin kulturarv fordi man alligevel ikke skal bruge det til noget.
Kom igen...
Det handler jo om sprog/teknologikendskab, ikke om C eller assembler.Darwind (13) skrev:Man skal nemlig rydde op efter sig selv i Flash - det er der bare ikke ret mange der ved.
Derudover så har Flash da haft mark&sweep siden ActionScript 3, så din pointe virker noget outdated!
Det underlige er faktisk at det er Java som har valgt at navngive den sådan. I C# hedder det en NullReferenceException, da der jo er snak om en CLR reference, og ikke en (nødvendigvis) en pointer!Darwind (13) skrev:En NullPointerException giver ligesom mere mening, nu man rent faktisk ved, hvad en pointer er ;)
Må desværre skuffe dig. Jeg er klassisk dannet, og var en af dem som spurte efter flere udfordringer, fordi at pensum var for nemt.Darwind (13) skrev:Du var garanteret ét af de børn i skolen, der tudede fordi du skulle lære andet end det du gad at lære... for det er ikke vigtigt at vide noget om sin kulturarv fordi man alligevel ikke skal bruge det til noget.
Kom igen...
Meningen med at lære historie er så vi kan undgå at gentage den. Med jeres argument omkring C og assembler, så burde vi sende ungerne ud i en skov for at jage med spyd, og tænde bål med flintesten.
Men der vil jo altid være nostalgiske tosser som mener at alting i gamle dage var så meget bedre. Og de få unge som hopper på vognen med de gamle tosser.
Windcape (14) skrev:Det handler jo om sprog/teknologikendskab, ikke om C eller assembler.
Derudover så har Flash da haft mark&sweep siden ActionScript 3, så din pointe virker noget outdated!
Det handler jo netop om at forstå de sprog, vores highlevel sprog bygger på. Selvom der er gc i AS3, så er det nu meget rart at vide, hvordan du undgår memory leaks, som din garbage collector ikke kan tage hånd om.
Derfor er det også meget rart at vide, hvorfor et memory leak opstår (ved fx at lave en reference fra et objekt til sig selv...).
Windcape (14) skrev:Må desværre skuffe dig. Jeg er klassisk dannet, og var en af dem somspurtespurgte efter flere udfordringer, fordiatpensum var for nemt.
Du skulle nok have brugt lidt mere tid på din danskundervisning så? :P
Windcape (14) skrev:
Meningen med at lære historie er så vi kan undgå at gentage den. Med jeres argument omkring C og assembler, så burde vi sende ungerne ud i en skov for at jage med spyd, og tænde bål med flintesten.
Ja, hvorfor ikke sende børnene ud? Har du aldrig været ude i en mose i skolen og fiske klamme alger eller andet op af den, for så derefter at blive fortalt lange kedelige historier om livet i en mose?
Meningen er ikke at lære om historien for at sikre, at den ikke gentager sig. Igen handler det også om at lære om det du kommer fra; dit miljø, din arv osv.
Og dette kan så refereres direkte til programmering. Det er vigtigt at lære om det, der ligger bagved det du sidder og roder med i highlevel sprog for at få forståelse for, hvorfor tingene er som de er.
Tag fx et eksempel som en for-løkke. I Android fx anbefales det, at den skrives sådan her:
int sizeOfArr = arr.length;
for(int i = 0; i < sizeOfArr; i++) {
// Do stuff...
}
og ikke sådan her:
for(int i = 0; i < arr.length; i++) {
// Do stuff...
}Hvorfor? Fordi compileren opretter en var hver gang løkken har kørt én gang i den sidste for-løkke, mens i første eksempel henter den bare en var fra sit register hver gang. Ville compiler og registre give mening, hvis du intet kendte til det bagvedliggende?
Windcape (14) skrev:Jeg er klassisk dannet, og var en af dem som spurte efter flere udfordringer, fordi at pensum var for nemt.
Bare fordi man giver en abe alverdens værktøj og byggematerialer, lærer den, at skrue skruer i og samtlige håndværksmessige begreb og giver den arbejdshandsker og sikkerhedshjelm på, betyder det ikke, den kan bygge et hus, eller blot gennemskue hvilke materialer der er bedst til fx. at tække med.
Jeg var en af dem, der selv udvidede min horisont ved at granske videre i pensumet og finde ud af, hvilke sjove ting jeg kunne få ud af det, ved at sætte det samme på alle mulige måder, samt at finde begrænsninger og finde ud af, hvordan man kunne komme gennem begrænsningerne for at nå et eller andet tosset mål.
At have involveret lærerene ydligere, ville blot have indskrænket min udvikling.
90% af at løse et problem, er at stille sig selv, de helt rigtigte spørgsmål.
Og hvorfor mener du at man ikke kan lære det i ActionScript, men absolut skal lære det i C?Darwind (15) skrev:Det handler jo netop om at forstå de sprog, vores highlevel sprog bygger på. Selvom der er gc i AS3, så er det nu meget rart at vide, hvordan du undgår memory leaks, som din garbage collector ikke kan tage hånd om.
Der er ingen problemer i at lære om hvordan GC fungerer i andre sprog end C/C++! Derudover så er hele teorien omkring GC jo ikke sprog-specifikt.
Der er jo kun Boehm's GC som specifikt er skrevet til C/C++.
Nej, det er vigtigt at forstå hvordan tingene virker i forhold til hvordan du skal bruge dem.Darwind (15) skrev:Det er vigtigt at lære om det, der ligger bagved det du sidder og roder med i highlevel sprog for at få forståelse for, hvorfor tingene er som de er.
Det er ikke nødvendigt at vide hvordan en motor virker for at køre bil. Og det er heller ikke nødvendigt at vide hvordan C#s GC er implementeret, for at kode C#.
Hvis det er rigtigt, så vinder ORACLE jo nok deres retsag.Darwind (15) skrev:I Android fx anbefales det, at den skrives sådan her:
Det gør den forhåbenlig ikke. Den kan jo aflæse værdien direkte fra arr.length. Jeg tvivler på at den laver en kopi af arr.length.Darwind (15) skrev:Hvorfor? Fordi compileren opretter en var hver gang løkken har kørt én gang i den sidste for-løkke, mens i første eksempel henter den bare en var fra sit register hver gang.
Og så afhænger det jo også af om arr.length er volatile (thread-safe) eller ej. Hvilket igen er implementerings-specifikt, og ikke noget viden om C eller assembler vil hjælpe dig med at forstå.
Og tongue-in-cheek, foreach er altså pænere! (Selvom jeg godt ved at Java folk stadigvæk hænger fast i Java 1.4)
Addendum til dit Java eksempel.
Grundlaget er jo åbenlyst at gøre koden threadsafe. Men hvad hjælper det at gøre længden thread-safe, når resten af koden ikke er?
Du burde kopiere hele dit array før du laver operations på det i et loop, eller bruge synchronize, hvis du vil have hele operationen skal være thread-safe.
Så jeg ville jo nok bruge Collections.synchronizedList ! Hvilket så er baseret på viden om Java som sprog/framework, og ikke på viden omkring C eller assembler.
Grundlaget er jo åbenlyst at gøre koden threadsafe. Men hvad hjælper det at gøre længden thread-safe, når resten af koden ikke er?
Du burde kopiere hele dit array før du laver operations på det i et loop, eller bruge synchronize, hvis du vil have hele operationen skal være thread-safe.
Så jeg ville jo nok bruge Collections.synchronizedList ! Hvilket så er baseret på viden om Java som sprog/framework, og ikke på viden omkring C eller assembler.
volatile betyder altså ikke thread safe. Det ville du vide hvis du havde læst lidt mere om JVM'en.
Du vil ligeledes også vide at det kræver flere instruktioner at hente en attribut fra et objekt end det gør at hente en lokal variabel. Compileren kan desuden lave flere optimeringer hvis det er en lokal variabel.
edit: whaaat. Hvordan får du concurrency ind her???
Du vil ligeledes også vide at det kræver flere instruktioner at hente en attribut fra et objekt end det gør at hente en lokal variabel. Compileren kan desuden lave flere optimeringer hvis det er en lokal variabel.
edit: whaaat. Hvordan får du concurrency ind her???
#19
Har Java et volatile keyword? :o Jeg snakkede om volatile i C#.
Har Java et volatile keyword? :o Jeg snakkede om volatile i C#.
Vi kan jo prøve at se hvor mange IL instruktioner der skal bruges til de 2 forskellige eksempler i C#.onetreehell (19) skrev:Du vil ligeledes også vide at det kræver flere instruktioner at hente en attribut fra et objekt end det gør at hente en lokal variabel. Compileren kan desuden lave flere optimeringer hvis det er en lokal variabel.
Windcape (18) skrev:Grundlaget er jo åbenlyst at gøre koden threadsafe. Men hvad hjælper det at gøre længden thread-safe, når resten af koden ikke er?
Hvordan i alverden kan du konkludere det, udfra det lille udsnit ?
Windcape (18) skrev:Du burde kopiere hele dit array før du laver operations på det i et loop, eller bruge synchronize, hvis du vil have hele operationen skal være thread-safe.
Hvor ved du fra det ikke er gjort ? Og hvis det havde været pointen, tror du så ikke, der var taget noget mere med.
Bare fordi det ligner noget fra en lærebog, du har læst, betyder det ikke at pointen er det samme.
Du læser din tilfældigt udvalgte betydning ind i teksten, konkludere noget og er så overbevidst om, det er rigtigt.
Windcape, det handler ikke om, at folk skal lære C for partout at kunne noget C, som de måske i øvrigt aldrig får brug for, fordi de skal være webudviklere.
Det handler om, at man ved at få rode med disse lowlevel begreber indirekte erhverver nogle kompetencer, som kan gavne en i andre sammenhænge. I eksemplet med C kunne det f.eks. være debugging eller kodestilsdisciplin, hvor der hersker meget liberale vilkår for disse i C.
Dette "trick" bruges meget i skolesystemet - hvorfor tror f.eks. du man skal lære at regne i hånden inden du får lov at bruge lommeregner? Der bliver pakket rigtig mange kompetencer og dannelse ind i forløbene, selv om de umiddelbart ser ud til at handle om kernefagligheden i faget.
Man kunne sikkert godt undvære dette, eller erhverve kompetencerne på andre måder. Men jeg hælder nu også til at tro, at man bliver dygtigere til det man laver, hvis man har prøvet sådan noget.
Det handler om, at man ved at få rode med disse lowlevel begreber indirekte erhverver nogle kompetencer, som kan gavne en i andre sammenhænge. I eksemplet med C kunne det f.eks. være debugging eller kodestilsdisciplin, hvor der hersker meget liberale vilkår for disse i C.
Dette "trick" bruges meget i skolesystemet - hvorfor tror f.eks. du man skal lære at regne i hånden inden du får lov at bruge lommeregner? Der bliver pakket rigtig mange kompetencer og dannelse ind i forløbene, selv om de umiddelbart ser ud til at handle om kernefagligheden i faget.
Man kunne sikkert godt undvære dette, eller erhverve kompetencerne på andre måder. Men jeg hælder nu også til at tro, at man bliver dygtigere til det man laver, hvis man har prøvet sådan noget.
Hvad skulle det ellers handle om? Det er ikke micro-optimisering, som forresten også er hamrende ligegyldigt.onetreehell (19) skrev:edit: whaaat. Hvordan får du concurrency ind her???
Eller skal jeg minder dig om hvad Knuth mener omkring små optimeringer / premature optimizations?
#23
I hvert fald ikke concurrency, for den kode er på ingen måde threadsafe.
I hvert fald ikke concurrency, for den kode er på ingen måde threadsafe.
Sjovt som det bare aldrig er tilfældet. Folk der koder C er notorisk dårlige til at skrive clean code.Spiderboy (22) skrev:I eksemplet med C kunne det f.eks. være debugging eller kodestilsdisciplin, hvor der hersker meget liberale vilkår for disse i C.
Nu er der jo heldigvis ikke så mange der koder i C89 mere, men det indbyder godt nok til mere ulæseligkode end selv LISP!
Jeg ser ikke at folk skal lære hvordan elektronikken i en lommeregner virker, før de må bruge den.Spiderboy (22) skrev:Dette "trick" bruges meget i skolesystemet - hvorfor tror f.eks. du man skal lære at regne i hånden inden du får lov at bruge lommeregner?
Man kunne også erhverve disse kompetancer når/hvis de er nødvendige.Spiderboy (22) skrev:Man kunne sikkert godt undvære dette, eller erhverve kompetencerne på andre måder. Men jeg hælder nu også til at tro, at man bliver dygtigere til det man laver, hvis man har prøvet sådan noget.
Der er ingen grund til at spilde sig tid på at lære noget man aldrig for brug for, bare fordi nogle gamle hippier skulle lære det da de begyndte at programmere.
Windcape (26) skrev:Det har jeg jo allerede påpeget :ponetreehell (24) skrev:#23
I hvert fald ikke concurrency, for den kode er på ingen måde threadsafe.
Så du må spørge Darwind hvad pointen med koden er. Og hvis det er micro-optimeringer, så er det idioti.
Tjaa, pointen var som sådan ikke om mine antagelser var rigtige eller forkerte eller om det var threadsafety jeg var ude efter.
(Og mikrooptimeringer er bestemt ikke idioti i et mobilt OS, men det er en anden diskussion...)
Pointen var, at for at forstå, hvorfor man laver optimeringer, må man forstå det underliggende... som i en compiler og hvad der dertil hører.
Lige nu mangler jeg en "mute this person's posts... forever..." til dig Windcape. Du er grangiveligt god til at kode osv., men du lever åbenbart i en anden verden end os andre. Du begynder at nitpicke alt, hvad man skriver og forstår åbenbart bare ikke budskabet i det vi prøver at forklare dig.
Der er kun én sandhed og det er din... eller ikke.
I give up...
At optimere en for loop er så ligegyldigt som det kan blive.Darwind (27) skrev:Og mikrooptimeringer er bestemt ikke idioti i et mobilt OS, men det er en anden diskussion...
Du kan optimiere på 1000 andre ting først, som gør meget større forskelle.
Og du vil netop påpge at Dalvik ikke laver samme optimeringer som de fleste andre sprog? :oDarwind (27) skrev:Pointen var, at for at forstå, hvorfor man laver optimeringer, må man forstå det underliggende... som i en compiler og hvad der dertil hører.
Hvordan vil du have at folk skal lære hvordan implementeringsspecifikke ting som compilere fungerer, ved at lære generelt om C og assembler?
Den verden hvor man er god til hvad man laver, og ikke bekymre sig om noget man aldrig for brug for? :oDarwind (27) skrev:men du lever åbenbart i en anden verden end os andre
Det fungerer faktisk rigtigt godt at være dygtig til hvad man laver. Det er en sorgfri tilværelse :p
Du fatter jo keine. Du er ligesom et barn, som ikke vil smage på maden, fordi du tror, du ikke kan lide det. Folk prøver at forklare dig, at du får en dybere forståelse for noget, som du ikke begriber.
Datamatiker, ikke? Man er ikke just superprogrammør efter endt uddannelse.
Windcape (14) skrev:Jeg er klassisk dannet, og var en af dem som spurte efter flere udfordringer, fordi at pensum var for nemt.
Datamatiker, ikke? Man er ikke just superprogrammør efter endt uddannelse.
Det handler ikke om forståelse. Det handler om at nogle fjolser som dig selv, mener at man skal pådutte alle at lære en masse irrelevant, som de aldrig for brug for.ty (30) skrev:Du fatter jo keine. Du er ligesom et barn, som ikke vil smage på maden, fordi du tror, du ikke kan lide det. Folk prøver at forklare dig, at du får en dybere forståelse for noget, som du ikke begriber.
Jeg kunne også mene at du skulle lære en masse om en vins bouquet, terroir og druer, for at kunne drikke den. Men jeg har intet problem med at folk ikke skal have dybere forståelse for hvordan vinen er dyrket og fremstillet, så længe den smager godt.
Der er ingen ide i at spilde sin tid på at lære assembler i dag, medmindre man skal bruge det. Og hvis der går 10-20 år mellem man har brug for det, kan man ligeså godt lære/opfriske det når man skal bruge det, og så ellers fokusere på at lære vigtigere ting.
Derudover så kan jeg jo sikkert programmere i flere sprog, end de fleste af jer. Det er kun arne_v som kommer på side af min erfaring her. Ligeledes kender jeg udemærket til de koncepter der nævnes, og er så bekendt med dem som man kan være, når man ikke har brug for den specifikke viden i dagligdagen. Men det er kun fordi jeg har lært det når jeg har haft brug for det.
Så hvis der er nogen der fatter "keine" så er det vel dig.
Windcape (10) skrev:Performance har sjældent noget som helst at gøre med assembly eller hvad der ligner.
Performance har alt at gøre med at forstå hvad der faktisk sker.
At læse assembler programmering er en af de bedste måder at lære hvordan ern CPU fungerer.
Windcape (10) skrev:Som f.eks. SQL Query Execution Plans. Ikke hvordan man laver bitshifting!
SQL query plans og bitshifting er ikke relevante til samme problem, men lad os ignorere det.
Man kan nå et vist stykke med tools som SQL query plans, profilere etc., men det er stadigvæk ren blackbox filosofi. Den rigtige dybe indsigt kræver at m,an forstår hvad der sker indeni.
Windcape (14) skrev:Det underlige er faktisk at det er Java som har valgt at navngive den sådan. I C# hedder det en NullReferenceException, da der jo er snak om en CLR reference, og ikke en (nødvendigvis) en pointer!
Det er muligt at det undrer dig.
Men det undrer ikke dem som har studeret de tidligere sprog.
En Java reference svarer faktisk mere til en C++ pointer end til en C++ reference.
Og JLS taler faktisk om pointer.
Sektion 4.3.1:
The reference values (often just references) are pointers to these objects
C# er mere konsekvent i at kalde dem for references.
Men en af grundene er at C# jo har pointere i unsafe mode, så de er nødt til at skelne.
Windcape (17) skrev:Og hvorfor mener du at man ikke kan lære det i ActionScript, men absolut skal lære det i C?
Windcape (17) skrev:Der er ingen problemer i at lære om hvordan GC fungerer i andre sprog end C/C++! Derudover så er hele teorien omkring GC jo ikke sprog-specifikt.
Pointen i GC er noget mere tydelig, hvis folk har prøvet et sprog uden GC.
Windcape (18) skrev:Addendum til dit Java eksempel.
Grundlaget er jo åbenlyst at gøre koden threadsafe. Men hvad hjælper det at gøre længden thread-safe, når resten af koden ikke er?
Givet at Android dokumentation eksplicit siger at der er af andre grunde, så vil jeg finde det meget lidt åbenlyst.
http://developer.android.com/guide/practices/desig...
Windcape (20) skrev:Vi kan jo prøve at se hvor mange IL instruktioner der skal bruges til de 2 forskellige eksempler i C#.
Her er der jo at folk med lidt CPU forståelse f.eks. erhvervet gennem assembler programmering vil forstå at det er native instruktioner og ikke VM instruktioner der bestemmer performance.
Derudover så tvivler jeg på at IL og Dalvik instruktioner er sammenlignelige.
Windcape (23) skrev:Hvad skulle det ellers handle om? Det er ikke micro-optimisering, som forresten også er hamrende ligegyldigt.
Er det ikke lidt fjollet at gætte på andres bevæggrunde, når de faktisk har fortalt hvad bevæggrundene er?
Windcape (23) skrev:Eller skal jeg minder dig om hvad Knuth mener omkring små optimeringer / premature optimizations?
Du skulle prøve at læse lidt af Knuth.
Knuth er ikke som sådan imod optimeringer.
Han bruger faktisk assembler som sprog i hans kendte serie om algoritmer.
Han er imod ubegrundede optimeringer.
Men vi må antage at Google ved mere end dig om, hvorvidt de optimeringer er begrundede eller ej.
Windcape (25) skrev:Sjovt som det bare aldrig er tilfældet. Folk der koder C er notorisk dårlige til at skrive clean code.
C programmører er faktisk ofte ret disciplinerede.
Det er de simpelthen nødt til. Det er disciplinen ikke compileren som sikrer mod at skyde sig selv i foden.
Windcape (25) skrev:Nu er der jo heldigvis ikke så mange der koder i C89 mere,
Det er der faktisk rigtigt mange der gør.
C er stadig et af de helt store sprog.
Og C99 har ikke slået så meget igennem. Mange af de nye features er ikke så nødvendige. Compileren supporten er ikke så god (hverken VC++ eller gcc er fuldt C99 kompatibel omend de har en del/mange af features).
Og hvorfor tror i så konsekvent at CPU'en er relevant for optimeringer?arne_v (32) skrev:At læse assembler programmering er en af de bedste måder at lære hvordan ern CPU fungerer.
På mobiler handler performance mere om UI virtualisering, og threading, end det handler om CPU.
Og hvorfor skal det så være C/C++? Påstår du virkelig at det er de eneste sprog i verden uden GC?arne_v (34) skrev:Pointen i GC er noget mere tydelig, hvis folk har prøvet et sprog uden GC.
Han havde ikke præciseret det. Men det er dyb idioti at micro-optimere på det niveau som Darwind foreslog. Og det er da skuffende at se at Google's ellers så "kloge" udviklere ikke har lært at skrive en compiler der kan optimere sådanne problemer væk!arne_v (38) skrev:Er det ikke lidt fjollet at gætte på andres bevæggrunde, når de faktisk har fortalt hvad bevæggrundene er?
Men det er vel hvad man for ud af at bruge Java.
En optimering er ubegrundet indtil duarne_v (38) skrev:Han er imod ubegrundede optimeringer.
a) har et performance problem
b) har profilet din app, og fundet hvor problemet er.
Vi kan også antage at der er 1000 ting som giver meget større optimeringer, end et for loop.arne_v (38) skrev:Men vi må antage at Google ved mere end dig om, hvorvidt de optimeringer er begrundede eller ej.
Så kan man jo starte med at fokusere på dem. Hvis du nogensinde for tid til at optimere sådanne småting som der nævnes, så gør du ikke dit arbejde ordenligt!
Og alligevel skriver de altid super grim, og ulæselig kode.arne_v (39) skrev:C programmører er faktisk ofte ret disciplinerede.
Men så igen, C udviklere tror jo også stadigvæk på at længden af deres variable i deres kode, er vigtigt! Læsbarhed er jo ikke så vigtigt, nej nej.
Fordi "hwnd" er super mere læsbart end "windowHandle".
Stakkels dem.arne_v (39) skrev:Det er der faktisk rigtigt mange der gør.
Windcape (25) skrev:Sjovt som det bare aldrig er tilfældet. Folk der koder C er notorisk dårlige til at skrive clean code.
Det kunne være meget værre, for C tillader det meget værre. Meget meget værre.
Derfor tvinger C folk til at lære at skrive (nogenlunde) ordentligt - sikkert ofte efter at have brændt fingrene, men det er også en effektiv måde at lære det på.
Windcape (25) skrev:Jeg ser ikke at folk skal lære hvordan elektronikken i en lommeregner virker, før de må bruge den.
Tro mig, jeg kender mennesker, som meget gerne så, at det også er tilfældet. :-)
Windcape (25) skrev:Man kunne også erhverve disse kompetancer når/hvis de er nødvendige.
Det jeg hører dig sige er, at vi lige så godt kan droppe alt uddannelse, og springe direkte til arbejdsmarkedet, hvor vi lærer tingene hen af vejen?
Windcape (25) skrev:Der er ingen grund til at spilde sig tid på at lære noget man aldrig for brug for, bare fordi nogle gamle hippier skulle lære det da de begyndte at programmere.
Jeg er gymnasielærer. Første gang mine elever skal aflevere en forsøgsrapport i fysik, insisterer jeg på, at de skal tegne grafen i hånden på millimeterpapir, hvor de fremover kan vælge at gøre det på computer.
Hvorfor det, når man aldrig for brug for det i praksis nu til dags? Fordi det er min erfaring, at hvis man har lavet det på den gammeldags måde først, så forstår man meget bedre hvordan de moderne metoder virker. Jeg kan simpelthen se, at mine elever bedre forstår princippet i grafer hvis de har siddet og fedtet med det i hånden først. Og det gør, at de laver bedre grafer og færre fejl.
Windcape (31) skrev:Derudover så kan jeg jo sikkert programmere i flere sprog, end de fleste af jer. Det er kun arne_v som kommer på side af min erfaring her. Ligeledes kender jeg udemærket til de koncepter der nævnes, og er så bekendt med dem som man kan være, når man ikke har brug for den specifikke viden i dagligdagen. Men det er kun fordi jeg har lært det når jeg har haft brug for det.
arne_v er oftere uenig end enig med dig, så du har ikke nødvendigvis den endelige sandhed™ og kunne tage fejl.
arne_v (36) skrev:Ja.Windcape (20) skrev:Jeg snakkede om volatile i C#.
Java volatile (version 1.5-) og C# volatile (version 2.0-) virker helt ens.
Og volatile i java gør kun kode threadsafe i meget få cornercases.
Windcape (40) skrev:Han havde ikke præciseret det. Men det er dyb idioti at micro-optimere på det niveau som Darwind foreslog. Og det er da skuffende at se at Google's ellers så "kloge" udviklere ikke har lært at skrive en compiler der kan optimere sådanne problemer væk!arne_v (38) skrev:Er det ikke lidt fjollet at gætte på andres bevæggrunde, når de faktisk har fortalt hvad bevæggrundene er?
Hvis du vidste lidt mere om semantikken af java ville du vide at det ikke er lovligt for compileren (JIT eller ej) at optimere de lookups væk.
Windcape (25) skrev:Nu er der jo heldigvis ikke så mange der koder i C89 mere, men det indbyder godt nok til mere ulæseligkode end selv LISP!
Mange lisp-dialekter gør det meget nemt at lave DSL, hvilket kan gøre din kode meget pænere og mere læsbart. Du burde også finde dig en moderne lisp dialekt med hygenic macros.
Windcape (41) skrev:Og alligevel skriver de altid super grim, og ulæselig kode.
Kan vi få nogen eksempler på den forfærdelige kode du bliver ved med at snakke om?
Jeg kan allerede grundlæggende C. Men der går typisk Jeg oversatte en rijndael implementation fra C til C# for 5-6 år siden.onetreehell (45) skrev:Btw windcape jeg synes du burde prøve at lære C. Skrive på et projekt og sådan.
Har dog ikke haft brug for at arbejde med C siden. Og der sandsynligvis 10-20 år før jeg for brug for det igen.
Jeg ville nok kalde dig idiot hvis jeg var en af dine studerende.Spiderboy (43) skrev:Jeg er gymnasielærer. Første gang mine elever skal aflevere en forsøgsrapport i fysik, insisterer jeg på, at de skal tegne grafen i hånden på millimeterpapir, hvor de fremover kan vælge at gøre det på computer.
Man lærer intet ved at tegne det i hånden. Grafer er en grafisk repræsentation, for at give et hurtigere overblik. Hvordan de er skabt er ligegyldigt.
arne_v's holdninger er heller ikke den endelige sandhed. Jeg ser ingen grund til at rette ind til højre.Spiderboy (43) skrev:arne_v er oftere uenig end enig med dig, så du har ikke nødvendigvis den endelige sandhed™ og kunne tage fejl.
Og begge mine forældre er programmører, fra dengang hvor man brugte hulkort. Så jeg er fint bekendt med hvordan tingene har udviklet sig de sidste 30 år. Måske mere end de fleste andre!
#48
Ud fra en tidligere kommentar[1] vil jeg påstå at du ikke kan grundlæggende C. Jeg tror du kan lære en masse brugbart ved at bruge et par måneder på noget C, men det må du selv om.
[1]: http://macnation.newz.dk/forum/tagwall/datamatiker... #89 og #108
Edit: Wut, hvorfor gav google mig noget fra macnation o_O
Ud fra en tidligere kommentar[1] vil jeg påstå at du ikke kan grundlæggende C. Jeg tror du kan lære en masse brugbart ved at bruge et par måneder på noget C, men det må du selv om.
[1]: http://macnation.newz.dk/forum/tagwall/datamatiker... #89 og #108
Edit: Wut, hvorfor gav google mig noget fra macnation o_O
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