steve's

Perche’ i bambini devono imparare a programmare

Dic
18

Mi sono avvicinato al tema “applicazioni didattiche del digitale” per ragione emotive, estetiche. Cioè perché mi affascinava l’idea. Non avevo nessuna conoscenza e nessuna competenza. Venivo da studi classici e da una laurea in Filosofia. Fine anni ottanta.

Ho comprato un PC (senza sistema operativo) e ho cercato di vedere quello che si poteva fare. Ho letto il leggibile, ho riflettuto, ho sperimentato.

Il primo risultato della riflessione è stato: per usare i computer per l’educazione bisogna prima capire cosa è l’educazione. E prima ancora, cos’è l’apprendimento, visto che l’educazione si suppone serva a migliorare e favorire l’apprendimento.

Sono arrivato (attraverso Dewey e altre letture) all’idea che l’apprendimento non è un fenomeno di introiezione di informazioni, ma nemmeno di costruzione di strutture mentali. E’ una ristrutturazione dell’ambiente, proprio quello esterno. Nel mondo reale è difficile farlo; l’ambiente educativo è invece uno spazio/tempo progettato apposta per permettere questa ristrutturazione, e per gestirla insieme a chi apprende. Ristrutturazione che si scontra con limiti, che vengono spinti sempre più oltre. Ma che nel mondo fisico, ben presto diventano ostacoli insormontabili.

A questo punto viene in aiuto il digitale, che ha molti meno limiti. Come parte di un ambiente educativo, gli artefatti digitali (programmi, dispositivi) devono essere costruiti in modo da facilitare questa modifica dell’ambiente. Devono essere modificabili da chi li usa. Quindi come minimo si deve dare all’utente (ma che brutta parola!) la possibilità di capire come cambiarli per adeguarli. Quindi interfacce riconfigurabili a piacere, modalità operative che si possono incrementare.

L’attività di modifica di un oggetto digitale in generale si chiama programmazione. E a differenza della modifica degli oggetti fisici non ha praticamente limiti.

Quest’attivita è – o dovrebbe essere – la maniera fondamentale, in un ambiente educativo, per interagire con il software. Qualsiasi software: che sia un gioco o un programma di videoscrittura (sono i campi dove ho fatto un po’ di esperimenti), o per fare calcoli, o simulazioni, etc etc. E i software devono essere costruiti in modo da permetterlo, a diversi livelli. Tecnicamente e legalmente. Trascinando pannelli o programmando.

 

L’obiettivo non è imparare a programmare, né per assicurarsi un futuro, né per sviluppare abilità logico-matematiche. L’obiettivo è imparare meglio con strumenti che sono pensati apposta per questo.

Creative computing from scratch

Dic
13

Scratch è ormai diventato una moda. Quando si parla di “coding”, di programmazione per bambini, si parla inevitabilmente di Scratch. Questa equazione mi infastidisce un po’, come se non si potesse giocare con la programmazione in altro modo, come se Scratch avesse una patente speciale e tutto il resto non fosse mai esistito. Questo naturalmente non è colpa di Scratch e dei suoi creatori, ma è una miopia tutta nostra. Probabilmente in Italia non è chiaro nemmeno il significato del nome: “scratch” è la linea di partenza di una corsa. Costruire qualcosa “from scratch” significa cominciare da zero.

Penso di fare un servizio utile provando a fare un po’ di chiarezza intorno al tema, all’oggetto Scratch e al suo modello didattico. Credo che chiunque voglia organizzare un pomeriggio di gioco con Scratch – ma come ho già scritto in precedenza, non basta un pomeriggio – dovrebbe almeno riflettere un po’ su questi argomenti.

 

Perché Scratch? Cosa ha di particolare? Almeno due aspetti mi sembrano alla base della sua fortuna. Ed entrambi meritano analisi e discussione.

  1. Il fatto che intorno a Scratch ci sia una comunità internazionale. Scratch è una “online community where children program and share interactive stories, games, and animations”. Bisogna quindi essere necessariamente connessi per programmare? In realtà esiste un editor offline, basato su Adobe Air. E’ una scelta strana per il MIT; né Adobe Air né l’editor offline sono OpenSource (a differenza di quasi tutti gli altri ambienti dello stesso genere). Non ho idea di quanti usino la versione offline, talmente è più facile utilizzare la versione online. In ogni caso c’erano, e ci sono ancora, anche altre comunità dello stesso genere. Quasi ognuno degli ambienti di programmazione per bambini ha un team di sviluppo che mantiene un sito con esempi, suggerimenti, guide. La comunità intorno a Scratch è la più recente, probabilmente la più attiva, non necessariamente la più interessante. Potrebbe valere la pena andare a curiosare anche nelle altre.
  2. Il fatto che non sia necessario scrivere codice sorgente (il che è piuttosto curioso, visto l’uso continuo del termine “coding”). La questione è rilevante. Uno dei passaggi chiave nella storia degli ambienti di programmazione per bambini è proprio il passaggio dalla scrittura di codice alla programmazione visuale. Significa che invece di scrivere “if questo then quest’altro” il programmatore deve trascinare oggetti grafici, disporli in un certo ordine, e scrivere solo dati all’interno di buchi (le variabili). La sintassi è affidata alla posizione degli oggetti, la semantica alla scrittura. Ci sono enormi vantaggi: il rischio di commettere errori di sintassi è annullato, la struttura del codice è rappresentata in forma visuale ed è più comprensibile con uno sguardo d’insieme. Si introduce però uno iato forte tra l’attività presente (visuale) e quella futura (scrittura). Infatti gli ambienti di programmazione visuale per adulti professionisti sono piuttosto pochi, dedicati di solito a domini specifici come il multimedia e, nel 99% dei casi, un programmatore scrive o modifica codice scritto. Ci sono degli evidenti vantaggi anche nell’uso della scrittura: un codice scritto in qualsiasi epoca e in qualsiasi linguaggio può essere modificato con un editor di testo (se la licenza lo permette). E abituarsi a leggere e rileggere, vale per un testo scritto in una lingua naturale come per un codice sorgente, non è un’attività poco utile nella vita.

Scratch nasce al MIT nel 2003 con un grant della NSF, in collaborazione con diverse altre università statunitensi (Pennsylvania, Harvard, Washington e altre). Tra i ringraziamenti, vengono citati Seymour Papert e Alan Kay, ovvero l’autore del LOGO e uno degli inventori della programmazione orientata agli oggetti e delle finestre, nonché di Squeak, Etoys e Tweak.

La storia degli ambienti di programmazione per bambini – in cui Scratch affonda le radici – è infatti molto lunga. A partire dal LOGO (1967 !) e i suoi derivati (StarLogo/NetLogo, 1999) passando per ToonTalk (1992), Stagecast Creator  (1996),  SmallTalk/Squeak/ (1996), Etoys (1997), Alice (1999),  fino al recente AppInventor per Android (2010). Una lista completa la trovate qui: http://en.wikipedia.org/wiki/Visual_programming_language.

Ognuno ha delle particolarità interessanti. Ad esempio Alice era basata sul modello della programmazione orientata agli oggetti, NetLogo sugli agenti concorrenti, Stagecast Creator sulle programmazione per regole. Sono tutti modelli alternativi alla programmazione “imperativa” (che è la più vecchia, quella in cui si comanda il computer con istruzioni e test, IF_THEN_ELSE), modelli che oggi sono studiati ed adottati su larga scala.

L’autorità principale dietro Scratch, Mitch Resnik (LEGO professor al MIT Media Lab), parla degli obiettivi del progetto in questi termini: “Quando qualcuno impara a programmare con Scratch impara allo stesso tempo importanti strategie per risolvere problemi, creare progetti e comunicare le proprie idee.” Le stesse idee sono espresse nella guida del 2011 pubblicata dall’Università di Harvard (http://scratched.gse.harvard.edu/sites/default/files/CurriculumGuide-v20110923.pdf). La guida è una miniera di idee e contenuti, declinati in 20 sessioni didattiche. Nell’introduzione si dice fra l’altro:

“Engaging in the creation of computational artifacts prepares young people for more than careers as computer scientists or as programmers. It supports young people’s development as computational thinkers – individuals who can draw on computational concepts, practices, and perspectives in all aspects of their lives, across disciplines and contexts.”

Il pensiero computazionale (traduzione dubbia; ma in questi casi è difficile resistere al calco) è quindi visto come una maniera di affrontare i problemi della vita, attraverso concetti come sequenze, cicli, parallelismo, eventi, condizioni, operatori e dati. Le pratiche che vengono incoraggiate come più adatte sono “essere iterativi e incrementali, verificare e correggere, riusare e mescolare, astrarre e modulare”.

Da un lato questa visione mi attrae, dall’altra devo confessare un po’ di spavento. Davvero i problemi reali vanno affrontati in termini di algoritmi formalizzabili? Davvero le azioni nei complessi contesti quotidiani vanno regolate in funzione di condizioni, operatori e dati? I bambini devono giocosamente imparare a comportarsi nella vita come automi perfettamente informati?

Persino l’idea dell’introduzione giocosa alla programmazione, per preparare i futuri sviluppatori di cui avremo bisogno nei prossimi dieci anni, andrebbe esaminata un po’ di più prima di essere accettata come una verità incontestabile. Non solo perché nel comparto informatico ci serviranno molte figure professionali diverse dagli sviluppatori; e non solo perché la programmazione richiede tanta creatività nell’inventare quanta abilità nel portare a termine l’idea.

Il punto centrale, il fulcro, è la strategia didattica.

Che “chi impara prima, impara meglio”, sembra essere un proverbio uscito dalla saggezza popolare, e quindi poco discutibile. Per diventare un musicista, un ballerino, un calciatore, un cantante, bisogna cominciare da bambini. Vale anche per le lingue straniere, vale anche per la matematica. Lo sappiamo per esperienza. Vale anche per la programmazione dei computer? Beh, qui troppi dati statistici non ci sono, dobbiamo procedere per analogia; e le analogie vanno tenute sotto controllo perché tendono a sfuggire.

Come si insegna ad un bambino una materia complessa, composta di tecnica e conoscenze, senza che le difficoltà impediscano i progressi?

Tradizionalmente, abbassando il livello della qualità richiesta, semplificando gli obiettivi, ma lasciando intatti gli elementi e le regole. Non si insegna ad una bambina di sei anni a suonare il violino con uno strumento con due sole corde, ma con un violino ¾, che ha la stessa complessità di uno 4/4 . Ma c’è una sterminata letteratura didattica composta per guidare lo studente dal facile al difficile. Non si semplifica il contesto, si modulano le richieste. La strategia didattica è lineare: c’è una gradazione infinita di modi di far vibrare una corda, e chi apprende procede lungo questo sentiero infinito. Limiti: la bambina si annoia, soprattutto se non capisce dove la porterà questa lunga strada, perché i risultati iniziali non sono troppo incoraggianti. Finirà probabilmente per abbandonare.

C’è un altro modo, più moderno: si crea un ambiente “didattico”, semplificato, in cui elementi e regole sono ridotti rispetto all’originale. Un flauto con i tasti invece dei fori; un toy piano diatonico. Qui i risultati gradevoli si raggiungono presto, la motivazione è rafforzata.

Questi giocattoli educativi non sono in continuità con il mondo reale. C’è una cesura netta: da un lato il giocattolo, dall’altro lo strumento vero, da un lato gli spartiti colorati, dall’altro i pentagrammi.

Questa strategia è senz’altro più efficace per iniziare, è più “democratica”, ha successo nella quasi totalità dei casi. Non serve a preparare musicisti professionisti, ma a comunicare l’amore per la musica (per esempio, io ho cominciato a suonare su un pianoforte giocattolo, e da allora amo disturbare il vicinato con ogni tipo di strumento – per questo vivo in campagna). E’ molto chiaro che non c’è un passaggio graduale dal modo “semplificato” a quello “avanzato”. Sono due mondi diversi, che si assomigliano in alcune parti, ma che non sono in connessione diretta. Alcuni degli studenti arrivati ai confini di uno si affacceranno sull’altro, si accorgeranno che la complessità è enormemente più elevata, ma decideranno di entrare lo stesso; altri si fermeranno nel primo mondo, come ho fatto io.

Tra gli ambienti di programmazione per bambini, però, alcuni sono stati pensati proprio come un raccordo, una via di mezzo tra i giocattoli e le cose serie. Sono ambienti dinamici, modificabili, evolutivi, in cui il bambino può iniziare in un contesto semplice e poi aggiungere complessità fino ad arrivare all’editor testuale di codice sorgente che è identico a quello del programmatore professionista. Questo è uno dei motivi per cui gli oggetti digitali sono più potenti di quelli fisici.

Ora, quali sono gli obiettivi di Scratch? Apparentemente, due: preparare futuri programmatori e iniziare i bambini all’amore per il computational thinking.

E la strategia didattica dietro Scratch, di quale delle due categorie delineate sopra fa parte? Direi della seconda, visto che l’ambiente che si propone è giocoso, facile, divertente, ma non ha le stesse regole del “mondo adulto” della programmazione. Non si scrive e legge codice. Non ci si preoccupa della correttezza sintattica. Non ci si preoccupa dell’efficienza, della velocità, della comprensibilità, della standardizzazione, dello stile, etc etc. Non c’è niente di male, come non c’è niente di male in un toy piano. Ma solo nei fumetti Schroeder suona Beethoven con quello.

Il problema nasce proprio quando si immagina che entrambi gli obiettivi possano essere raggiunti con una sola strategia, ovvero quando questa differenza di approcci strategici non viene proprio percepita,  cioè quando si pensa che iniziare a programmare con Scratch sia solo il gradino più basso di una scala che porta, gradualmente, alla produzione dei software che usiamo ogni minuto. E questo è tipicamente un errore di chi non ha una grande esperienza della programmazione.

Programmare non è solo un po’ più difficile di creare un gioco con Scratch, è enormemente più complesso; come realizzare un film o registrare un concerto non è solo un po’ più difficile di girare un video con uno smartphone.

Personalmente ho visto tanti bambini (studenti, figli, figli di amici) giocare con ambienti di programmazione fatti apposta per costruire giochi. Di tutti questi, solo uno, che io sappia, ha avuto la voglia e la costanza di continuare. Gli altri, quando hanno capito che programmare è difficile, si sono arresi e sono tornati a giocare.

____

Ci sono infine alcune domande che credo sia importante porsi quando si inizia un progetto didattico con Scratch.

1. Possono condurre un curriculum (nel senso di un progetto didattico) basato su Scratch anche docenti che non sono informatici di estrazione? Non è ovvia la risposta. Nel senso che le competenze tecniche per usare e far usare Scratch sono ovviamente molto basse. Ma non avere il background necessario potrebbe essere un limite grosso quando si cerca di espandere le idee e i concetti di Scratch e applicarle al mondo quotidiano (gli smartphone, il web, i programmi per PC). Non significa che solo i laureati in informatica possono condurre un laboratorio Scratch. Servono competenze pedagogiche, capacità di giocare insieme ai bambini e competenze informatiche.

2. Le idee dietro Scratch hanno una lunga storia, quasi tutta scritta negli Stati Uniti, quindi legata a quel modello educativo e sociale. Possiamo prenderle in prestito così come sono o possiamo/dobbiamo pensare ad un adattamento europeo e italiano? Ad esempio, se il peso delle attività di scrittura/lettura è diverso nei curricula statunitensi e italiani dei primi anni scolastici, non dobbiamo tenerne conto?

3. Perché dobbiamo sempre ricominciare “from scratch”? Ci sono, in tutto il mondo, migliaia di esperienze di introduzione alla programmazione con altri linguaggi e ambienti, in Italia almeno a partire dagli anni ’80. Possiamo ritrovarli, studiarli, verificarne i risultati? Potremmo, ad esempio, andare a vedere quali effetti hanno avuto nel tempo sui bambini coinvolti (quanti hanno scelto l’informatica come professione, quanti riconoscono un valore a quelle esperienze)?

Insomma, mi sembra che ci sia ancora tanto da fare e tanto su cui riflettere.

Google e la ginestra

Dic
07

Sentito ieri alla radio:

– “Adesso Giovanni vi darà l’indirizzo del sito di cui stiamo parlando”

– “Ok, Carla, è www…”

– ” No, dai, basta andare su Google e scrivere…”

La URL – il nome del sito – è diventata praticamente ininfluente. Se devo visitare il sito di Repubblica non perdo tempo a scrivere l’indirizzo preciso (http://www.repubblica.it) ma scrivo “repu” nello spazio degli indirizzi del browser, e se prima non viene autocompletato usando la mia cronologia arriva la pagina di Google che riporta repubblica.it come primo risultato. Clicco e via. E’ comodo, più veloce. Non mi devo ricordare esattamente come si scrive, non devo impicciarmi con dettagli ridicoli come il dominio di primo livello (it org com net) o il prefisso del protocollo (http ftp smtp …).

Nella lontana era del pregoogliano inferiore le cose erano diverse. Come erroneamente si dice ancora nella pagina di Wikipedia italiana dedicata al World Wide Web:

“La visione di una pagina web inizia digitandone la URL nell’apposito campo del browser web oppure cliccando su un collegamento ipertestuale presente in una pagina web precedentemente visualizzata o in altra risorsa come ad esempio un’e-mail. Il browser web a quel punto dietro le quinte inizia una serie di messaggi di comunicazione con il web server che ospita quella pagina con lo scopo di visualizzarla sul terminale utente.”

Non è più così. Si dovrebbe correggere come segue:

“La visione di una pagina web inizia digitandone un pezzo del titolo nell’apposito campo del browser web. Il browser web a quel punto invia la stringa a Google, che acquisisce l’informazione (ad esempio per profilare l’utente), cerca nei suoi database e fornisce una lista di URL che contengono o sono collegati a quella stringa. Cliccando su uno dei link proposti, il browser dietro le quinte inizia una serie di messaggi di comunicazione etc etc.”

Non voglio qui entrare nella questione delle informazioni – a volte non necessarie – regalate a Google. Mi interessa una questione più “filosofica” collegata a questa piccola pigrizia: ho l’oggetto e lo specchio, ma guardo solo lo specchio. Come se lo specchio – ogni specchio – non fosse deformante. Al punto poi da dimenticarmi dell’oggetto. Al punto magari da rimanere preda di ridicoli trappole via mail (“clicca qui”: ma qui dove? dove punta questo link?).

Nel mondo ci sono le cose: alberi, pianeti, libri, film. Poi ci sono le rappresentazione delle cose, di cui una parte importante è costituita da insiemi di parole sulle cose: gli articoli di giornale, le recensioni dei film, le chiacchiere al bar, i commenti nei blog, i tweets.

Sono due tipi di cose diversi. In alcuni casi la differenza è netta: la pianta della ginestra è una cosa, una foto di una ginestra un’altra. In altri è più complicato, in particolare quando le “cose” sono esse stesse dei testi, e ancora di più quando esiste una versione digitale di questi testi che è accessibile via Internet. Per esempio, la Ginestra (il poema leopardiano) è una cosa (una copia digitale la si trova qui: http://it.wikisource.org/wiki/Canti_%28Leopardi_-_Donati%29/XXXIV._La_ginestra); la pagina di Wikipedia sulla Ginestra (http://it.wikipedia.org/wiki/La_ginestra) o le parafrasi ad uso scolastico (come http://www.oilproject.org/lezione/leopardi-la-ginestra-parafrasi-pessimismo-leopardiano-3662.html) sono un’altra cosa.

Nel senso che hanno autore diverso, dicono cose diverse, sono state scritte per scopi diversi. Cose che si usano diversamente, che soddisfano bisogni diversi. Se devo leggere la Ginestra mi serve il testo originale; se devo sapere cosa si è detto nel tempo di quel componimento, mi servono i commenti dei critici. Magari ci sono occasioni in cui mi servono entrambi, o uno può supplire all’altro (poniamo, perché devo scrivere un tema per l’ora di Italiano di domattina e sono un po’ in affanno). Ma restano due cose diverse e potrei volere l’una o l’altra separatamente, non mescolate tutte insieme in migliaia di risultati.

Ora a Google (ma varrebbe per qualsiasi altro motore di ricerca) non posso segnalare questa differenza di intenzione, non posso scegliere. Posso decidere che voglio trovare qualcosa sulla Ginestra, e posso persino dire in che formato: voglio un testo o un’immagine o un video o una mappa. O persino un libro (more>books). Ma sto sempre cercando “cose che si riferiscono a”, non “la Ginestra” in sé.

Prima di internet, se cercavo una cosa, voleva dire che mi interessava quella cosa (diciamo l’originale) e magari andavo in biblioteca o in libreria a cercare le opere complete di Leopardi; se invece volevo sapere cosa la gente dice di quella cosa andavo a cercare un manuale di storia della Letteratura, o una rivista di Italianistica, o andavo a lezione. Ora ho la possibilità di accedere a quasi tutte queste cose da casa tramite un unico canale (compresa magari la lezione su qualche MOOC). Ma l’impressione che ho è che non si faccia più la differenza, tanto che è anche difficile per me scriverne e farmi capire.

All’origine c’è il fatto che un motore di ricerca prende la stringa di caratteri che gli forniamo e la confronta con quello che ha nel database. Ed è normale che ci siano molti più record di pagine che parlano della Ginestra che non recordi di copie digitali dell’originale. E che di originali ne basta uno, mentre di commenti che ne possono essere milioni. E che l’originale (la copia del testo originale) non è marcata in maniera diversa dal resto.

Ma il punto è che questa configurazione tecnica ha portato ad un’abitudine mentale nuova. Non si parla qui della questione generica “internet e i cellulari allontanano i giovani dal mondo reale”, perché qui non è questione di età – Google lo usiamo semplicemente tutti – ma del fatto che l’enorme massa di informazioni disponibili ha reso inevitabile l’uso di un motore di ricerca, e che la maniera di funzionare di questo ha talmente cambiato le nostre abitudini da renderci indifferenti alla distinzione tra quello che diciamo di una cosa e la cosa stessa.

Certo è difficile sostenere che la ginestra abbia un’esistenza indipendente da quello che pensiamo e diciamo di essa. Il tavolo di Berkeley ci ricorda che non abbiamo un accesso privilegiato alla realtà. E si, non sapremo mai se l’uomo è andato davvero sulla Luna e se la guerra in Iraq ha davvero avuto luogo, perché abbiamo solo rappresentazioni di questi eventi. Ma resta il fatto che in un contesto normale sappiamo distinguere abbastanza bene tra cosa e rappresentazione, in ogni caso abbastanza da sopravvivere. Normalmente sappiamo distinguere senza pericolo tra un’esplosione in cielo (di un fuoco di artificio) e un film di guerra, tra le Operette Morali e un manuale di liceo, tra una foto del giardino in primavera e un rametto in un vaso. Dovremmo ugualmente saper distinguere, ed essere interessati a farlo, tra una versione digitale di una poesia e tutto quello che è stato detto su di essa. Come dovremmo saper distinguere tra un indirizzo internet e le informazioni che Google ci restituisce a proposito di quell’indirizzo.

Ma temo che questo piccolo artificio dei motori di ricerca favorisca (ancora di più) una visione generica che non è interessata a distinguere tra gli ordini delle cose, che non è interessata al confronto e alla valutazione personale, che assume tutto come originale. Con quel che ne consegue.