Hvordan programmerer jeg ?

En af de første ting jeg blev foreslået til min blog her på version2 var "Du kan jo skrive hvordan du programmerer."

Den har jeg nu gået og tygget på i meget lang tid og nu har jeg opgivet.

Men I fortjener at vide hvorfor jeg har opgivet, selvom det bliver en noget abstrakt og højrøvet saga.

Jeg ved at Vladimir Horowitz på det bestemte påstod at han ikke anede hvordan han spillede Chopin.

Det var der naturligvis ikke nogen der troede på, enhver kunne jo høre hvor godt han gjorde det.

Men jeg er begyndt at forstå hvad han mente.

Ja, han stiller noderne på flyglet og ham tamper i tangenterne og ud kommer den skønneste version af Chopin man kan ønske sig, men hvad der lige sker imellem de første to punkter er svært at formulere.

Ligesom musik har programmer en karakter og struktur, en kerne har f.eks en første sats hvor alt stables på benene, en andensats der ikke gør mine til at slutte og en tredje sats hvor der nødtørftigt ryddes op inden der slukkes og lukkes, ofte med en række ustoppelige coda'er i bedste Beethoven stil, mens man forsøger at få alt stoppet ned på disken.

Men i modsætning til musik er programmers notation ikke bundet til resultatet, men kun til processen og derfor har kildeteksten en selvstændig æstetik der ofte trækker i helt andre retninger end alle andre hensyn.

Nogle kildetekster er hårdt strukturerede som en Piet Mondrian, andre ligner noget der er kastet sammen af Hieronymus Bosch.

Et helt særligt udkomme af denne æstetik er IOCC konkurrencens fantastiske indslag, eller duff's device der er C sprogets svar på Escher.

Som om det ikke var nok, så er kildetekster notorisk dårlige til at representere datastrukturene i et program, dem må man i alle gængse sprog udlede af programmets handlinger.

(Det skyldes sikkert denne frihed fra direkte representation at datastrukturer har meget højere dimensionalitet end kildetekstens en eller til nød to dimensioner og der har været gjort forsøg på at vende denne ulighed, men resultaterne var forholdsvis pauvre.)

Datastrukturer har også deres egne arkitektoniske idealer, de kan ligne Søren Bruns dragesnor eller et tempel fra den klassiske antik,men det må man som sagt læse sig til, det er ikke umiddelbart synligt.

Oven i alt dette kommer så de rent funktionelle krav, hvad programmet skal gøre, hvilket miljø det skal køre i, performance, robusthed osv.

Jeg har prøvet at rekonstruere forløbet for Varnish, men det er ikke lykkedes mig at formulere endsige uddrage en beskrivelse af processen.

Jeg kan genkende en række forskellige værktøjer og processer der iterativt bruges undervejs og nogle fænomener eller tendenser.

F.eks når jeg kører fast eller er utilfreds med noget kode, men ikke har en bedre ide, så polerer jeg koden mens jeg tænker over problemet: flytter funktioner sammen eller fra hinanden, abstraherer funktionalitet og omstrukturerer kode.

Andre gange prøver jeg med alle midler "at få hul igennem" og resultatet er noget frygtelig kode der kun hænger sammen med ståltråd tyggegummi og bøjede søm, men det når frem til mål med en lillefingernegl og derved kan jeg enten opnå bekræftelse på metodens brugbarhed, eller konstatere at det bliver noget frygteligt rod.

Det er også tydeligt, at kode der er for komplext i forhold til hvad det skal opnå går mig på: Der skal være et rimeligt forhold imellem hvordan kildeteksten ser ud og hvad den gør.

Men alt i alt, så må jeg blankt indrømme: jeg ved egentlig ikke hvordan jeg programmerer.

phk

Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Claus Dræby

Det varmer mit hjerte at du giver æstetikken så fremtrædende plads i din beskrivelse af programmering. Gang på gang har jeg oplevet at kvaliteten af mine programmer hænger langt tættere sammen med min følelse af at det er smukt end af nogen anden parameter jeg har kunnet finde.

Det binder en smuk ende til den undersøgelse du refererede forleden, hvor det så meget ud som om det at blive god til at programmere var et talent snarere end en færdighed.

Så mon ikke man kan sige at det du ikke ved er ligesom liv, intelligens og andre interessante begreber: Vi kan ikke definere dem, men vi bilder os ind at vi kan kende dem når vi ser dem?

  • 0
  • 0
Jens Madsen

Mit indtryk er, at de fleste softwarefolk programmerer på deadline. Hvis man ser på de kvaliteter et program skal opfylde, så er deadline den vigtigste. Det betyder, at enhver anden kvalitet - endog pålidelighed - ofte er under. Og ting som forsinkelse, strømforbrug, osv. er langt under.

Dette betyder, at vi får en type softwarefolk, der lærer at stoppe med at tænke i tide. Man tænker hurtigt, og kort, og begynder ikke at tænke i kvalitet. I stedet for, at bruge masser af tid, før man programmerer. Og bruge den tid som det tager, at få de rette idéer.

Jeg har altid nedprioriteret deadline, fordi det er den eneste parameter, man absolut intet lærer af. Det kan betragtes som en grænse for, hvor meget man lærer. Når deadlines nås, stoppes processen. Og arbejdes konstant med kort deadline, kommer hjernen ikke i omdrejninger, efter at finde de bedste og dygtigste løsninger.

Ofte må man starte forfra, fordi det viser sig, at en idé ikke fungerer. Er en algorithme forkert, så kan man ikke "rette" sig til funktion. Algorithmen må ganske enkelt kasseres, og udskiftes. Jo mere man har programmeret på denne fadæse - jo mere ondt gør det. Men, hvis man har syltet tiden, med at blot tænke, så er det ikke så slemt. Derfor sylter jeg gerne tiden, inden jeg går i gang.

Ofte høres, at dygtige programmører bruger flere hundrede tusinder linier på et program. Min metode er en anden: Det vigtige er ikke programmet, men dokumentation. Dokumentation må ikke indeholde kode, da den skal abstrahere koden væk, og kunne præsentere det underliggende uden kode, som en black-box. Dette sætter krav til det underliggenes dokumentation. Er der ikke nævnt ting som store O funktioner, så er der aldrig et svar. Store O funktion, er garantien for svaret. Ram forbrug, og harddisk forbrug, er garanti mod uendligt forbrug. Man skal vide, hvilke parametre de forskellige forbrug afhænger af. Og derfor betyder ram noget. Hastighed betyder noget. Indstruktioner betyder noget. Harddisk betyder noget. Selvom en faktor to, ikke betyder alverden. Hvis disse ting ikke dokumenteres, går forbruget mod uendeligt, og der er ingen grænse, og det vil ikke kunne fungere.

Man kan ikke teste sig til, om noget fungere. Kun hvis dataene for programmet er i orden, vil det fungere. At en test siger ok, er ikke meget værd. Som for en stikkontakt, kan man ikke bare "teste" sig til, at den holder til 30A. Den kan kun holde til 10A - for det er det, som den er designet til. Det rigtige er altid, at designe tingene til at fungere. Det betyder, at man altid tager efter worst case. Indenfor HW vil enhver der afleverer en konstruktion hvis data er kommet som resultat af en "test", og ikke som resultat af worst case for de komponenter der bruges, blive betragtet som stor idiot. En konstruktion kan kun holde til det den er designet til - ikke til det den kan testes til. Næste gang, vil den ikke kunne holde, hvis det baseres på test. Kun ved at have et top-down design, således vi anvender veldokumenterede dokumenter, så er vi i stand til at dokumentere, at vores program overhovedet har svar. Er det ikke dokumenteret for de underlæggende komponenter, skal de kasseres.

Brugervenlighed måler jeg, som hastigheden hvormed en bruger kan bruge programmet. Skal noget indtastes, betyder det noget, hvor længe brugeren skal bruge tid på dette. Tastes noget forkert, betyder noget, hvor længe brugeren skal bruge for at rette det. En menu, der driller, og hopper bort, når musen kommer i nærheden, således brugeren saboteres er bandlyst. Focus, der tilfældigvis skiftes bort, ved at blive "trukken" over i anden applikation, så brugeren pludselig taster forkert sted, er også bandlyst - måske findes i den anden applikation formatering af harddisk, når der trykkes backspace. Formatering af harddisk, sletning af dokumenter, det indtastede osv. accepteres ikke, at kunne ske "ved en fejl".

Deadline lærer man ikke noget af.

Ofte ses, at deadline også fører til fejl - og tiden at rette disse fejl, er ikke medregnet. Er der her ny deadline fortsætter historien, og rettelserne gøres ikke godt - desuden er det ofte umuligt, da man aldrig når niveauet, hvor de algorithmer som ikke dur, må skiftes. Det vil tage for lang tid, og en rettelse påkræves. Resultatet er, at man går mere og mere i retning af, at intet fungere.

Deadline er den største taber.

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