Skuldrene eller tæerne ?

Jeg roder med et af den slags problemer der ikke burde, men som til overflod findes: Hvordan laver man en backup-kopi af vigtige data fra et indlejret system.

Jeg kan ikke lige afsløre hvad det er for noget kram, men der er tale om et M68K fra slutningen af firserne og foreløbig er jeg igang med at disassemblere EPROM indholdet for at finde ud af hvor de data jeg skal have en kopi af ligger.

Mens jeg graver mig igennem 100k linier assembler, med min Python baserede disassembler/reverse-compiler (mere om den ved en senere lejlighed) er jeg flere gange stødt på smarte detaljer eller kreative løsninger som jeg må tage hatten af for.

Det fik mig til at tænke.

Udannelsen til kunstmaler eller billedhugger involverer endeløse museumsbesøg for at studere og aflure de klassiske mestre deres metoder og håndværk.

Mange kunstmuseer er ligefrem nødt til at spærre forstudier af gips mere af, end de færdige marmorstatuer, fordi den endeløse strøm af studerende der skal mærke mesterens fingerstrøg, slider for meget.

Kok bliver man heller ikke uden at spise sig vej igennem egne og andres fejltagelser.

Men uddannelsen som programmør, indeholder den egentlig nogen væsentlig komponent af at studere existerende programmer, eller er det noget man først rammer når man bliver ansat bagefter ?

Jeg startede selv med guderne vide hvor mange tusinder linier RPG-II på en S/34 og derfra igennem alle mulige stykker kode jeg har måttet slås med i de sidste 25 år.

I forhold til andre skabende kunstnere, har vi i vores disciplin adgang til en umådelig mængde "prior art", ikke som fotografiske reproduktioner, men som "the real thing", download bare sourceforge og github og start så der...

Men hvis vi nu skal være ærlige, så er det meste af koden på internettet mere at ligne med vor mors hverdagsmad, end med mesterkokkes geniale frembringelser og det lærer man ikke så meget af.

Vi burde lave os en Kanon (det er så populært i tiden) over programmer som alle programmører bør læse: Klassiske kildetekster som man lærer noget af.

John Lions bog med 6th edition UNIX kildeteksten hører helt klart til på listen. (Her genskabt og klar til download)

Andre forslag modtages med glæde...

phk

PS: Hvis nogen har en gammel PSOS/PSO-System manual, fra før det blev til "PSOS+", vil jeg meget gerne låne den.

Kommentarer (38)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Steen Krøyer

Jeg ved det ikke er et selvstændigt stykke kode, men Jon Bentleys "Programming Pearls" 2nd Ed (Addison-Wesley, 1999) er klart værd at læse/studere. Den er lille, i et direkte og letforståeligt sprog, og spækket med små og store guldkorn.

Klart en kanon-bog :-)

  • 0
  • 0
Jesper Louis Andersen

Doug McIlroy's "Squinting at power series" er ret fed som en concurrency-introduktion. Der er også Russ Cox "Regular Expression matching can be simple and fast":

http://swtch.com/~rsc/regexp/regexp1.html

... og så er vi vist ovre Bell Labs/Google/Plan9 folkene. Don Knuth har en del kommenterede programmer som er værd at kigge på (Dancing links i forbindelse med sudoku f.eks.).

John Hughes "Why Functional programming matters"

http://www.md.chalmers.se/~rjmh/Papers/whyfp.html

bør også være læst af enhver programmør. Funktionel programmering har i visse tilfælde noget at byde på, som imperative programmeringssprog har svært ved at gøre efter. En Kanon bør helt sikkert give anledning til en vis diversitet.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det var hele programmer jeg ledte efter, ikke bøger.

Og nej, generelt er små "proof of concept" programmer ikke noget værd som "kanonføde" for de er totalt uden kontext og det er netop samspillet med kontexten der er det svære at få rigtigt i programmering.

Poul-Henning

  • 0
  • 0
Poul-Henning Kamp Blogger

En Kanon bør helt sikkert give anledning til en vis diversitet.

Det er ikke diversiteten, men relevansen der afgør om værker kommer i en kanon, det handler ikke om at lave en spraglende forestilling, men om at vise hvad der har betydet noget i praksis.

Derfor er det ikke de højtravende teoretiske eksempler vi skal have, men derimod kode der faktisk blev brugt og gjorde nytte.

Poul-Henning

  • 0
  • 0
Torben Mogensen Blogger

Derfor er det ikke de højtravende teoretiske eksempler vi skal have, men derimod kode der faktisk blev brugt og gjorde nytte.

Så må Knuths kildekode til TeX bestemt være værdig.

Ditto Mads Toftes ML Kit compiler (med bidrag fra mange andre). Denne compiler har blandt andet været brugt til at udvikle IT Universitetets studieadministrationssystem, så den kan ikke kaldes unyttig.

Af ældre dato kunne Gier Algol 60 oversætteren være et udmærket eksempel.

  • 0
  • 0
Poul-Henning Kamp Blogger

GIER Algol 60: Sandsynligvis ja, ikke mindst på grund af dens "Rosetta Sten" kommentarer.

Toftes ML compiler: God joke.

Det smarte i at have et studieadministrationssystem som kun rektor, himself, kan vedligeholde er der ikke mange af de involverede der kan se.

Poul-Henning

  • 0
  • 0
Torben Mogensen Blogger

et studieadministrationssystem som kun rektor, himself, kan vedligeholde

Hvori begrunder du det udsagn? Der er sikkert flere i Danmark, der kan programmere i Standard ML end i M68K maskinkode, som var dit eksempel.

  • 0
  • 0
Claus Jørgensen

Men uddannelsen som programmør, indeholder den egentlig nogen væsentlig komponent af at studere existerende programmer, eller er det noget man først rammer når man bliver ansat bagefter ?

Nej, og det er vel sådan set heller ikke relevant?

Fordi i så fald, skulle det være programmer skrevet i de sprog der undervises i (Dvs. Java og C#).

Derudover så er "uddannelsen som programmør" mere fokuseret på alt andet end at programmere i dag. Man kan sågar blive uddannet Datamatiker uden at skrive en eneste linje kode i sit speciale.

At læse kildekoden til f.eks. UNIX vil mere end noget andet give et grundlag til at aldrig ville kode i C, og vise hvor dårligt et sprog det er.

Jeg så hellere at folk læse "Clean Code" af Robert C. Martin.

Men ellers, at læse kildekoden til .NET [1] eller Java [2], kunne også give et indblik i hvordan man designer gode APIs. Det er meget en vigtig i dag.

[1] http://referencesource.microsoft.com/netframework.aspx
[2] http://www.sun.com/software/opensource/java/

  • 0
  • 0
Carsten Sonne

Men uddannelsen som programmør, indeholder den egentlig nogen væsentlig komponent af at studere existerende programmer, eller er det noget man først rammer når man bliver ansat bagefter ?

Min uddannelse gjorde ikke. Til gengæld interesserede jeg mig for programmering allerede i de gamle C64 og Amiga dage.

Systemerne havde en begrænset hardware, der ikke så nemt lod sig udvide, præcis som nutidens indlejrede systemer. Det gjorde at programmøre måtte være ualmindelige kreative for at presse mere ud af hardwaren. Såkaldte demoer kom i en lind strøm, hvor kunstnerne udøvede deres magiske talenter og pressede hardwaren yderligt gang på gang.

De tekniker som blev brugt, giver en forståelse og en løsning på visse type problemer. Hvis man forstod princippet i en teknik, kunne den bruges til at løse lignende problemer på andre områder. I dag kalder det for (design) patterns.

En indblik i den slags teknikker, giver en forståelse og nogle ideer, der ikke kan erstattes med noget alternativ; Præcis som design patterns. Dem kan man også kun lære og forstå ved at studere dem, og i øvrigt eksperimentere med dem.

  • 0
  • 0
Jesper Mørch

Man kan sågar blive uddannet Datamatiker uden at skrive en eneste linje kode i sit speciale.

Nu er datamatiker-uddannelsen heller ikke en programmør-uddannelse, men en kort halvpraktisk datalogisk generalist-uddannelse. I øvrigt er datamatiker-hovedopgaven ikke specielt væsentlig for erhvervslivet. Hvis du som datamatiker derfor vælger ikke at programmere i din hovedopgave, har du måske en god grund til det netop fordi det er en generalist-uddannelse og ikke den slaveprogrammør-uddannelse den ofte betragtes som.

Fordi i så fald, skulle det være programmer skrevet i de sprog der undervises i (Dvs. Java og C#).

Sludder og vrøvl. Du lærer ikke noget af at læse om ting du i forvejen kender.
I øvrigt har både Java og C# meget meget dybe rødder i C.
Hvis du vil se et objektorienteret sprog UDEN rødder i C, skulle du tage et kig på SmallTalk. Det bruges faktisk stadig i seriøse IT-systemer...
Hvis det ikke behøver at være objektorienteret kan du f.eks. tage et kig på Cobol og PL/1, som også stadig bruges i tidskritiske systemer, Assembler er også relevant...
Faktisk kan du kun bruge C# og Java m.fl. til applikations-programmering, ikke til system-programmering med f.eks. egen ressource-styring o.lign. som er temmelig udbredt på embedded software m.m.

Når PHK taler om programmører, er jeg ret sikker på han ikke kun tænker på datamatikere, men også de akademisk IT-uddannede (ingeniører, dataloger m.fl.), som i høj grad også beskæftiges med embedded programmering, algoritme-udvikling, indlejrede systemer, hastighedsoptimering af eksisterende kode m.m., f.eks. at kode grafiske rutiner i assembler, for at trække al regnekraft ud af GPU'en :o)

  • 0
  • 0
Claus Jørgensen

Sludder og vrøvl. Du lærer ikke noget af at læse om ting du i forvejen kender.

Men modsat for man heller ikke noget ud af at læse en artikel på Fransk, hvis man kun kan læse Dansk og Engelsk.

Hvis du vil se et objektorienteret sprog UDEN rødder i C, skulle du tage et kig på SmallTalk. Det bruges faktisk stadig i seriøse IT-systemer

Alle programmører burde kende til SmallTalk. Det er en af de to sprog der bruges til eksempler i Design Patterns, Gamma et. al. (Hvilket jo er et must read for alle programmører!).

Faktisk kan du kun bruge C# og Java m.fl. til applikations-programmering, ikke til system-programmering med f.eks. egen ressource-styring o.lign. som er temmelig udbredt på embedded software m.m.

Jeg går ud fra at du ikke er Java/C# programmør, når du kommer med sådan en udtalese :-)

Når PHK taler om programmører, er jeg ret sikker på han ikke kun tænker på datamatikere, men også de akademisk IT-uddannede (ingeniører, dataloger m.fl.)

Og?

I så fald modsiger du jo dit første argument, at man ikke lære noget ved at læse om noget man allerede kender.

Derudover er der rimelig valgfrihed mht. sprog på de akademiske uddanelser. Jeg har set dataloger løse pathfinding opgaver i PHP, og signal-håndtering i C#.

  • 0
  • 0
Troels Liebe Bentsen

En compiler som kun har én større bruger og i et sprog som stort set kun bliver brugt til sprogforskning er ikke lige Kanon værdig efter min mening.

Tex er helt sikker imponerende men igen så er det sku sært og man skal vist hedde Donald Knuth for helt at forstå det.

En Kanon for programøre bør ikke indholde sprog som kun bliver brugt i akademiske kredse.

  • 0
  • 0
Torben Mogensen Blogger

En compiler som kun har én større bruger og i et sprog som stort set kun bliver brugt til sprogforskning er ikke lige Kanon værdig efter min mening.

Maskinkode for en død processorarkitektur på en død platform er ikke mere kanonværdig efter lignende kriterier. Det er vel kvalitet, der er det væsentligste kriterium.

Tex er helt sikker imponerende men igen så er det sku sært og man skal vist hedde Donald Knuth for helt at forstå det.

TeX/LaTeX bliver brugt af 90% af alle naturvidenskabelige forskere og en del forskere fra andre felter (jeg har set filosofi- og historietekster, der er lavet i LaTeX). Så man behøver ikke at være Knuth for at forstå TeX. Ejheller kildekoden, for den er noget af det bedst kommenterede og dokumenterede kode, der nogensinde er lavet.

En Kanon for programøre bør ikke indholde sprog som kun bliver brugt i akademiske kredse.

Det kan diskuteres, men hvorfor skulle et sådant krav udelukke Standard ML?

  • 0
  • 0
Troels Liebe Bentsen

Maskinkode for en død processorarkitektur på en død platform er ikke mere kanonværdig efter lignende kriterier. Det er vel kvalitet, der er det væsentligste kriterium.

Det skulle gerne være begge dele, brug og kvalitet. Det er for nemt at lave pæn kode hvis det ikke skal bruges i den virkelig verden. Så selv maskinkode fra en død processorarkitektur på en død platform er bedre en sprog hvis eneste test er en compiler til sig selv.

TeX/LaTeX bliver brugt af 90% af alle naturvidenskabelige forskere og en del forskere fra andre felter (jeg har set filosofi- og historietekster, der er lavet i LaTeX). Så man behøver ikke at være Knuth for at forstå TeX. Ejheller kildekoden, for den er noget af det bedst kommenterede og dokumenterede kode, der nogensinde er lavet

LaTex og Tex er helt sikkert fantisk og bliver brugt flittigt, men der er ikke lige frem mange andre udviklere der har rørt i den originale WEB kode som jo ville være Kanon eksemplet hvis Tex blev valgt.

Det kan diskuteres, men hvorfor skulle et sådant krav udelukke Standard ML?

Jeg kan ikke komme i tanke om så meget som et stykke kode skrevet i SML ud over ITU's studie administrative system som har praktisk anvendelse eller hvis hoved formål ikke har noget med en SML compiler at gøre. Og grunden til at nogen ville skrive et studie administrative system i SML har nok mere at gøre med manden der lavet sprogvalget end at det faktisk var det rigtig værktøj til opgaven.

Hvis det endeligt skal være eksempler i et funktionelle sprog, så finde man mere kode som faktisk bliver brugt i Erlang, F# eller Haskell.

Men igen en Kanon plejer at være noget for "folket" så her duer det ikke med noget som kun en snæver lille elite kan forstå og ser som "stor" kunst hvilket vist nok udelukker de flest funktionelle sprog.

  • 0
  • 0
Jesper Mørch

Jeg går ud fra at du ikke er Java/C# programmør, når du kommer med sådan en udtalese

Selvom jeg er IT-uddannet, er jeg ikke udpræget programmør.
Det afholder mig dog ikke fra at have programmeret i både Java, VB, C++, QBasic, PHP, UNIX-shell, SmallTalk, et par scriptsprog (f.eks. JavaScript) og en smule C, og er nu på vej ud i Ruby og Python.
Sprog som har memory-management indbygget i VM'en egner sig ikke til hardware-programmering. til gengæld er de ideelle til applikations-udvikling, hvor det giver knap så dygtige programmører (som undertegnede) større muligheder for at kunne få noget kode fra hånden, uden at behøve at tænke på hardware- og platforms-specifik optimering, hukommelses-håndtering (og oprydning) etc. De forskellige benyttede 16-bit udgaver af Windows (3.x, 95, 98, og Me) var glimrende eksempler på elendig hukommelses-håndtering, andre versioner af operativsystemer har (haft) lignende problemer gennem tiden... Med C# og Java m.fl. elimineres den slags problemer. til gengæld får man slet ikke samme performance som ved at benytte C, som jeg stadig vil betragte som det ultimative programmerings-sprog. Måske derfor operativsystemer stadig skrives i netop C.

  • 0
  • 0
Claus Jørgensen

Sprog som har memory-management indbygget i VM'en egner sig ikke til hardware-programmering.

Men nu snakker du pludselig om .NET og Java (platform), ikke om C# og Java (sprog). Der er stor forskel! (Til blandt andet Lego Mindstorms bruges der Java til embedded programmering.)

Hvis man skal lave applikationsudvikling i C/C++ ville man også bruge en Garbage Collector.

Og der var en ide til noget must-read klassisk kode:

Hans Boehm's Garbage Collector: http://www.hpl.hp.com/personal/Hans_Boehm/gc/

  • 0
  • 0
Claus Jørgensen

Så free og delete er altså ikke sprog primitiver?

Jo, men hvad er pointen?

C# tillader jo netop manuel memory håndtering (til en vis grad, men mere end Java). Og derfor kan det også fint bruges til embedding.

Spørgsmålet handler om performance, men der skal man jo altid vurdere hvad der er vigtigst, udviklingshastighed eller produktperformance. Helst med en solid business-case, og ikke meninger.

  • 0
  • 0
Poul-Henning Kamp Blogger

Maskinkode for en død processorarkitektur på en død platform er ikke mere kanonværdig efter lignende kriterier. Det er vel kvalitet, der er det væsentligste kriterium.

Nu har jeg for det første ikke foreslået det pågældende m68k program til kanonen, men jeg synes at det er en totalt forkert opfattelse der gives udtryk for her.

Jeg giver ret så langt, at sproget ikke må være en decideret hindring for at man faktisk kan læse programmet, derfor min ikke helt uforbeholdne tilslutning til Gier Algol compileren.

Derudover er jeg skuffet over jeres totale mangel på fantasi.

Jeg havde selv "Apollo Guidance Computer" som punkt to på listen, men tænkte at det kunne en af jer da få lov til at foreslå.

Men det gjorde i ikke ?

Tror I ikke i kan lære noget af at læse programmet der gjorde det muligt at lade et menneske hoppe omkring på en "soundstage in Arizona" ?

Endelig, har jeg absolut ikke noget problem med at programmerne fylder hundrede sider eller mere: det handler netop om at finde nogle solide værker man kan studere og lære nyt af, hele livet, ikke om nogle "social-media karma improving soundbites" der passer under den gennemsnitlige "boredom-timeout" på fem sekunder.

Poul-Henning

PS: Og alt det der "Mit programmeringssprog er bedre end dit programmeringssprog" pisseri kan i tage et andet sted hen: Gode programmører kan skrive i ethvert sprog de får behov for.

  • 0
  • 0
Jesper Louis Andersen

Hvis det er de større eksempler du er efter, og ikke perler, så er der formentlig noget at hente fra Lausen, Hansen og Jensen i 60'erne og starten af 70'erne. Det lader til at de herrer havde gang i nogle ting som i den grad satte pegepinden i den rigtige retning.

Plan9 er helt sikkert også et studie værd. Traditionelle UNIX-kerner er ufatteligt grimme set i perspektiv. Der er en masse om at skrive programmer som kan vedligeholdes over lang tid gemt i Plan9. Og nogle ret innovative ideer.

FreeBSD eller NetBSD er også værd at kigge på. De udgør i modsætning til Linux en noget mindre anarkistisk konstruktion og derfor er de en del nemmere at finde rundt i som operativsystemer. Minix er en mulighed hvis det skal være småt. Der er også bøger skrevet så man har et kommentarspor sideløbende med læsningen. Jeg ville nok foretrække NetBSD som er en del "renere" end FreeBSD (sorry PHK).

Knuths TeX. Den har været oppe og vende. MLKittet er heller ikke så ringe en ide endda. Og Standard MLs Basis library er også temmeligt godt. Hvis man ellers kan læse koden, og forstå hvad der foregår er det utroligt godt skruet sammen. Jeg synes det er lettere irrelevant hvor mange som bruger et givent stykke software. Der er masser af firefox-brugere, men køn er koden fandme ikke. Generelt tvivler jeg på at der er korrelation mellem køn kode og antallet af personer som bruger den.

PostgreSQL.

Quake-kodebaserne, måske. Jeg har ikke kigget på dem. Et andet bud er SQLite som efter sigende skulle have mere testkode end produktionskode med en stor faktor. Det har jeg jeg heller ikke kigget på.

Scheme48 er en fed interpreter-kodebase som jeg klart også vil anbefale. Den oprindelige implementation er efter sigende skrevet på 48 timer, men nu går joken at man skal kunne læse kodebasen på 48 timer. Det er en klassisk interpreter hvor en virtuel maskine afvikles i C med en Scheme-fortolker ovenpå. Fortolkeren er inkrementalt bootstrapped på den fede måde.. I starten havde de en scheme-variant uden GC og eksplicit hukommelsesstyring der så langsomt morfes indtil den er en R5RS-scheme. Det er ekstremt interessante sager.

Bortset fra arbejdet omkring Regnecentralen er fordelen at alt den kode jeg har nævnt er offentlig tilgængelig og under fornuftige licenser i de fleste tilfælde. Jeg kender ikke status på så gammel kode fra år før jeg blev født :)

  • 0
  • 0
Poul-Henning Kamp Blogger

Bortset fra arbejdet omkring Regnecentralen er fordelen at alt den kode jeg har nævnt er offentlig tilgængelig

Jeg har ikke overblik over præcis hvor meget, men vi har en masse regnecentralen materiale i datamuseum.dk.

Poul-Henning

  • 0
  • 0
Carl-Lykke Pedersen

Hej PH.

Jeg har altid godt kunne lide det her:

define _ F-->00 || F-OO--;

long F=00,OO=00;
main(){F_OO();printf("%1.3f\n", 4.*-F/OO/OO);}F_OO()
{
_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_
_-_-_-_
}

/* Måske smadret lidt af tøsset variabel-bredde typesnit, men så se her:
http://www.cise.ufl.edu/~manuel/obfuscate/pi.c */

Og jeg har ikke koden, men kun beskrivelsen af Mel's kode i Hacker's Dictionary: http://www.outpost9.com/reference/jargon/jargon_49.html

  • 0
  • 0
Henrik Jacobsen

Nu har jeg for det første ikke foreslået det pågældende m68k program til kanonen(...)

Mon ikke det var GA-compileren der blev hentydet til?

Jeg giver ret så langt, at sproget ikke må være en decideret hindring for at man faktisk kan læse programmet
(...)
Jeg havde selv "Apollo Guidance Computer" som punkt to på listen (...)

Lidt paradoksalt... der er vist noget med en instruktion i Apollo-computeren, som ingen længere kan gøre rede for funktionen af ;)

  • 0
  • 0
Troels Liebe Bentsen

Postfix er helt klart noget af den pænest C kode jeg har kigget på. Masser af kommentare, klar opdeling og fornuftigt design.

Openssh er også rimeligt pæn kode og med interessante design detaljer, så som privilege separation og alt det bøvlede der er omkring kryptering, sockets og terminalen på Unix.

Chromium for dens design og nye tilgang til hvordan man lavere software, sandboxes og processer i stedet for tråde, etc. Hvordan de så bundler og distribuere den er tilgængelig ikke så fantastisk.

Dokuwiki er noget er den pæneste PHP kode jeg har set til dato og har igen en anden tilgang til hvordan man løser opgaven med at lave en wiki.

Git for sit simple og effektive design på en kompliceret opgave, kode kvaliteten variere dog lidt, men bliver bedre for hver release.

  • 0
  • 0
Henrik Jacobsen

Fik så lige checket op på det (her: http://en.wikipedia.org/wiki/Apollo_Guidance_Computer#The_Block_II). Den mystiske EDRUPT instruktion optræder kun een gang i al kendt SW til AGC'en, så det er ikke et kardinalpunkt for forståelsen - men maskinens ejendommeligheder i øvrigt får GIERs indikatoroperationer til at fremstå som det rene læse-let stof.

Jeg tror i øvrigt der er et betydeligt mismatch mellem dine forventinger (til kanon-forslag), og målgruppen her på Version2. Teknikker og problemstillinger fra AGC (hard real time, stærkt begrænset kode- og dataplads osv) er simpelt hen for langt fra den daglige virkelighed - for andre end nogle ganske få af os :)

  • 0
  • 0
Carsten Sonne

En ting jeg støtte på engang ifm. bogstaver der bevæger sig hen over skærmen i en kurve, var en sine table generator.

[code=qbasic]
10 L=256: REM length of table

20 X=10: REM amplitude/2

30 A=1024: REM address

40 FOR I=0 TO 2$ \pi$ STEP 2$ \pi$ /L

50 : POKE A,SIN(I)*Y+Y

60 NEXT
[/code]

Teknikken går i alt sin enkelthed ud på at generere en tabel med koordinater svarende til kurven. Det man kan lære af den teknik, er at nogle gange kan det bedre betale sig at forudberegne visse tal frem for at beregne dem undervejs; En memory vs. CPU afvejning. Samme princip som en cache. Måske et simpelt eksempel, men alligevel med til at give en slags erkendelse i et helt banalt princip.

En anden eksempel med en fascinerende effekt, går ud på at modificerer grafik hardware registrer efterhånden som skærmen tegnes via interrupts, hvorved registrer kan genbruges i forskellige tilstande ned over billedet. Hvad kan man lære at det ? Om ikke andet, kan man da erkende at en tilstand skal ses ift. et tidspunkt. En princip man skal være super skarp på i multithreading.

Et sidste eksempel, var en implementering af en simpel 3D motor jeg så engang, skrevet i C. Den var spækket med alle mulige små niftige detaljer. Generelt er 3D engines og kompilerer fyldt med små sjældent sete detaljer.

Man kan lære meget ved at studere små detaljer i alle typer sprog, på alle typer platforme, også fortidens. Der er dog langt imellem guldkornene. I dag er der væsentlig længere end da hardwaren var en ufravigelig begrænsning.

  • 0
  • 0
Torben Mogensen Blogger

Og alt det der "Mit programmeringssprog er bedre end dit programmeringssprog" pisseri kan i tage et andet sted hen: Gode programmører kan skrive i ethvert sprog de får behov for.

Enig. Mine eksempler omfattede f.eks. også TeX, som er skrevet i CWeb, som er en [i]literate programming[/i] skal bygget ovenpå C, som bekendt ikke er mit yndlingssprog. Men Knuth kan skrive pæn kode i alle sprog. Man kan måske ligefrem sige, at C er et sprog, hvor man virkelig kan se forskel på gode og almindelige programmører: Gode programmører kan lave pæn og velfungerende kode i C, mens almindelige programmører laver grim kode, der bruger uhyrlige mængder lager og jævnligt bryder sammen.

  • 0
  • 0
Esben Bach

Selvom det nok ikke lige umiddelbart lader sig gøre, så kunne jeg godt tænke mig at se hvad der styrer og driver de 2 NASA Mars Rovers Spirit og Opportunity, specielt med de seneste udvidelser omkring billede genkendelse. Det er godt nok en speciel kontekst, tilgengæld må der være en del steder man skal tænke kreativt.

  • 0
  • 0
Carsten Sonne

Vi burde lave os en Kanon (det er så populært i tiden) over programmer som alle programmører bør læse: Klassiske kildetekster som man lærer noget af.

Efter dybere overvejelser: Fantastisk ide. Den bør spænde bredt over sprog og platforme. En omhyggelig valgt liste af kildekode, ville være et stort aktiv. Specielt for dem der vil gerne vil aflure og lære de store kunstneres tankegang. Derudover vil det give en vis mængde 'publicity' og måske inspiration til nogle unge håbefulde mennesker.

Processen kunne være
1) Indsendelse af forslag fra offentligheden.
2) Sortering af et dommerpanel.
3) En liste på måske 50-100 nominerede stykker kode
4) Afstemning fra en kendt brugergruppe, men åben for tilmelding.
5) F.eks. 10-20 stykker kode der slipper igennem nåleøjet.

Alternative processer kan ligeledes tænkes.

  • 0
  • 0
Robert Larsen

Jeg er personligt ret glad for Gtk+. Ikke fordi jeg bruger skidtet, men fordi jeg synes, at det er virkelig lækker C kode.

Når folk siger, at C ikke er objekt orienteret, sender jeg dem altid i retning af Gtk+.

  • 0
  • 0
Log ind eller Opret konto for at kommentere