Coders at Work

søndag 21. mars 2010 Bøker Historie

Coders at Work var den første boken jeg leste på Kindle'n min, og den er helt fenomenal! Overbevist allerede? Så løp og kjøp. Hvis du trenger mer overbevisning, les denne artikkelen, og så løp og kjøp!

Coders at Work inneholder intervjuer med 15 programmerings-storheter. Peter Seibel spør utviklere som har vært i bransjen siden så tidlig som 60-tallet, og som alle har konkrete resultater å vise til, hvordan man lærer å programmere, hvordan de utøver sitt yrke, hva de tenker om fremtiden innenfor faget, og mye, mye mer.

Å "høre" disse menneskene fortelle om sine svært varierte karriærer har åpnet øynene mine. Boken gir et unikt, historisk perspektiv for oss som ikke har holdt på med dette like lenge som disse legendene.

Det var spesielt tre intervjuer som skilte seg ut, og som jeg vil fortelle litt mer om. Deretter vil jeg trekke frem tre lærdommer fra intervjuobjektenes samlede visdom.

Høydepunkt #1: Dan Ingalls

Alan Key hadde ideen til Smalltalk, men det er Dan Ingalls som implementerte. Dan er "egentlig" fysiker, men da han begynte å jobbe på Xerox PARC var det ingen vei tilbake. Han har også stått bak noen svært sentrale algoritmer innen datagrafikk, og muligjorde UI-elementer vi nå tar for gitt – som pop-up menyer og lignende.

Dan er en fasinerende fyr som viser en ekte glede for programmering. Han ser på software som noe levende, noe man må leke med, og design er noe som skal vokses frem etterhvert som man koder. Jeg var så heldig å få se ham in real life på QCon London, hvor han fremstod som svært ydmyk og beskjeden – til tross for at han har vært med å forme hvordan vi i dag ser på både objektorientering og interaksjon med datamaskiner generelt.

Dan Ingalls legger stor vekt på betydningen av å ha et dynamisk og interaktivt grensesnitt til programmering, slik som Smalltalk/Squeak eller Lively Kernel (som han har jobbet med i det siste), slik at man får rask tilbakemelding på hva man gjør. Jeg tror dette er sterkt undervurdert i utdanningen av dagens utviklere, og skulle ønske vi hadde flere slike utviklingsmiljøer. Men språk som har interaktive kommandolinjer (som Ruby, Python, Boo, Erlang, Haskell, etc.) gir også en del av disse fordelene.

Intervjuet med Dan var kanskje det aller største høydepunktet i boken. Han har et pragmatisk forhold til programmering som inspirerer meg.

Høydepunkt #2: Ken Thompson

Ken Thompson er aller mest for å ha utviklet UNIX (sammen med Dennis Ritchie). Han står også bak programmeringsspråket B, forgjengeren til C (det er helt sant!). Han har også gjort revolusjonerende ting innen sjakk-programmering, og kom opp med den i dag velbrukte UTF-8 Unicode encodingen.

En av de tingene Thompson minner oss på i Coders at Work er at design av software skal være dynamisk. Når noe ikke er optimalt for en ny situasjon så er det bedre å refakturere enn å følge det orginale designet og bare lappe på koden. Alt for ofte ser vi på kode som vi har skrevet som noe som har så stor verdi i seg selv at vi ikke vil ødelegge det. Selv om vi vet at det går raskere og løsningen vil bli bedre neste gang vi løser et problem, så beholder vi koden i stor grad slik vi først implementerte den. Thompson refaktureringer og omskriver rått og brutalt:

Thompson: I've never been a lover of existing code. Code by itself amost rots and it's gotta be rewritten. Even when nothing has changed, for some reason it rots.

Seibel: How do you decide when code needs to be thrown away?

Thompson: When it's hard to work on. I do it much quicker than most people do. I'll throw away code as soon I want to add something to it and I get the feeling that what I have to do to add it is too hard. I'll throw it away and start over and come up with a different partitioning that makes it easy to do whatever I wanted to do. I'm really quick on the trigger for throwing stuff out.

Thompson drev smidig design lenge før noen begynte å snakke om Agile.

Høydepunkt #3: Joe Armstrong

Joe Armstrong er kjent får å ha utviklet programmeringsspråket Erlang, og Open Telecom Platform (OTP), da han jobbet for Ericsson Computer Science Lab. Som Ingalls har også Joe bakgrunn som fysiker.

Intervjuet inneholder mange tankevekkende (og provoserende) uttalelser – Joe er ingen A4-utvikler, men mye av det han står for er ting man finner igjen innenfor eXtreme programming og software craftsmanship bevegelsen. Han sier f.eks. at det tar 30 år med trening før man kan si at man kan programmering. Han sier også at han kun programmerer når han føler seg i toppform – når han ikke føler at koden strømmer ut fra fingrene av seg selv går han i stedet rundt og forstyrrer sine medarbeidere (lol).

Joe forteller også at han ikke hopper rett inn og begynner å kode. Om han får et prosjekt som skal ta 12 måneder så bruker han de første 9 til å gå rundt og tenke og gruble på hvordan det best lar seg gjøre. Når han kommer til kodingen har designet blitt en del av underbevisstheten, og implementeringen er deretter fort gjort.

Svarte bokser er noe Joe ikke setter pris på. Det koster ham ikke en halv kalori å åpne opp bibliotek han benytter og gjøre endringer som passer ham. Man bør løse ting der hvor de er enklest å løse, generalisering og gjenbruk kan være negativt.

Da jeg så Joe på QCon London fikk jeg et helt annet inntrykk av ham enn jeg hadde fått gjennom intervjuet. Han var en litt liten og rolig, eldre mann, og minnet litt om charley chaplin. Men det han hadde å fortelle satt i gang en storm av nye tanker, og jeg gikk som jeg har fortalt tidligere straks ut og kjøpte boken hans om samtidighetsprogrammering i Erlang.

Visdomsord #1: Multithreading er fordømt vanskelig

Seibel spurte alle intervjuobjektene om de kunne fortelle om den vankeligste bug'en de hadde måttet fikse. Nesten alle svarte med å begynne å snakke om multithreading og samtidighet (bortsett fra Joe Armstrong, som synes samtidighet er mye enklere enn mainstream programmering). Selv de mest geniale utviklerne sier at mutithreading er vanskelig, og at den beste løsningen er å unngå det!

Da er det morsomt å faktisk jobbe på et system som er så gjennomsyret av samtidighet som vår SMS Gateway :)

Visdomsord #2: C var et feilskjær

Flere av de intervjuede kom inn på programmeringsspråket C, og hvordan det – på grunn av at det ble så populært – har bremset og til dels ødelagt utviklingen av avanserte programmeringsspråk og kompilatorer. Fran Allen sier for eksempel:

"By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of high-level language to the machine."

Dette var en tankevekker, og noe jeg ikke hadde hørt om tidligere. Jeg lurer på hva vi hadde fått til med maskinene våre i dag om C aldri hadde blitt utviklet, og Fortran og Lisp hadde beholdt sitt fotfeste i bransjen. Bernie Cosell hadde følgende å si om fremtiden:

"I don't know what tomorrow's language is. I don't think C or it's derivatives such as C++ are going to really be the right vehicle for heavy-duty program application - even system development - going forward."

Visdomsord #3: De gamle er eldst

Det siste jeg vil trekke frem fra boken er hva de "gamle utviklerne" hadde å si om hva som har skjedd innenfor softwareutvikling den siste tiden. Flere, blant andre Ken Thompson, hevdet at det ikke hadde skjedd særlig mye nytt å skrive hjem om innenfor programmering de siste 20-30 årene. Vi hadde orntlig innovasjon på 60- og 70-tallet, men deretter har vi bare hatt mindre justeringer og forbedringer.

Det kan selvsagt hende noe av dette skyldes folks tendens til å tenke at "alt var bedre før", og at de gamle knarkene ikke har klart å henge med de siste årene. Men flere av intervjuobjektene sier også at veldig mange av de oppdagelsene de ser i dag er gjennoppdagelser av ting som er gjort før. Software-bransjen har utrolig dårlig hukommelse, og det er den viktigste grunnen til at jeg mener utviklere bør lese denne og lignende bøker. Ikke finn opp hjulet på nytt, ikke gjør de samme feilene som allerede har blitt gjort og dokumentert!

“Coders at Work should inspire readers to learn about the wider context of their craft and stop the reinvention of the proverbial wheel” —Vladimir Sedach from review at Slashdot

Heldigvis virker det nå som om folk begynner å få øynene opp for dette, og begynner å gå tilbake til røttene. Jeg vet i alle fall at jeg er på vei dit!

Øvrige personer som intervjues i Coders at Work:

Guy Steele: En ekte polyglot – var med å utvikle både Common Lisp og Scheme, og har også en finger med i standardiseringen av Fortran, C og ECMAScript, samt at han skrev den offisielle spesifikasjonen for Java. Steele spilte også en viktig rolle i Emacs' fødsel.

L Peter Deutsch: Begynte å programmere på 50-tallet (som 11-åring). Jobbet med Interlisp og Smalltalk VM'en hos Xerox PARC, hvor han var med og oppfant just-in-time kompilering. Står også bak Ghostscript.

Peter Norvig: Director of Research hos Google, tidligere Director of Search Quality, og før det forsket han for NASA.

Brendan Eich: Mannen bak JavaScript, og nå CTO i Mozilla Corporation.

Douglas Crockford: Senior JavaScript-arkitekt hos Yahoo!, oppfinner av JSON, og forfatter av boken JavaScript: The Good Parts, et must for dem som vil bruke JavaScript som et orntlig programmeringsspråk.

Jamie Zawincki: Lisp hacker som bl.a. utviklet Lucid Emacs (a.k.a. XEmacs) og jobbet på Unix-versjonen av Netscape.

Brad Fitzpatrick: Begynte å programmere som femåring, og står bak bl.a. LiveJournal, memcached og Perlbal.

Joshua Bloch: Chief Java Architect i Google, jobbet tidligere for Sun hvor han stod bak deler av Java (bl.a. Java Collections Framework).

Simon Peyton Jones: Sentral person i Microsoft Research, står bak standardiseringen av programmerinsspråket Haskell, og er arkitekt og sjefsutvikler på Glasgow Haskell Compiler (GHC).

Fran Allen: Eneste kvinne i boken. Fortran-guru og kompilator-pioner som jobbet for IBM Research i 45 år.

Bernie Cosell: Lisp-programmerer og master debugger. Hadde bl.a. en rolle i utviklingen av ARPANET – nettverket som ble Internett.

Donald Knuth: Kjent for The Art of Computer Programming, bibelen innen algoritmer og datastrukturer, som han har jobbet på de siste fire tiårene. Populariserte Big-O notasjon for algoritme-analyse, utvikler TeX og en metodikk han kaller litterær programmering.