Digi Tales

Costruire teorie sperimentali con il Coding

Nov
07

Tra le tante ragioni usate per giustificare la pratica (anticipata) del Coding, quella che mi pare più sensata per la scuola è la possibilità che viene data agli studenti di costruire in maniera sperimentale una teoria di un dominio. Per esempio: come funziona il ciclo dell’acqua? Perché a volte i semi germogliano ma poi si seccano? Quando va usato il congiuntivo?

Costruire una teoria significa capire, ma capire ad un livello diverso da “apprendere una regola o una formula”. Costruire in maniera sperimentale significa arrivare un po’ alla volta alla teoria giusta, provando modi diversi di mettere in relazione parametri e vedendo immediatamente, sensibilmente, il risultato.

Questo modo di apprendere è reso possibile dall’esistenza dei computer, nella loro essenza di artefatti digitali programmabili, e dalla loro accessibilità per gli studenti. Esistono esempi meravigliosi di simulazioni digitali  in campi diversi, ma che di solito hanno il difetto di essere chiuse, cioè non programmabili. Si riesce a intuire quali sono le regole in gioco, a verificarne le relazioni, ma non a formalizzarle.

Il coding ha senso in questo contesto a patto di avere presente dove si va a parare fin dall’inizio, e a patto di non fermarsi ai primi passi. E’ praticabile in tempi ragionevoli se si hanno a disposizione degli ambienti programmabili non vuoti, cioè in cui le regole del dominio sono già cablate. E’ utile se dopo la fase di scoperta e costruzione della teoria in un ambito limitato si passa alla sua estensione e riapplicazione in altri domini.

Passo 1. Se creo una storia animata usando un programma di disegno, che permette di aggiungere suoni e musiche e di muovere sprites sullo schermo, sto facendo quello che potrei fare a mano, con infinita fatica e molti più errori, disegnando su una pellicola. Quella storia avrà sempre lo stesso svolgimento non importa quante volte la esegua. Per creare la storia devo aver già chiare le regole dell’ambiente.
Cosa sto imparando? Ad usare certi strumenti, punto. Se programmo questa storia, sto imparando ad usare altri strumenti e concetti (ripetizione, spostamento) ma niente di più.

Passo 2. Se invece ho un ambiente dinamico, in cui succedono delle cose (immaginiamo un gioco: arrivano mostri, si presentano nuovi ostacoli etc) e devo muovere manualmente un personaggio, quello che succede dipende dalle mie azioni e ogni volta è diverso. Se il mostro si avvicina troppo, mi mangia. Ma se sta esattamente sopra di me, in verticale, gli posso sparare. Che invece di spostare il personaggio manualmente utilizzando un joystick, un mouse o un touchscreen io possa scrivere un comando per spostarlo non cambia molto le cose, ma è un primo passo.
Cosa sto imparando qui? A individuare i parametri e a stimare intuitivamente i valori di soglia di questi parametri cui devo reagire. Bene, ma ancora non basta.

Passo 3. Il tutto diventa interessante solo quando riesco a programmare il personaggio non in modo che esegua sempre lo stesso movimento, ma in modo che esegua un movimento diverso in funzione della situazione.

Senza scomodare l’intelligenza artificiale, posso definire delle semplici regole:

  1. se c’è un mostro nella linea di tiro, spara
  2. se il mostro si avvicina troppo, spostati verso l’area dove ci sono meno mostri

Bisogna definire cos’è la linea di tiro, quanto è grande e come si verifica la sicurezza di un’area, eccetera. Cosa si sta imparando qui? A costruire una strategia che sia buona in qualsiasi situazione. Per costruire la strategia bisogna non solo individuare i parametri dell’ambiente più significativi ma anche definire in maniera precisa i valori di soglia, e poi stabilire le azioni migliori per far fronte alla situazione definita dal superamento di quei valori, cioè bisogna costruire una teoria. Il fatto che io debba programmare questa strategia mi obbliga a formalizzarla e a verificarla. La possibilità di rappresentarla in un codice sorgente mi permette di discuterla con gli altri, di rivederla in un momento successivo, di correggerla, di generalizzarla.

Non è tanto importante l’apprendimento delle tecniche di programmazione – che però sono funzionali alla costruzione della teoria e alla sua verifica immediata – , quanto il fatto che questo approccio permette di affrontare domini (che tradizionalmente mi chiederebbero di imparare in maniera fideistica certe nozioni, per esempio che l’accelerazione di gravità sulla Terra è 9,8 m/s) in una maniera costruttiva, esperienziale e collaborativa. Posso sperimentare direttamente la relazione tra certe cause e certi effetti, come potrei fare anche nel mondo reale se avessi risorse a sufficienza o se potessi accelerare o rallentare il tempo (come faceva Galilei). Il fatto che la mia teoria sia scritta in una forma eseguibile facilità sia la verifica immediata, sia il confronto con gli altri.

Per esempio, ho un seme. Se c’è sole e acqua, il seme germoglia e nasce un fiore. Se c’è acqua, ma non sole, il seme germoglia ma non nasce il fiore. Se c’è sole, ma non acqua, il fiore crepa. I parametri qui sono luce e umidità; i valori soglia li devo scoprire. E poi devo trovare le azioni che permettono al mio seme di fornire la performance migliore (innaffiare, drenare, coprire, illuminare). Se riesco a programmare queste azioni significa che ho costruito una teoria dell’ambiente. Non: ho costruito una teoria perché avevo imparato le regole, ma: costruendo una teoria ho capito le regole.

Ci sono infinite applicazioni possibili. Papert ha pensato alla geometria piana, ma si può spaziare dalla fisica alla biologia, dalla storia alla grammatica, dalla musica alla lingua due. Forse all’inizio potrà sembrare bizzarro concepire lo studio della lingua in maniera sperimentale, ma niente lo vieta. L’importante è che ci siano delle regole che producono effetti (diacronici o sincronici) e che queste regole si possano inserire in un ambiente che ne mostra gli effetti. E’ vero che le “regole” in ambito linguistico hanno tantissime eccezioni, mentre la fisica ci ha abituato a situazioni più lineari; ma si può immaginare una lingua artificiale senza eccezioni dove si possa sperimentare in assenza di attrito, o un universo fantastico dove le carestie portino inevitabilmente alle guerre. In fondo, la geometria euclidea o la logica aristotelica sono nate con la stessa idea di fare astrazione dai dettagli reali per arrivare più facilmente ai concetti e alle regole chiave.

Far costruire agli studenti un ambiente del genere partendo da zero è troppo complesso. Per farlo bisognerebbe sapere in anticipo quali sono i parametri fondamentali e la loro relazione, che invece dovrebbe essere l’obiettivo dell’attività. Sarebbe molto meglio avere a disposizione un ambiente con le sue regole già cablate (ma ispezionabili, o addirittura modificabili), che però mi permettesse di programmare le azioni con cui interagisco con l’ambiente. Che so: un ambiente in cui la relazione tra massa e peso è definita, in cui però il tempo si possa rallentare a piacere o la resistenza dell’aria azzerare.

Passo 4. Non si tratta di ricostruire tutto il sapere a forza di esperimenti. Una volta capito il meccanismo dell’elaborazione di teorie, si può cercare di capire se esistono delle invarianti che mi permettono di applicare uno schema che ha funzionato una volta anche in situazioni diverse. Per far questo, devo catalogare i miei schemi in funzioni delle caratteristiche delle situazioni che ne suggeriscono l’applicazione. Naturalmente questa è la parte più difficile. Ma la fase metacognitiva (cosa abbiamo scoperto? come potremmo riusarlo) è altrettanto importante di quelle precedenti e la competenza nell’applicazione di schemi a situazioni nuove è in fondo l’obiettivo che giustifica tutta l’educazione.

Passo 5. Inoltre gli schemi si possono rendere più potenti, grazie ad elaborazioni formali (generalizzazioni, trasformazioni). Qui forse vale la pena non provare a inventare tutto, ma sfruttare le esperienze di quelli che hanno già studiato e sperimentato prima di noi. Ma si inverte l’ordine tradizionale: prima si capisce, sperimentando in un ambiente semplificato e controllato,  quali sono le regole di fondo, e solo dopo si imparano i trucchi che permettono di riapplicarle in maniera estesa e rapida. Non mi si chiede di imparare prima i prodotti notevoli e poi, forse, capire a cosa mai possono servire, ma il contrario.

Serve necessariamente un computer e un ambiente di programmazione semplificato per praticare questo tipo di didattica? No, certo. Ma senza un ambiente digitale programmabile questo approccio sarebbe talmente difficile e lungo che in pratica si finisce per non applicarlo quasi mai.

 

 

Oltre il giardino. Del codice.

Ott
29

Presidente: Lei è d’accordo con Ben? Pensa che possiamo stimolare la crescita con incentivi temporanei?
Chance: Fintanto che le radici non sono recise, va tutto bene, e andrà tutto bene, nel giardino.

Il surreale film del 1979 “Being there” (in Italiano “Oltre il giardino”) interpretato, come si dice, magistralmente da Peter Sellers è troppo noto per doverne fare un riassunto. Il film parla della volontà di trovare modelli a tutti i costi, del ruolo della televisione, del vuoto di valori e di altro.
Ma a me piace soprattutto la metafora del giardino. O meglio, quella che tutti – tranne Chance Gardiner – interpretano come una metafora dello Stato e della sua cura.

Qui da me tutti hanno un casa col giardino. Però il rapporto col giardino (e anzi con la natura in generale) è molto diversificato. Almeno tre categorie sono facilmente riconoscibili:
1. estetica: prato inglese, statue, alberi di rappresentanza (magnolia)
2. funzionale: orto + frutteto, niente verde inutile
3. negazionista: cemento e muri; poi eventualmente vasi
Solo che io non mi ritrovo in nessuna di queste categorie. E si vede dal fatto che tutti quelli che passano guardano, scuotono la testa e mi dicono gentilmente: “Ma ti serve aiuto per tagliare tutta questa boscaglia?” La boscaglia in questione sarebbe il mio giardino. Che è fatto di tante piante diverse, ognuna con una storia, una curiosità, un modo di crescere e di lottare con le altre, una personalità, uno stile. Ci sono tracce di piante precedenti, promesse di piante future. Alcune le ho portate io da lontano, altre me le hanno regalate, altre sono nate da sole. Piante che mi ricordano persone, luoghi, momenti.

Qualche tempo fa mi sono accorto che anche per il rapporto con il digitale valgono più o meno le stesse categorie di sopra: chi lo vede come un accessorio di moda, chi come un utile strumento, chi fa finta che non esista. Non c’è possibilità di dialogo tra queste visioni così diverse, e ognuno guarda il giardino dell’altro con disprezzo nemmeno troppo celato.
Poi c’è chi il giardino non lo vuole per niente, ma è felice di visitare quello degli altri. Più in generale, si potrebbe dire che ci sono i nomadi-cacciatori-raccoglitori, che navigano e prendono quello che gli serve, e gli stanziali-allevatori-coltivatori, che circoscrivono uno spazio e ne controllano lo sviluppo. I primi hanno uno sguardo, come dire?, grandangolare; i secondi montano un macro. Oppure: lo sguardo dei nomadi percepisce le differenze, quello dei coltivatori le crea (un po’ come lo sguardo di Ciclope, avete presente?).
All’interno di questa metafora, programmare è coltivare alberi digitali. I programmi, come gli alberi, sono organismi che se va tutto bene crescono, si sviluppano. Hanno una vita propria (ebbene si) e a volte non fanno quello che uno si immaginava che facessero. Restano piccoli, o esplodono all’improvviso; intrecciano le radici con altri alberi, sfruttano lo stesso terreno, si fanno ombra tra loro. Gli alberi, come i programmi, anche quando muoiono vengono riusati per fare altro, da noi o da altri organismi. Si riproducono con i semi, o, al limite, diventano humus per altri alberi.
Nella coltivazione dei programmi non si parte dal nulla: infatti gli alberi non si seminano, si piantano alberelli giovani (e si, c’è la questione dell’opensource…). O meglio, veramente qualcuno molto bravo e un po’ presuntuoso lo fa, ma è difficile e lungo scriversi tutto da zero; più facile utilizzare librerie, interpreti e compilatori.
I programmi si potano: si tolgono rami secchi, o si indirizza lo sviluppo in una certa direzione, per avere una certa forma finale o per avere un certo quantitativo di frutti. Si innestano con rami di altre specie perché la struttura deve essere robusta e resistente. Si curano le malattie, si eliminano i parassiti (i bug…).

Non è facile coltivare un albero. La difficoltà più grande non è la tecnica spicciola (tagliare, zappare intorno alle radici) ma la visione d’insieme. Per esempio io ho piantato un acero troppo vicino alla casa e troppo vicino ad un giovane castagno. Per i primi quattro cinque anni, l’acero è restato più o meno uguale. Poi improvvisamente ha cominciato a crescere. Il risultato è che il castagno, che è più lento, è cresciuto storto cercando sole e aria, e l’acero fa ombra ai pannelli solari sul tetto. Ma quando ho piantato il giovane acero era alto quaranta centimetri, me l’ero riportato da una passeggiata nello zaino. Ora sarà alto quindici metri e non accenna a fermarsi. Non ho saputo “vederlo” da grande, nel contesto dello sviluppo del resto del giardino. Gli esperti me l’avrebbero detto subito: non lì. Oppure dovevo tagliargli la cima dopo due-tre anni per farlo allargare più in basso.
La progettazione e lo sviluppo di un software ha le stesse difficoltà. Bisogna impostare la struttura in modo che sia solida e resistente, scegliendo il linguaggio o il framework adeguato, andando a vedere cosa hanno fatto gli altri nei loro giardini. Poi bisogna sapere vedere in avanti, immaginarlo crescere, decidere da che parte piegarlo, tagliare delle aree morte o che daranno fastidio ad altri software. E durante tutta la sua vita bisogna tenerlo pulito dai bug, controllare che non ci siano vermi che ne rodono il tronco, parassiti che inseriscono uova che esploderanno più avanti.

A che serve coltivare alberi? Beh, dipende. Alcuni sono belli, altri fanno ombra, altri portano frutti o legna.
A chi va insegnato a coltivare alberi? In linea di principio, a tutti; come tutti, secondo me, dovrebbero saper scrivere un racconto, disegnare o suonare uno strumento. Perché è fonte di un piacere immenso – quello di vedere un organismo crescere – e perché permette di condividerlo con gli altri.
Bisogna essere professionisti, avere un giardino perfetto? No, non tutti. Basta anche un limone sul terrazzino. Ma essere in grado di apprezzare un albero quando lo si vede, quello si; e non solo “uh quant’è bello”, ma saper vedere attraverso e indietro, cos’è, da dove viene, come è cresciuto, come crescerà.

E la programmazione? Anche quella va insegnata a tutti i bambini? Qui bisogna stare attenti a quello che si scrive, e siccome ne ho scritto pure troppo altrove, passo. Qui mi accontento della metafora, che è utile quando fa riflettere da un punto di vista nuovo e suggerisce idee.

Però anche in questo caso mi ritrovo (spesso) ad essere l’unico appassionato dalla boscaglia digitale e a partecipare amorevolmente a tutta la complessità dei suoi organismi, piantando qui, potando là, e poi godendomi il risultato. Non lo faccio (più) in maniera quotidiana, nel senso che intervengo solo marginalmente nelle scrittura di codice sorgente, che scrive chi è molto più bravo di me. Mi appunto ancora delle idee, o ripesco degli schemi di anni fa in attesa del momento in cui ci sarà tempo e risorse per applicarli. Vado in giro a curiosare per i vivai e riporto qualcosa a casa; oppure immagino giardini che poi altri dovranno coltivare.

Chi passa mi dice ancora: ma vuoi una mano per cancellare tutto questo pasticcio? Ma non era meglio fare il rivenditore di Moodle?

Monitoraggio, brutta parola

Ott
09
Sul sito Programma il Futuro sono scaricabili dei report sui dati sulle attività svolte nel primo (http://programmailfuturo.it/media/docs/Rapporto-monitoraggio-settembre-2014-gennaio-2015.pdf) e nel secondo anno di progetto (http://programmailfuturo.it/media/docs/evento-celebrativo/programma_futuro-MIUR-26mag2015.pdf). Numero di ore, numero di insegnanti per regione e per disciplina, numero di classi e studenti coinvolti, e poi gradimento, valutazioni, osservazioni, tutti corredati di grafici. Dati raccolti in parte grazie a Google Analytics (altrimenti perché si attiva ogni volta che apro una pagina in Code.org?) e in parte grazie a questionari.
Questa cosa mi solletica.
Dieci anni fa, quando lavoravo a Scienze della Comunicazione, ho fatto una ricerca sui forum del corso concorso per dirigenti scolastici di INDIRE (2006). Siccome la piattaforma usata non prevedeva nessun tipo di monitoraggio fine (e peraltro non esisteva più…), siamo partiti da una copia del DB Oracle e siamo riusciti a ricostruire i profili, le conversazioni, i temi, le modalità comunicative. Il risultato principale è stato forse però l’insieme di query SQL che avrebbero permesso di analizzare allo stesso modo i dati di altri forum che usavano la stessa struttura dati, ad esempio per vedere se c’erano invarianti legate alla dimensione geografica, all’età, alle esperienze pregresse. Non mi risulta che siano stati mai usati, ma pazienza.
Cinque anni dopo, il MIUR ci affidò una ricerca per valutare il risultato di tre piani di formazione nazionali. La cosa anche qui fu piuttosto difficile, perché non c’erano dati originali, ovvero il progetto delle attività non contemplava la raccolta di dati prima, durante e dopo. Sono stati analizzati fondamentalmente i risultati di questionari somministrati ai docenti. Il che come si può immaginare non è la stessa cosa di avere accesso alle informazioni primarie.
Nella recente formazione per gli Animatori Digitali del Lazio, che mi ha coinvolto solo come tecnico fornitore di piattaforme, ho proposto di impostare un piano di monitoraggio all’inizio delle attività. Non per valutare nessuno, ma perché quando domani qualcuno arriverà a chiedersi se e come ha funzionato avrà bisogno di qualche informazione in più rispetto ad un sondaggio finale.
 
Insomma la fatica per ottenere dei risultati di qualche qualità mi pare inversamente proporzionale alla lungimiranza di chi gestisce un progetto. Se poi i dati raccolti (naturalmente anonimizzati) venissero resi disponibili come opendata (oltre alle elaborazioni in PDF), si potrebbe lasciare a chi ne ha voglia e competenze il compito di far emergere qualche idea buona (qui ho esagerato, vabbè).
 
Se ogni attività di coding fosse preceduta da una raccolta di informazioni (chi è il docente, che competenze ha, che lavori sono stati fatti con quella classe in precedenza) e magari da un test di ingresso, se durante le ore di coding si potesse registrare lo scambio tra gli studenti e con il docente o il processo di acquisizione di nuove forme sintattiche, se le attività fossero seguite da un test finale, se se se… ci sarebbero alla fine dati su cui riflettere. Anche senza avere per forza la pretesa di dimostrare che il coding serve (o non serve) ad un obiettivo specifico.
Magari verrebbero fuori delle connessioni a cui non si era pensato. Per esempio, l’influenza della famiglia o dell”ambiente sociale, o della lingua materna; il peso delle competenze informatiche del docente (o delle dimensioni dello schermo, o del tempo atmosferico, o del segno zodiacale del docente, o che so io). O magari non viene fuori niente. Ma senza quei dati non si saprà mai. Non mi sto inventando i Learning Analytics: se ne occupa tanta gente, la Microsoft nell’accordo con il Ministero dell’Educazione Nazionale Francese ha specificato che il suo intervento sul coding prevede anche questo tipo di attività di monitoraggio e analisi dei dati (http://cache.media.education.gouv.fr/file/Partenaires/17/7/convention_signee_506177.pdf, pag 4). Se lo fa Microsoft, a qualcosa servirà, no?
 
Quello che voglio dire non è tanto che ci deve essere un quiz alla fine che ci permetterà di dire se Mario ha imparato il pensiero computazionale (o uno strumento di analisi degli elaborati come DrScratch, http://drscratch.org/, – grazie Massimo per la segnalazione – che pure potrebbe essere utile); ma che una Piano Nazionale dovrebbe dotarsi dall’inizio di un protocollo e di strumenti per valutare la qualità di quello che fa, e non solo la quantità e le opinioni. Se Google ha costruito la sua fortuna sull’analisi dei testi e dei comportamenti della popolazione mondiale, ci sarà pure una ragione. Che, nel nostro caso, non è poter vendere pubblicità e servizi mirati, ma valutare globalmente un piano nazionale (non il coding), e per una volta non a posteriori.
E’ un suggerimento per il terzo anno…

Non di solo coding

Set
16

logo_GC

L’Associazione Gessetti colorati, con la collaborazione del CESEDI – Città metropolitana di Torino – nell’ambito delle sue attività di formazione, organizza due incontri aperti:

Giovedì 29 Settembre h 17:00 – 19:30 a PAVONE Canavese
c/o  Sala S. Marta

e

Venerdì 30 settembre Settembre h 9:30 – 12:30 a TORINO
c/o la sede del CESEDI – Via Gaudenzio Ferrari, 1

sul tema:

La necessità della cultura digitale: non di solo coding

Un confronto critico (ma non polemico) sul digitale, sul ruolo del coding e sul PNSD.

Si parlerà  tra l’altro di:

  • Necessità della cultura digitale per la formazione della cittadinanza: non di solo coding (R. Marchisio) (PAVONE, TORINO)
  • Dietro il coding. Significato, storia, usi possibili e poco immaginabili (S.Penge) (PAVONE, TORINO)
  • La paura dell’algoritmo.  Coding, gadgeting e formazione docenti (E. Pantò) (PAVONE)

Ne discuteranno con il pubblico:
Rodolfo Marchisio – ex insegnante – formatore e autore, collabora con Istoreto su temi di Cittadinanza digitale
Eleonora Pantò – ricercatrice presso CSP – Innovazione nelle ICT, Direttrice Associazione Dschola
Stefano Penge – esperto di software e piattaforme per la didattica, docente presso Università La Sapienza di Roma

Per informazioni: info@gessetticolorati.it  o rodolfo.marchisio@istoreto.it

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.

Cos’e’ la programmazione

Nov
15

Dopo la lettura di un articolo di El País (tradotto e ripubblicato sul Venerdì di Repubblica di questa settimana) sul recupero dei giovani cinesi videogame-dipendenti, in cui si cerca di spiegare  il desiderio dei diciassettenni maschi, figli unici di dipendenti pubblici, di perdersi nei meandri virtuali di un universo dove finalmente qualcuno ne riconosca le qualità facendo ricorso alla eccessiva durezza dell’educazione familiare tradizionale e il poco affetto ricevuto, ho capito finalmente cos’è la programmazione. Un attimo di pazienza e lo dico anche a voi.

Il (anche la, certo, ma molto più spesso il) programmatore è un tizio che passa molte ore davanti ad un  monitor. Però va detto che quando ha un problema da risolvere continua a pensarci ininterrottamente, anche se visto da fuori sta facendo altro, come mangiare o dormire o parlare con voi. Non è un teorico, non cerca l’intuizione essenziale, ma proprio la soluzione pratica. E  dopo averla trovata ne subisce l’incantamento narcisistico e  la raffina e ritocca e la ottimizza finché qualcuno non lo scuote e lo invita  a passare ad altro.

Non ama lavorare in batteria, ma gli piacciono i team stretti dove spalla a spalla si arriva più in alto, come nelle piramidi umane del circo.

Il programmatore costruisce universi,  dà un nome alle cose e le porta all’esistenza. Stabilisce genealogie, crea discendenze e parentele. Ma disegna anche gli scenari dove questi nuovi enti dovranno dispiegare le loro azioni. Storia, geografica, fisica: tutto dipende da lui, niente gli sfugge, o almeno così pensa.

Perché il programmatore sente il bisogno irrefrenabile di controllare l’universo che ha costruito, di cui è l’unico Demiurgo. E non si contenta di stare a guardare da fuori: lancia il programma in modalità debug  e lo segue, letteralmente passo dopo passo, anzi lo spia, fino a immaginarsi avatar,  di qua e di là dello schermo (“per ora va bene, ho tutto quello che mi serve, ora vado avanti, vediamo che succede”). Cerca il bug, ma non con lo spirito dell’entomologo, piuttosto come un regista che impersoni  direttamente sulla scena un personaggio per vedere cos’è che non funziona delle sue battute.

Cosa farebbe se non potesse programmare? come darebbe sfogo a questa esigenza viscerale, forse infantile, di possedere un universo tutto suo, sicuro,  senza imposizioni esterne, senza competizioni, senza delusioni e tradimenti?

Programmare è il suo modo di soddisfare questo bisogno, tutto sommato senza fare troppi danni, almeno paragonati a quelli che combina chi si mette in testa di fondare un impero. E’ un’attività riconosciuta come socialmente utile, perciò si viene anche pagati – limitatamente. Mentre si evita che il disturbo esploda, si ottengono anche sottoprodotti, a volte pregevoli, detti “programmi”.

Insomma, è chiaro: la programmazione è una terapia.

Che significa Code Week? (in difesa della conoscenza della lingua del digitale)

Ott
18

C’è una certo fastidio diffuso, per lo meno tra i miei amici e conoscenti, per l’esterofilia linguistica e gli stranierismi (leggi anglicismi, leggi meglio americanismi) usati nell’universo educativo.

Ci sono due aree linguistiche fondamentali che sono responsabili di questo male endemico: il business (americanismo) e l’informatica (“computer science” da noi non ha attecchito). In entrambi i casi si tratta di parole che viaggiano insieme ai discorsi, ed entrambi questi discorsi sono nati e si sono sviluppati da sempre in ambiente angloamericano.

Che questi due discorsi, insieme alle loro parole-vessillo, si impongano anche in un ambito diverso, quello educativo, è in effetti un problema grave. Pensare l’educazione in termini di competitività, di target, di budget, è indice di un più generale assetto di valori che si può criticare. Usare le parole dell’informatica in lingua originale anche dentro la scuola forse è meno grave perché finora non si è assistito ad un ripensamento dell’educazione in termini algoritmi, programmi e architetture di rete. Tuttavia anche qui c’è chi si domanda perché usare email invece di posta elettronica, streaming invece di diretta, BYOL invece di PITC (Porta Il Tuo Computer), etc… Chi usa il termine originale vuole mostrare di essere aggiornato, e vuole concedere all’ascoltatore la stessa patente (“qui siamo tra esperti, sappiamo tutti cos’è il digital divide”). E a volte invece l’uso di queste espressioni è proprio causa di divisione e genera incomprensioni; ma nessuno ammetterebbe di non sapere esattamente cosa significa HTTP, parola che digita tutti i giorni.

Ora però – anche alla luce delle riflessioni che facevo qualche giorno fa sullo stesso tema, anche se forse non era troppo evidente – vorrei provare ad approfondire un po’ il discorso.

Alcune delle parole sotto accusa sono difficili da tradurre in maniera sintetica (provate con “debriefing”), ma d’altra parte non sempre essere sintetici è un valore. Altre sembrano proprio un esercizio gratuito di pigrizia (“screensaver” non è un termine tecnico). In altri casi la traduzione italiana esiste, ma non è detto che abbia proprio lo stesso valore.

Per esempio confrontiamo i vocaboli “calcolatore” e “computer”. Hanno esattamente lo stesso significato, nel senso che dovunque si usa il primo si potrebbe usare il secondo. Non indicano due oggetti diversi.

Ma se vi rotolate nelle bocca queste parole sentite cose diverse. Uno sa di università, di laboratorio, l’altro di Euronics.

La diffusione lessicale è ovviamente molto diversa: calcolatore viene usato solo dai pochi che hanno appreso l’informatica almeno trent’anni fa, computer da tutti gli altri. L’etimologia è poi interessante: “calcolatore” viene, dopo vari passaggi, da calculus, il sassolino che si usava per contare, magari disposto in scanalature di una tavoletta o su fili diversi come nel pallottoliere; “computer” da com-puto, il verbo delle operazioni aritmetiche (la somma, in particolare). Uno punta sul supporto materiale, sull’ausilio tecnologico, l’altro sull’operazione mentale di trarre una conclusione da una situazione complessa.

Naturalmente l’etimologia non partecipa alla determinazione dell’uso di un termine, almeno quando è ignota. Ma saperne di più aiuta a modulare l’uso dei termini, a scegliere. C’è chi non capisce il successo del nome (prima dell’oggetto) Whatsapp, principalmente perché non coglie il nesso con “what’s up?”, che succede? O chi non sa che “tube” significa “televisione” (dal tubo catodico), e quindi non collega Youtube con “fai la tua televisione”.

Un altro esempio che è sotto i riflettori in questi giorni (Code Week): “coding” potrebbe essere tradotto con “programmare, programmazione”. Ma esiste “programming”, che equivale a “programmare”. Nel quadrilatero che possiamo immaginare, uno dei vertici è vuoto. I due termini inglesi hanno – nella mia mente, sulla base delle mie esperienze –  due sfumature diverse: coding è “codificare”, cioè trasporre uno schema operativo in un certo codice linguistico, partendo da una versione astratta o da un altro codice. Programmare è “costruire un programma”, un artefatto digitale che viene eseguito da un calcolatore. Il primo termine sottolinea il processo, l’attività linguistica; l’altro il fine e l’utilizzo del prodotto finale. Uno si presta bene a sviluppare gli aspetti narrativi, l’altro quelli ingegneristici. Quando dico “un programma è la materializzazione in un linguaggio specifico di un algoritmo che risolve un problema”, ho in mente il risultato, non il processo di scrittura. Quando dico “coding is fun”  ho in mente l’avventura di trovare dentro di me le parole giuste per dirlo.

“That is why I enjoy computer programming more than anything I have encountered in this life. Not because of the boring “move, modify, store, repeat” routine of the daily work, but in studying how I write code and from the knowledge and insight I get into the code, I also get into myself.” Mark Janssen qui parla evidentemente di coding, non di programming.

Ora non giurerei che chi parla oggi di “Code Week” intenda una cosa diversa da “Settimana della Programmazione”; però sarebbe bello se i corsi di “coding” e quelli di “programmazione” fossero riconosciuti come cose diverse e un potesse iscriversi all’uno o all’altro con cognizione di causa. Sarebbe bello se chi parla di certi argomenti avesse una conoscenza meno superficiale; conoscenza (non solo competenza) che non deriva solo dalla pratica di una disciplina, ma anche dalla riflessione sulle proprie esperienze e dallo studio delle parole di quella disciplina, del loro uso non solo qui ed ora. Mi rendo conto che  è una posizione che può apparire retrograda. D’altra parte, penso ancora che ci siano più parole che cose, e che rinunciare alla parole in favore delle cose sia almeno altrettanto rischioso dell’inverso.

 

Il problema, secondo il mio modesto parere (IMHO), è quindi non tanto nell’usare un termine straniero per ossequio ad una potenza nemica, ma usarlo inconsapevolmente senza cercare di coglierne tutti i significati e i sapori. Come per la zappa.

Anche in questo caso, un’educazione all’uso delle parole, trasversale a tutte le discipline, sarebbe benvenuta.