| Titolo originale: | Teach Yourself Programming in Ten Years |
| Autore: | Peter Norvig |
| Versione originale: | http://norvig.com/21-days.html |
| Traduzione a cura di: | Fabio Z Tessitore |
Passeggia in qualsiasi libreria e vedrai 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 addirittura ore. Ho fatto la seguente ricerca 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 studiare Beethoven, 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 C++ in Tre Giorni potrebbe significare:
In 3 giorni non avrai il tempo di scrivere alcun programma significativo e con esso imparare da successi e sconfitte. Non avrai il tempo di lavorare con un programmatore esperto e capire com'è vivere nell'ambiente C++. In breve, non avrai 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 potresti imparare la sintassi del C++ (se già conosci un altro linguaggio), ma non potrai imparare molto su come usare quel linguaggio. In breve, se fossi, diciamo, un programmatore Basic, potresti imparare a scrivere programmi in stile Basic usando la sintassi del C++, ma non potresti imparare per cosa il C++ 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 di essere conosciuto. È possibile che debba imparare una piccola parte del C++ (o più probabilmente, qualcosa del tipo JavaScript o Flash) perché hai bisogno di interfacciarti con qualcosa di esistente per portare a termine un compito specifico. Ma allora non stai imparando a programmare; stai imparando a completare quel compito.
Sfortunatamente non è sufficiente, come dimostra la prossima sezione.
Alcuni ricercatori (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & 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 telegrafia, 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 in un compito appena oltre le proprie abilità, 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 hit 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 della vita. Gli studenti bravi avevano totalizzato, a confronto, 8.000 ore, e i futuri insegnanti di musica appena sopra le 4.000 ore.
Quindi potrebbe essere 10.000 ore, non 10 anni, il numero magico. (Henri Cartier-Bresson (1908-2004) disse Le tue prime 10.000 fotografie saranno le peggiori, ma lui ne scattava più di una all'ora). Samuel Johnson (1709-1784) pensava ci volesse anche di più: 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 (1340-1400) aggiunse La vita è così breve, l'arte così lunga da imparare. Ippocrate (c. 400 AC) è 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:
Interessati alla programmazione, e fanne perché è divertente. Assicurati che sia sufficientemente divertente così da portarla avanti per dieci anni/10.000 ore.
Programma. Il modo migliore per 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 Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life è un riferimento interessante.
Parla con altri programmatori; leggi altri programmi. È più importante di qualsiasi libro o corso.
Se vuoi, frequenta un'università. Ti darà accesso ad alcuni lavori che richiedono titoli e ti darà una conoscenza più profonda del campo, ma se la scuola non ti piace, puoi (con qualche attenzione) ottenere un'esperienza simile lavorando. In ogni caso imparare solo dai libri non è sufficiente. Lo studio della 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 de 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.
Lavora su progetti insieme ad altri programmatori. Sii il miglior programmatore in alcuni progetti; sii il peggiore in altri. Quando sarai il migliore potrai testare le tue abilità di guidare un progetto e ispirare gli altri con la tua visione. Quando sarai il peggiore imparerai cosa fanno i maestri, e cosa non piace fare loro (perché lo faranno fare a te).
Lavora su progetti dopo altri programmatori. Comprendi un programma scritto da qualcun altro. Capisci cosa voleva capire e aggiusta laddove il programmatore originale non c'è. Pensa a come progettare i tuoi programmi per renderli più semplici per quelli che li manterranno dopo di te.
Impara almeno una mezza dozzina di linguaggi di programmazione. Incluso un linguaggio che supporta l'astrazione in classi (come Java o C++), uno che supporta l'astrazione funzionale (come Lisp o ML), uno che supporta l'astrazione sintattica (come Lisp), uno che supporta le specificazioni dichiarative (come Prolog o i template del C++), uno che supporta le coroutine (come Icon o Scheme), e uno che supporta il parallelismo (come Sisal).
Ricorda che c'è la parola computer in computer science. Devi sapere quanto tempo occorre al tuo computer per eseguire un'istruzione, leggere una parola dalla memoria (cache e non), leggere parole consecutive dal disco e cercare in una nuova locazione di memoria sul disco. (Risposte)
Impegnati nello sforzo di standardizzazione di un linguaggio. Potrebbe essere il comitato per l'ANSI C++, oppure potrebbe essere decidere se nel tuo stile ci saranno 2 o 4 spazi per ogni livello di identazione. In ogni caso, imparerai cosa, in un linguaggio, piace ad altre persone, come profondamente lo sentono e forse perfino perché lo sentono così.
Abbi il buon senso di tirarti fuori dalla standardizzazione del linguaggio il prima possibile.
Tenendo a mente tutto ciò, è opinabile quanto lontano puoi arrivare imparando solo 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 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.
Tutto ciò assumendo che qualcuno ha già le qualità necessarie per diventare un grande progettista; il lavoro consiste nel motivarlo 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. Perlis dice che i migliori hanno un talento che prescinde dall'allenamento. Ma da dove viene questo talento? È innato? O viene sviluppato con la diligenza? Auguste Gusteau (lo chef di Ratatouille) dice: tutti possono cucinare, ma solo gli impavidi possono essere grandi. Penso sia volontà di dedicare una larga parte della propria vita alla pratica. Ma forse impavidi è un termine per sintetizzare questo concetto. Oppure, come dice Anton Ego, il critico di Gusteau: Non tutti possono diventare grandi artisti, ma un grande artista può venir fuori da ovunque.
Quindi vai avanti e compra quel libro su Java/Ruby/Javascript/PHP; probabilmente ne farai un qualche uso. Ma non cambierai la tua vita, o la tua reale esperienza come programmatore in 24 ore, giorni, o anche settimane. Che succede lavorando sodo per 24 mesi? Bene, adesso sei partito ...
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.
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:
| esecuzione di una tipica istruzione | 1/1.000.000.000 sec = 1 nanosec |
| leggere dalla cache L1 | 0.5 nanosec |
| predizione di flusso errata | 5 nanosec |
| leggere dalla cache L2 | 7 nanosec |
| Mutex lock/unlock | 25 nanosec |
| leggere dalla memoria principale | 100 nanosec |
| inviare 2KB su una rete 1Gbps | 20.000 nanosec |
| leggere 1MB sequenzialmente dalla memoria | 250.000 nanosec |
| leggere da una nuova posizione sul disco (seek) | 8.000.000 nanosec |
| leggere 1MB sequenzialmente dal disco | 20.000.000 nanosec |
| inviare pacchetti dagli USA all'Europa e viceversa | 150 millisec = 150.000.000 nanosec |
Svariate persone hanno chiesto quale linguaggio di programmazione dovrebbero imparare per primo. Non c'è un'unica risposta, ma considera questi punti:
Riferisciti ai tuoi amici. Quando qualcuno chiede Quale sistema operativo dovrei usare, Windows, Unix o Mac?, la mia risposta normalmente è: usa quello che i tuoi amici usano. Il vantaggio che ne avrai imparando dai tuoi amici compenserà ogni differenza intrinseca tra SO, o tra linguaggi di programmazione. Considera anche gli amici futuri: la comunità di programmatori di cui farai parte se continuerai. Il linguaggio 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? Ti piacciono le persone che partecipano a questi forum?
Resta sul semplice. I linguaggi di programmazione come 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. Tu sei interessato ad imparare. Non hai bisogno di queste complicazioni. Andrà bene un linguaggio progettato per essere facile da imparare e ricordare da un singolo programmatore.
Gioca. In che modo preferiresti imparare a suonare il pianoforte: nel modo normale, interattivo, in cui senti ogni nota appena premi un tasto, o nel modo batch, in cui puoi sentire le note solo dopo che hai finito un'intera canzone? Chiaramente il modo interattivo rende più semplice imparare a suonare il pianoforte e lo stesso vale per la programmazione. Insisti su un linguaggio che consente il modo interattivo e usalo.
Dati questi criteri, la mia raccomandazione per un primo linguaggio di programmazione è Python o Scheme. Ma le circostanze possono cambiare e ci sono altre buone scelte. Se la tua età è a singola cifra probabilmente preferirai Alice o Squeak (anche i più anziani potrebbero preferirli). La cosa importante è scegliere e partire.
Svariate persone hanno chiesto da quali libri e pagine web dovrebbero studiare. Ripeto che imparare solo dai libri non basta ma posso consigliare i seguenti:
Structure and Interpretation of Computer Programs (Abelson & Sussman) è probabilmente la migiore introduzione alla computer science; e insegna a programmare come un metodo per capire la computer science. Puoi 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) è uno dei migliori libri su come progettare programmi in modo elegante e funzionale.
Python Programming: An Introduction to Computer Science (Zelle) è una buona introduzione che usa il 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