absorbeo.net

maintained by André Reffhaug (andrer *AT* opera *DOT* com)

Lær deg selv programmering på 10 år

Norsk oversettelse av Peter Norvigs essay Teach yourself programming in 10 years

Hvorfor har alle det så travelt? Ta en tur inn i en hvilken som helst bokbutikk, og du vil se Lær deg Java på 7 dager ved siden av et variert utvalg bøker som tilbyr seg å lære deg Visual Basic, Windows, Internett, og så videre på bare et par dager eller timer. Jeg gjorde det følgende søket på Amazon.com:

De første 78 treffene var databøker (nummer 79 var Lær deg Bengali på 30 dager). Jeg byttet ut "dager" med "timer" og fikk like bemerkelsesverdige resultater: 253 bøker til, med 77 databøker, etterfulgt av Lær deg selv gramatikk og stil på 24 timer på nummer 78. Av de 200 første treffene var 96% databøker.

Konklusjonen er at enten har folk det utrolig travelt med å lære om datamaskiner, eller så er det mye lettere å lære om datamaskiner enn alt annet. Det finnes ingen bøker som reklamerer med at de på et par dager vil lære deg om kvantefysikk, hunde- stell eller hvordan spille Beethoven.

La oss analysere hva en tittel som Lær deg Pascal på tre dager kan bety: På tre dager har du ikke tid til å skrive flere store programmer, og lære av din suksess eller feil med dem. Du har ikke tid til å arbeide sammen med en som har lang erfaring med programmering, og forstå hvordan det er å arbeide i et slikt miljø. Kort sagt, du har ikke tid til å lære stort. Det de snakker om kan bare være en overfladisk kjennskap, ikke en dyp forståelse. Som Alexander Pope sa, "litt lærdom kan være farlig."

Pascal: På tre dager kan du kanskje ha tid til å lære deg syntakset til Pascal (forutsatt at du allerede kjenner til et liknende språk), men du har ikke tid til å lære deg hvordan bruke dette nye syntakset. Kort sagt, hvis du for eksempel kjente til Basic, kunne du lære deg å skrive Pascal programmer i Basic-stil, men du kunne ikke lære deg hva Pascal faktisk er godt (og dårlig) egnet for. Så, hva er poenget? Alan Perlis sa en gang: "Et språk som ikke påvirker hvordan du tenker på programmering er det ikke verdt å kjenne til." Et mulig poeng kan være at du trenger å lære deg litt Pascal (eller mest sannsynlig noe som Visual Basic eller JavaScript) fordi du trenger å interface med et eksisterende verktøy for å oppnå noe veldig spesifikt. Men da lærer du deg ikke hvordan du skal programmere; da lærer du hvordan du skal oppnå akkurat dette spesifikke.

På tre dager: Dette er dessverre ikke nok, som det neste avsnittet viser. Lær deg programmering på ti år-forskere (Hayes, Bloom) har vist at det tar omtrent ti år å utvikle ekspertise i ett av mange forskjellige felt, blant annet sjakkspill, musikk komposisjon, maling, pianospill, svømming, tennis, og forskning innen nevropsykologi og topologi. Det ser ikke ut til å finnes noen ordentlige snarveier. Selv Mozart, som var et musikalsk vidunderbarn allerede som fireåring brukte 13 år til før han begynte å lage musikk i verdensklasse. Beatles, i en annen sjanger, så ut til å komme ut av intet med en rekke nummer 1 hit'er og en opptreden på the Ed Sullivan show i 1964. Men de hadde spilt på en rekke små klubber i Liverpool og Hamburg siden 1957, og selv om de hadde bred appell fra starten av, ga de ikke ut sin første kritikerroste suksess, Sgt. Peppers, før i 1967. Samuel Johnson mente at det tar lenger tid enn ti år: "Utmerkelse innen et felt kan man bare oppnå gjennom et livs arbeid; det kan ikke kjøpes billigere." Og Chaucer klagde: "Livet er så kort, og kunsten tar så lang tid å lære."

Her er min oppskrift for suksess innen programmering: Bli interessert i programmering, og gjør det fordi det er moro. Sørg for at det fortsetter å være såpass moro at du er villig til å vie 10 år til det.

Snakk med andre som programmerer; les andre programmer. Dette er viktigere enn en hvilken som helst bok eller treningskurs.

Programmér. Den beste måten å lære på er å lære mens du gjør. For å si det mer teknisk, "det maksimale ytelsesnivået for et invidivid innenfor et gitt felt oppnås ikke automatisk som en funksjon av utvidet erfaring, men ytelsesnivået kan økes selv av svært erfarne individer som et resultat av mål- rettede forsøk på å forbedre seg." (s. 366) og "den mest effektive læringen krever en veldefinert oppgave med et passende vanskelighetsnivå for det individuelle menneske, informativ tilbakemelding, og muligheter for repetisjon og retting av feil." (s. 20-21). Boken "Cognition in Practice: Mind, Mathematics and Culture in Everyday Life" er en interessant kilde for dette synspunktet.

Hvis du har lyst kan du bruke fire år på universitetet (eller mer). Dette vil gi deg tilgang til endel jobber som krever papirer, og det vil gi deg en dypere forståelse av feltet. Men hvis du ikke liker skolen, kan du (med litt vilje) få liknende erfaringer. Uansett, boklærdom alene kommer ikke til å være nok. "Informatikk-utdannelse kan gjøre deg til en programmeringsekspert like mye som å studere pensler og pigment kan gjøre deg til en god maler" sier Eric Raymond, forfatter av "The New Hacker's Dictionary." En av de beste programmererne jeg noensinne har ansatt hadde bare vitnemål fra videregående skole; han har laget mange gode programmer, har sin egen nyhetsgruppe, og er, gjennom aksjer, uten tvil mye rikere enn jeg noen- sinne kommer til å bli.

Arbeid på prosjekter sammen med andre som kan programmere. Vær den beste programmereren på noen prosjekter, vær den verste på andre. Når du er den beste får du testet evnene dine til å lede et prosjekt, og til å inspirere andre med din visjon. Når du er den dårligste lærer du hva mesterne gjør, og du lærer hva de ikke liker å gjøre (fordi du blir nødt til å gjøre det for dem).

Arbeid på prosjekter etter andre som kan programmere. Forsøk å forstå programmer skrevet av andre. Se hva som skal til for å forstå og reparere programmer når de som først skrev dem ikke er tilgjengelige lenger. Tenk på hvordan du bør legge opp programmene dine, slik at det blir lettere for de som arbeider på det etter deg.

Lær deg et godt knippe forskjellige språk. Inkluder ett språk som støtter klasse-abstraksjoner (som Java eller C++), ett som støtter funksjonell abstraksjon (som Lisp eller ML), ett som støtter syntaktisk abstraksjon (som Lisp), ett som støtter deklarative spesifikasjoner (som Prolog eller C++ templates), ett som støtter ko-rutiner (som Icon eller Scheme), og ett som støtter parallellisme (som Sisal).

Husk at for å programmere bruker du en datamaskin. Vit hvor lang tid det tar datamaskinen din å utføre en instruksjon, hente et "word" fra minnet (både med og uten en cache-bom), lese påfølgende "words" fra disken, og søke til en ny plass på disken. (Svar her.)

Involver deg i arbeidet med å standardisere et språk. Det kunne være ANSI C++ komiteen, eller det kunne være å avgjøre hvorvidt du selv skal bruke 2 eller 4 mellomrom for å indente koden din. Uansett, du lærer om hva andre folk liker ved et språk, hvor dypt de føler nettopp dette, og kanskje også litt om hvorfor de føler det slik.

Vær smart nok til å hoppe av arbeidet med å standardisere et språk så fort som mulig. Med alt dette i bakhodet er det verdt å stille seg selv spørmålet om hvor langt du kommer med bare boklærdom. Før mitt første barn ble født leste jeg all "Hvordan..." og følte meg fremdeles som en rådvill nybegynner. 30 måneder senere, da mitt andre barn ble født, gikk jeg tilbake til de bøkene? Nei. Isteden stolte jeg på min personlige erfaring, som viste seg å være langt mer brukbar og betryggende enn de tusen sidene skrevet av eksperter.

Fred Brooks identifiserte, i essayet "No Silver Bullets" en trestegs-plan for å finne gode programmerere:

Identifiser de flinke designerne så tidlig som mulig.

Sørg for at noen følger opp den du har funnet og sørg for at man fører papirer på vedkommende.

Gi designere i vekst muligheter til å snakke med og stimulere hverandre.

Dette er under antakelsen av at enkelte mennesker allerede har kvalitetene som trengs for å gode designere. Jobben er å hjelpe dem på veien så godt som mulig. Alan Perlis sa det bedre: "Alle kan lære seg å lage en skulptur: Michelangelo måtte man lære hvordan ikke å lage en skulptur. Slik er det også med gode programmerere."

Så bare kjøp den Java-boken; du får sikkert noe brukbart ut av det. Men du kommer ikke til å forandre livet ditt, eller din ekspertise, på 24 timer, dager, eller selv måneder.

Referanser: Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.

Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.

Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.

Omtrentlige svar

---

timing for forskjellige operasjoner på en typisk 1GHz PC, sommer 2001:

Etterord - språkvalg:

---

Mange har spurt meg om hvilket programmeringsspråk de burde lære seg først. Det finnes ikke noe enhetlig svar, men tenk på disse tre poengene:

Bruk vennene dine. Når noen spør meg "Hvilket operativsystem burde jeg bruke, Windows, Unix eller Mac?", er mitt svar vanligvis: "Bruk det vennene dine bruker." Fordelen du får av å lære av vennene dine er større enn forskjellen i språk eller operativsystem. Tenk også på dine fremtidige venner: fellesskapet av programmerere som du vil bli en del av hvis du fortsetter med programmering. Har språket du valgte deg en stor og voksende fremtid, eller er det i ferd med å dø? Finnes det bøker, web-sider og forum du kan få svar fra? Liker du menneskene i disse forumene?

Gjør det enkelt. Programmeringsspråk som C++ og Java er designet for profesjonell utvikling av store teams som er opptatt av effektiviteten av koden sin. Som et resultat av dette har disse språkene kompliserte deler laget nettopp for slikt bruk. Du er opptatt av å lære deg å programmere. Du trenger ikke noe så komplisert. Du trenger et språk som er lett å huske og bruke for en ensom programmerer.

Lek! Hvordan vil du helst lære å spille piano? Den normale, interaktive måten, hvor du hører hver note så snart du trykker ned en tangent, eller i "batch" mode, hvor du hører notene når du har spilt ferdig hele sangen? Den interaktive måten er helt klart den letteste måten å lære piano på, og det samme gjelder programmering. Insister på et språk med en interaktiv læreprosess, og bruk det. Gitt disse kriteriene er min anbefaling for et første programmeringsspråk enten Python eller Scheme. Men dine omgivelser kan variere, og det finnes andre gode valg. Hvis du har en alder med bare ett tall i, ville du kanskje like Alice eller Squeak (eldre elever kan også like disse). Det viktigste er at du velger og kommer igang.

Etterord nummer to - bøker og andre ressurser:

---

Flere har spurt meg hvilke bøker og websider de burde lære fra. Jeg gjentar at boklærdom ikke er nok, men kan anbefale følgende:

Scheme: Structure and Interpretation of Computer Programs (Abelson & Sussman) er antakeligvis den beste introduksjonen til informatikk, og den lærer bort programmering som en måte å forstå informatikk på. Du får også videoer av foredragene gratis på internett. Boken er utfordrende, men kan kanskje luke ut noen mennesker som kanskje bør tilnærme seg problemet på en annen måte.

Scheme: How to Design Programs (Felleisen et al.) er en av de beste bøkene om hvordan du faktisk skal designe på en elegant og funksjonell måte.

Python: Python Programming: An Intro to CS (Zelle) er en god introduksjon til informatikk med bruk av Python.

Python: Mange gode tutorials på Python.org

Oz: Concepts, Techniques, and Models of Computer Programming (Van Roy & Haridi) blir av mange ansett for å være den moderne arvtageren til Abelson & Sussman. Det er en tur gjennom programmeringens store idéer, med et bredere spektrum enn Abelson & Sussman, samtidig som den er lettere å lese og følge. Den bruker et språk, Oz, som ikke er godt kjent, men som brukes for å lære andre språk.

Originalartikkel av Peter Norvig Innholdet er copyrightet av nevnte forfatter.