| Titolo originale: | Teach Yourself Programming in Ten Years |
| Autore: | Peter Norvig |
| Versione originale: | http://norvig.com/21-days.html |
| Traduzione aggiornata al: | 12 Luglio, 2009 |
| A cura di: | Fabio Z Tessitore |
| Licenza: | Questo documento è pubblicato con il consenso dall'autore. |
Passeggiate in qualsiasi libreria, e vedrete come accanto a Impara Java in 7 Giorni sono presenti infinite variazioni sul tema che pretendono di insegnare Visual Basic, Windows, Internet e altro in pochi giorni o ore. Ho fatto la seguente ricerca di tipo power search su Amazon.com:
pubdate: after 1992 e title: days e
(title: learn o title: teach yourself)
e ho ottenuto 248 risultati. I primi 78 erano libri di informatica (il 79-esimo era Impara il Bengalese in 30 giorni). Ho allora sostituito days con hours ed ho ottenuto un risultato simile: 253 libri, di cui 77 di informatica seguiti da Impara la Grammatica e lo Stile in 24 ore alla 78-esima posizione. Dei primi 200, il 96% erano libri di informatica.
La conclusione è che le persone vanno molto di fretta quando devono imparare qualcosa sui computer, oppure che i computer sono qualcosa di favolosamente facile da imparare rispetto a qualsiasi altra cosa. Non ci sono libri su come imparare Beethoven, o la Fisica dei Quanti, o perfino l'Addestramento dei Cani in pochi giorni. Felleisen et al. accennano a questa tendenza nel loro libro How to Design Programs, quando dicono Programmare male è facile. Gli idioti possono impararlo in 21 giorni, anche se sono stupidi.
Proviamo ad analizzare cosa un titolo del tipo Impara il Pascal in Tre Giorni potrebbe significare:
In 3 giorni non avrete il tempo di scrivere alcun programma significativo, e con esso imparare dai vostri successi e sconfitte. Non avrete il tempo di lavorare con un programmatore esperto e capire com'è vivere in quell'ambiente. In breve, non avrete tempo di imparare molto. Quindi si può parlare di una familiarità superficiale, non di conoscenza profonda. Come disse Alexander Pope, un po' di sapere è pericoloso.
In 3 giorni potreste imparare la sintassi del Pascal (se già conoscete un linguaggio simile), ma non potrete imparare molto su come usare quella sintassi. In breve, se foste, diciamo, un programmatore Basic, potreste imparare a scrivere programmi in stile Basic usando la sintassi del Pascal, ma non potrete imparare per cosa il Pascal va bene (e non). Qual è il punto? Alan Perlis una volta disse: Un linguaggio che non influenza il modo di pensare la programmazione, non vale la pena conoscerlo. Una cosa possibile è che dovete imparare una piccola parte del Pascal (o più probabilmente, qualcosa del tipo Visual Basic o JavaScript) perché avete bisogno di interfacciarvi con qualcosa di esistente per portare a termine un compito specifico. Ma allora non state imparando a programmare; state imparando a completare quel compito.
Sfortunatamente, non è abbastanza, come la prossima sezione dimostra.
Alcuni ricercatori (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simon & Chase (1973)) hanno dimostrato che sono necessari circa dieci anni per sviluppare esperienza in una gran varietà di campi, inclusi il gioco degli scacchi, la composizione musicale, la pittura, il suonare il pianoforte, il nuoto, il tennis, le ricerche in neuropsicologia e in topologia. La chiave è la pratica intenzionale: non semplicemente farlo ancora e ancora, ma impegnarsi con un compito appena oltre le proprie abilità attuali, provare, analizzare il proprio rendimento mentre e dopo l'esecuzione, e correggere gli errori. Quindi ripetere. E ripetere ancora. Non sembrano esserci scorciatoie: anche per Mozart, che era un prodigio musicale a 4 anni, ci vollero altri 13 anni prima di iniziare a produrre musica di levello mondiale. In un altro genere, i Beatles sembrano comparire sulle scene con una #1 hits e un'apparizione nello show di Ed Sullivan nel 1964. Ma hanno suonato in piccoli club a Liverpool e Amburgo fin dal 1957, e nonostante siano piaciuti immediatamente, il loro primo grande successo, Sgt. Peppers, fu inciso nel 1967. Malcolm Gladwell riporta una ricerca su studenti dell'Accademia della Musica di Berlino in cui veniva comparato il migliore, il medio e l'ultimo terzo della classe e veniva chiesto loro quante ore avevano fatto pratica:
Tutti, di tutti i gruppi, avevano iniziato a suonare pressappoco alla stessa età - attorno ai cinque anni. Nei primi anni tutti hanno fatto pratica per lo stesso tempo - circa due o tre ore alla settimana. Ma verso gli otto anni iniziavano ad emergere le vere differenze. Gli studenti che risultavano essere i migliori del loro corso iniziarono a far pratica più degli altri: sei ore a settimana a nove anni, otto a dodici anni, sedici a settimana a quattordici anni, e sempre a salire, fino all'età di venti anni alla quale praticavano ben oltre le trenta ore settimanali. Dall'età di venti anni, l'elite aveva totalizzato 10.000 ore di pratica lungo il corso delle loro vite. Gli studenti bravi avevano totalizzato, a confronto, 8.000 ore, e i futuri insegnanti di musica appena sopra le 4.000 ore.
Quindi è 10.000 ore, non 10 anni, il numero magico. Samuel Johnson pensava ci volessero più di dieci anni: L'eccellenza in un campo qualsiasi può essere raggiunta solo attraverso il lavoro di una vita: non si può acquistare ad un prezzo inferiore. E Chaucer aggiunse La vita è così breve, l'arte così lunga da imparare. Ippocrate (c. 400 A.C.) è noto per la massima ars longa, vita brevis, che è parte della citazione più lunga Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile, che in Italiano suona come La vita è breve, l'arte lunga, l'occasione è fugace, l'esperienza ingannevole, il giudizio difficile. Sebbene in Latino, ars può significare sia arte che mestiere, nell'originale Greco la parola techne significa solo abilità, non arte.
Questa è la mia ricetta per avere successo nella programmazione:
Siate interessati alla programmazione, e fatene perché è divertente. Siate sicuri che sia sufficientemente divertente così da portarla avanti per dieci anni.
Parlate con altri programmatori; leggete altri programmi. È più importante di qualsiasi libro o corso.
Programmate. Il modo migliore di imparare è imparare facendo. Per essere più tecnici, il massimo livello di prestazioni per gli individui in un dato dominio non è automaticamente una funzione dell'esperienza generale, ma può essere incrementato anche dagli individui di grande esperienza come risultato di un deliberato sforzo per migliorare. (p. 366) e il modo migliore per imparare richiede un compito ben definito con un livello di difficoltà appropriato per l'individuo in questione, una retroazione informativa, e l'opportunità per la ripetizione e la correzione degli errori. (p. 20-21) Il libro Cognizione in Pratica: Mente, Matematica, e Cultura nella Vita di tutti i giorni è un riferimento interessante per questo punto di vista.
Se volete, frequentate un'università. Vi darà accesso ad alcuni lavori che richiedono credenziali, e vi darà una conoscenza più profonda del campo, ma se la scuola non vi piace, potete (con qualche attenzione) ottenere un'esperienza simile sul lavoro. In ogni caso, imparare solo dai libri non è abbastanza. L'educazione nella computer science non può rendere nessuno un programmatore esperto più che studiare pennelli e colori possa rendere qualcuno un pittore esperto dice Eric Raymond, autore di Il Nuovo Dizionario Hacker. Uno dei migliori programmatori che ho mai assunto aveva solo il titolo di Scuola Superiore; ha prodotto una gran quantità di ottimo software, ha un proprio newsgroup, e ha guadagnato abbastanza in stock options per comprarsi un proprio nightclub.
Lavorate su progetti insieme ad altri programmatori. Siate il miglior programmatore in alcuni progetti; siate il peggiore in altri. Quando sarete il migliore, potrete testare le vostre abilità di guidare un progetto, e ispirare gli altri con la vostra visione. Quando sarete il peggiore, imparerete cosa fanno i maestri, e cosa non piace fare loro (perché lo faranno fare a voi).
Lavorate su progetti dopo altri programmatori. Siate interessati a capire un programma scritto da qualcun altro. Capite cosa voleva capire e aggiustate quando il programmatore originale non è in giro. Pensate a come progettare i vostri programmi per renderli più semplici per quelli che li manterranno dopo di voi.
Imparate almeno una mezza dozzina di linguaggi di programmazione. Includete un linguaggio che supporti l'astrazione in classi (come Java o C++), uno che supporti l'astrazione funzionale (come Lisp o ML), uno che supporti l'astrazione sintattica (come Lisp), uno che supporti le specificazioni dichiarative (come Prolog o i template del C++), uno che supporti le coroutine (come Icon o Scheme), e uno che supporti il parallelismo (come Sisal).
Ricordate che c'è la parola computer in computer science. Dovete sapere quanto tempo occorrerà al vostro computer per eseguire un'istruzione, leggere una parola dalla memoria (con e senza una cache miss), leggere parole consecutive dal disco, e cercare in una nuova locazione di memoria sul disco. (Risposte.)
Siate impegnati nello sforzo di standardizzazione di un linguaggio. Potrebbe essere il comitato per l'ANSI C++, oppure potrebbe essere decidere se nel vostro stile ci saranno 2 o 4 spazi per ogni livello di identazione. In ogni caso, imparerete cosa, in un linguaggio, piace ad altre persone, come profondamente lo sentono, e forse perfino perché lo sentono così.
Abbiate il buon senso di tirarvi fuori dalla standardizzazione del linguaggio il prima possibile.
Tenendo a mente tutto ciò, è opinabile quanto lontano potrete arrivare imparando dai libri. Prima che il mio primo figlio nascesse, lessi tutti i libri della serie Come Fare, e ancora mi sentivo come un novizio senza speranza. 30 mesi dopo, quando nacque il mio secondo figlio, tornai indietro ai libri per una rinfrescata? No. Invece, mi rifeci all'esperienza personale, che risultò essere molto più utile e rassicurante per me rispetto alle migliaia di pagine scritte da esperti.
Fred Brooks, nel suo saggio No Silver Bullets (Niente Pallottole d'Argento) ha identificato un piano in tre parti per trovare grandi progettisti di software:
Identificare sistematicamente i migliori progettisti il prima possibile.
Assegnare un mentore responsabile per lo sviluppo del prospetto e tenere con cura un archivio della carriera.
Provvedere opportunità per progettisti in crescita di interagire e stimolarsi gli uni con gli altri.
Ciò assumendo che qualcuno già abbia le qualità necessarie per diventare un grande progettista; il lavoro consiste nel motivarli correttamente. Alan Perlis più succintamente: A chiunque può essere insegnato a scolpire: a Michelangelo si poteva insegnare come non farlo. Così è per i grandi programmatori.
Quindi andate avanti e comprate quel libro su Java; probabilmente ne farete un qualche uso. Ma non cambierete la vostra vita, o la vostra reale esperienza come programmatori in 24 ore, giorni, o anche mesi.
Bloom, Benjamin (ed.) Sviluppare il Talento nei Giovani, Ballantine, 1985.
Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.
Bryan, W.L. & Harter, N. "Studies on the telegraphic language: The acquisition of a hierarchy of habits. Psychology Review, 1899, 8, 345-375
Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.
Chase, William G. & Simon, Herbert A. Perception in Chess Cognitive Psychology, 1973, 4, 55-81.
Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.
Tempi approssimativi per varie operazioni su un tipico PC da 1GHz nell'estate 2001:
| esecuzione di una singola istruzione | 1 nsec = (1/1.000.000.000) sec |
| leggere una parola dalla cache L1 | 2 nsec |
| leggere una parola dalla memoria principale | 10 nsec |
| leggere parole da posizioni sul disco consecutive | 200 nsec |
| leggere una parola da una nuova posizione sul disco (seek) | 8,000,000 nsec = 8 msec |
Molte persone hanno chiesto quale linguaggio di programmazione dovrebbero imparare per primo. Non c'è un'unica risposta, ma considerate questi punti:
Riferitevi ai vostri amici. Quando qualcuno chiede Quale sistema operativo dovrei usare, Windows, Unix, o Mac?, la mia risposta normalmente è: usate quello che i vostri amici usano. Il vantaggio che ne avrete imparando dai vostri amici compenserà ogni differenza intrinseca tra SO, o tra linguaggi di programmazione. Considerate anche i vostri amici futuri: la comunità di programmatori di cui farete parte se continuerete. Il linguaggio da voi scelto ha una comunità larga e crescente o una piccola e in estinzione? Ci sono libri, siti web, e forum online da cui avere risposte? Vi piacciono le persone che partecipano a questi forum?
Restare sul semplice. I linguaggi di programmazione come il C++ e Java sono progettati per lo sviluppo professionale da parte di grandi gruppi di programmatori con esperienza che sono interessati all'efficienza in fase di run-time dei loro codici. Come risultato, questi linguaggi hanno parti complicate progettate per queste circostanze. Voi siete interessati ad imparare a programmare. Non avete bisogno di queste complicazioni. Per voi va bene un linguaggio progettato per essere facile da imparare e ricordare da un singolo nuovo programmatore.
Giocate. In che modo preferireste imparare a suonare il pianoforte: nel modo normale, interattivo, in cui sentite ogni nota appena premete un tasto, o nel modo batch, in cui potete sentire le note solo dopo che avete finito un'intera canzone? Chiaramente, il modo interattivo rende più semplice imparare a suonare il pianoforte, e lo stesso vale per la programmazione. Insistete su un linguaggio che consente il modo interattivo e usatelo.
Dati questi criteri, la mia raccomandazione per un primo linguaggio di programmazione è Python o Scheme. Ma le vostre circostanze possono cambiare, e ci sono altre buone scelte. Se la vostra età è a singola cifra, probabilmente preferirete Alice o Squeak (anche i più anziani potrebbero preferirli). La cosa importante è scegliere e partire.
Molte persone hanno chiesto da quali libri e pagine web dovrebbero studiare. Ripeto che imparare solo dai libri non è abbastanza ma posso consigliare i seguenti:
Struttura e Interpretazione di Programmi per Computer (Abelson & Sussman) è probabilmente la migiore introduzione alla computer science, e insegna a programmare come un modo per capire la computer science. Potete vedere i video online delle lezioni su questo libro, come pure il testo completo online. Il libro è una vera sfida e scoraggerà alcune persone che potrebbero avere successo con un diverso approccio.
How to Design Programs (Felleisen et al.) (in versione online) è attualmente uno dei migliori libri su come progettare programmi in modo elegante e funzionale.
Programmazione in Python: Un'introduzione alla Computer Science (Zelle) è una buona introduzione all'uso del Python.
Alcuni tutorial online sono disponibili sul sito Python.org.
Concepts, Techniques, and Models of Computer Programming (Van Roy & Haridi) è visto da alcuni come il successore moderno di Abelson & Sussman. È un tour attraverso le grandi idee della programmazione, copre un più grande intervallo rispetto a Abelson & Sussman mentre è più semplice da leggere e da seguire. Usa un linguaggio, Oz, non molto conosciuto ma utile come base per imparare altri linguaggi.
T. Capey ha fatto notare che la pagina Complete Problem Solver su Amazon ora ha i libri Impara il Bengalese in 21 giorni e Impara la Grammatica e lo Stile nella sezione Utenti che hanno acquistato questo libro hanno anche acquistato questi oggetti. Immagino che la maggior parte delle persone che guardano il libro provengano da questa pagina. Grazie a Ross Cohen per il suo aiuto con Ippocrate.
CulturaHacker.it