steve's

apprendimento digitale e dintorni

E perché non un’automa?

Gen
13

Questo articolo fa seguito al precedente e descrive un ipotetica attività di “coding” da fare in classe. Il dominio è quello della lingua. L’obiettivo è costruire insieme un automa linguistico, cioè un programma in grado di simulare un parlante della lingua Italiana, in una situazione specifica molto semplice: premettere l’articolo ad un nome.

Non è un caso che l’esempio proposto non sia quello di un quiz o di un programma che “interroga” lo studente (come in tanti esempi che si possono trovare in rete: per esempio, http://www.baby-flash.com/lavagna/articoli_sbagliati1.swf oppure http://www.softwaredidatticofree.it/schedaapostrofo1.htm). Anzi: il modello è esplicitamente un altro, quello dell’insegnamento AL computer DA PARTE dello studente, o meglio da parte di un gruppo di studenti.

Probabilmente i docenti di Lingua che leggeranno questo testo troveranno imprecisioni, errori, mancanze. Mea culpa: non sono un linguista, né un docente di lingua. Si può senz’altro correggere e migliorare, o ripensare da zero. In generale, quanto scritto rappresenta solo un esempio di una possibile modalità di utilizzo della programmazione come strumento di costruzione collettiva di conoscenze, da adattare (o ripensare) nei contesti specifici della classe.

Gli esempi di codice contenuto sono in Kojo; in appendice due piccoli estratti di codice in Logo e in Prolog.

Qui trovate una presentazione veloce.

Qui invece l’articolo completo.

Scuole e monopolio della carta igienica: il caso Paapre

Nov
22

La doverosa attenzione dell’ente pubblico per il bilancio è sicuramente meritoria. In un Paese dove si spende troppo e male, ancora di più.

Quando si decide di utilizzare un servizio gratuito, di qualità, dal punto di vista del bilancio va tutto bene, e anche dal punto di vista della funzionalità.
Però occorrerebbe pensare agli effetti collaterali – non solo a quelli immediati all’interno della scuola. Perché la scuola pubblica ha anche un piede nella società e nel futuro.
Quando il servizio è virtuale, digitale, sembra che questi effetti non ci siano. Invece non si vedono, ma ci sono.

 


Prima parte
Facciamo allora un esempio più concreto: prendiamo la carta igienica. Ogni scuola ha una voce di budget annuale per la pulizia, immagino, che comprende anche la carta igienica. Un tot per ogni bagno? Le scuole superiori ne consumano di più, di meno? non importa. Facciamo sia 100.
Quei 100 € vengono dallo Stato, o dai Comuni, o dalle Regioni? non lo so, ma ipotizzo derivino dalle tasse pagate dai cittadini e dalle imprese.
Immaginiamo il flusso di quei 100 €. Marchiamoli come fa la polizia per i soldi dei riscatti e seguiamo la strada che fanno.
Ogni anno viene contattato un fornitore e gli vengono dati 100 €.
Il fornitore di quei 100 € ne trattiene una parte (per pagare stipendi, furgoncino, benzina), e una parte la dà al grossista.
Della sua parte, il grossista ne tiene una quota (per pagare stipendi, magazzino), e il resto la dà al produttore, per esempio alla fabbrica di carta igienica di Lucca.
La fabbrica di Lucca con la sua quota compra la materia prima e produce la carta igienica.
Ognuno di questi attori spende parte del proprio incasso in stipendi, in affitto di mezzi.
Poi su quel 100 € vanno calcolate le tasse, cioè la parte di denaro che torna nella casse dello Stato, delle Regioni etc. Sembra che la pressione fiscale in Italia sia alta, è una bella fetta che torna indietro.
Insomma c’è un flusso di denaro dal cittadino allo stato al cittadino.

Ci sono dei limiti.
Si potrebbero selezionare i fornitori, o tutta la filiera, per garantirsi che non ci sia sfruttamento minorile, che la carta sia riciclata e non vengano tagliati troppi alberi, o inquinati fiumi; o che l’elettricità sia presa da fonti rinnovabili, etc etc. Ma questo farebbe aumentare il costo della carta igienica.
Non solo: quei 100 € sono probabilmente insufficienti per coprire il bisogno effettivo di carta igienica della scuola.
Cosa fa allora il dirigente accorto? Inventa.
1. Affigge un regolamento che limita i centimetri quadri di CI a disposizione dell’utente per ogni seduta
2. Ricicla le circolari
3. Lancia il piano BYOTP (Bring Your Own Toilet Paper)
4. Produce della carta con  le stampanti 3D
etc.

Ora immaginiamo che il signor Paapre, multinazionale di QualchepostoLand, decida di regalare carta igienica quadruplo velo, profumata alla lavanda, a tutte le scuole italiane.
Perché lo fa? sono affari suoi, possiamo immaginare che non sia per altruismo, ma per ora ignoriamolo.
Per quanto tempo lo fa? Non lo sappiamo. Certo non si impegna a farlo per sempre.
Intanto le scuole sono contente perché risolvono il problema e risparmiano. La carta igienica è di ottima qualità e viene consegnata direttamente alla scuola.
Si può discutere sul fatto che gli studenti si abituino alla carta quadruplo velo profumata alla lavanda e poi in futuro – ma anche a casa – vogliano usare solo quella.
Ma il punto è un altro: si crea una situazione di monopolio. Anche potendo scegliere, chi comprerebbe mai carta igienica se si può avere gratis?
Che succede? che quel flusso di denaro si ferma. O meglio, i 100 € vengono utilizzati altrimenti (forse per cose più utili) ma gli attori prima elencati hanno un ammanco rispetto alle entrate previste.
Cosa fanno? Ricordate che non è UNA scuola, ma TUTTE le scuole. Cambiano settore, mettono a part time gli operai, licenziano, chiudono….
Diminuiscono anche le entrate del fisco. Forse quella voce di bilancio scolastico viene cancellata.
Sono eventi che non riguardano la scuola?
Quella scuola che preparava gli studenti ad un mercato del lavoro, che però grazie (anche) all’operato della scuola piano piano scompare?
E che succederà quando il signor Paapre decidera di far pagare 1 € (invece di 100) la sua fornitura? Niente, sempre economia per la scuola. Ma siccome c’è un monopolio, da 1 € si può passare anche a 100 €, senza che nessuno possa fare niente. Tornare indietro? ma ormai il tessuto imprenditoriale non c’è più. Niente più fornitori locali, niente grossisti.

Ora cosa c’è di diverso se invece di carta igienica parliamo di servizi digitali (software, connettività, cloud, antivirus, ….)?
Economia e praticità possono davvero bilanciare il danno che si fa all’ecosistema delle imprese digitali locali?


Seconda parte
Ma allora come la metti con il software opensource, che è gratis? Neanche quello va bene? Si. Ma non perché è gratis.
Anche qui possiamo fare una simulazione. Su 100  € di licenze di software Megasoft, una quota (piccola) va al fornitore; la maggior parte va al produttore, che ha sede a Vattelappesca City. Siccome il fornitore ha un piccolo margine, deve moltiplicare le vendite; tendenzialmente deve acquisire il monopolio. Quindi spinge, fa sconti, fa formazione sulla versione Educational di Megasoft, quella adatta per il Coding. Un giorno anche quella sarà a pagamento, ma per ora va bene…

Invece su 100 € di servizi connessi con il software opensource (formazione, installazione, adattamento, hosting), tutto va al fornitore locale. Il quale paga le tasse, paga gli stipendi etc etc. Il fornitore locale NON ha bisogno di monopolizzare il mercato, perché ha margine a sufficienza. C’è spazio per soluzioni diverse  e fornitori diversi.
I servizi sono di qualità inferiore? Forse, ma visto che il software è aperto si possono migliorare. Si possono unire le risorse di più scuole per sviluppare migliorie e funzionalità di cui tutti beneficeranno.

Quando la scuola decide di installare Moodle per l’e-learning (perché è gratis) e WordPress per il sito (perché è gratis) e poi di gestirli internamente, fa un’opera meritoria dal punto di vista del bilancio. Meno meritoria dal punto di vista dell’economia del Paese.

Contro la definizione

Nov
15

Cos’è un albero? Cos’è la filosofia? Cos’è l’ipotenusa? Cos’è il coding?

Sono domande completamente diverse nascoste dalla stessa forma. Se il concetto di cui domandiamo la definizione è un’invenzione formalizzata dentro qualche dominio, la risposta sta nella costruzione di quel concetto nel dominio (una tassonomia botanica, la geometria euclidea). Se invece è un concetto più complesso, che riguarda una pratica (o meglio, diverse pratiche) che è stata etichettata con quella parola da persone diverse in tempi diversi, la definizione non può che essere prima di tutto una raccolta di utilizzi.
In questo secondo caso, non c’è una risposta univoca e ultima. Nessuno ha la patente per poter dire in maniera incontestabile cosa è la filosofia. Se vogliamo una definizione normativa, possiamo provare a distinguere tra usi corretti e scorretti, ma prima bisogna concordare su: corretto rispetto a cosa? E chi ha il diritto di stabilirlo?

Se poi il concetto è nuovo, e non c’è un establishment (la scuola, l’accademia, qualche forma di potere riconosciuto) che ne fissa gli usi, definirlo rischia solo di creare delle guerre di religione. Se il concetto è importato da qualche altra cultura e lingua (come lo era la filosofia per i romani) bisogna stare ancora più attenti: cosa si definisce, la versione originale, quella localizzata, o una supposta versione universale?
La definizione è essa stessa una pratica, inventata da Platone, perfezionata da Aristotele, poi passata nel medioevo agli scolastici, poi entrata nella scienza. Da collocazione di un concetto in una gerarchia fissa è diventata un procedimento pratico per evitare incomprensioni e permettere confronti. Ha a che fare con la spiegazione dell’uso di un termine/concetto, più che con la sua natura profonda. Illuminante, per me, la discussione della definizione del concetto di lunghezza fatta da Percy William Bridgman nella sua Logica della Fisica Moderna (1927). Lunghezza si può definire se si descrivono le operazioni con cui si misura la lunghezza. Per fortuna Bridgman si  è allontanato da definizioni fisicaliste e si è messo a interrogarsi in generale sul significato operazionale dei concetti.

Allora per favore smettiamola con la domanda “Cos’è il coding?” come se potesse esistere una risposta del tipo “Il Coding è questo e non quest’altro”. Quanto sarebbe meglio fermarsi a “la parola ‘coding’ viene impiegata così e così in questi contesti”.

 

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?

Ma perché non sono nato là?

Ott
09

La citazione (che dovrebbe essere chiara per chi ha almeno cinquant’anni) è da Claudio Baglioni, ebbene si, “Viva l’Inghilterra”, anno 1973.

Si riferisce al fatto che mi danno (voce del verbo dannare) almeno dal 1999 intorno alla necessità di un’analisi (socio)linguistica del codice sorgente e non trovo un cane disposto ad ascoltarmi. O quasi, come si vede da http://steve.lynxlab.com/?p=73

Invece in USA e in Canada ci lavorano sul serio, dentro l’università, mettendo insieme ricercatori di linguistica e di informatica. E quest’articolo, pubblicato  nei Proceedings di una conferenza annuale del Psychology of Programming Interest Group che si tiene nel’UK, è finalmente (finalmente?) un esempio pratico di un tentativo reale di applicazione di modelli e strumenti sociolinguistici al codice sorgente da parte di un gruppo di ricercatori dell’Università di Lethbridge. Molto minimale ed embrionale, ma insomma esiste.

Schermata da 2016-10-10 21-59-45

Il tema è quello del genere. Si può riconoscere solo leggendo il codice se l’autore è uomo o donna? Pare di si. E che ce ne importa, diranno i miei piccoli lettori. Ci importa, perché come premettono le autrici, è il primo passo per vedere se nel codice ci sono tracce anche della lingua materna, delle conoscenze pregresse di altri linguaggi, del livello sociale o della cultura generale. E allora? Allora è il primo passo per riconoscere che il codice sorgente è un testo, risultato di un’attività di scrittura, e quindi può contenere  tutte le varianti possibili che una scrittura permette: stili, personalità, mode, esperienze trascorse. Non importa che il lessico sia limitato (ma estensibile a piacere) e che la grammatica sia molto restrittiva (ma permette forme alternative). Un programma, definitely, is not just an implementation of an algorithm which solves a problem. Si scrivono programmi per scopi diversi: per gioco, per sfida, per sperimentazione, per produrre un effetto artistico, per imparare. A monte si sceglie il linguaggio in cui scriverli, il che ha un effetto sull’orientamento generale del programma, su come viene letto, come verrà modificato e come sarà punto di partenza per nuovi programmi.

Ne deriva che quando si insegna a scrivere codice, come quando si insegna a scrivere – ma a scrivere bene – non basta insegnare la grammatica e il lessico. Ci vuole molto, moto di più. Ci vogliono buoni esempi (lettura), modelli, obiettivi, strumenti di valutazione. Ne deriva, probabilmente (ma questa è solo una mia ipotesi) che chi legge e scrive molto, programma meglio; che introdurre lo studio di come si crea e sviluppa una storia permetterebbe di ottenere dei codici sorgenti migliori, che come le buone storie “si reggono”. Le buone storie si tramandano nei secoli, come le fiabe; forse è così anche per i buoni programmi.

Rice, J. E., I. Genee, and F. Naz. “Linking linguistics and programming: How to start?(work in progress).” Proc. 25th Annual Psychology of Programming Interest Group Conference-PPIG. 2014.

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…

Dietro il coding

Set
25

copertina

In occasione dei due seminari in Piemonte (Ivrea e Torino), di cui qui trovate maggiori informazioni, ho preparato delle slide. Troppe slide. Alla fine mi hanno fatto notare che più che una presentazione stava diventando un libro.

 

 

E allora ho colto l’occasione, reimpaginato, aggiunto, corretto, e ho realizzato un piccolo ebook dal titolo “Dietro il Coding”. Non è una difesa del coding né una sua condanna. E’ semplicemente una raccolta di domande e di riflessioni che hanno lo scopo di stimolare quelle degli altri, soprattutto di quelli che intendono dedicare qualche ora al Coding con i propri ragazzi. Riflessioni che partono da lontano, da almeno venticinque anni fa, ma che ho cercato di aggiornare andando a caccia di opinioni, di proposte e di alternative. Una parte importante è dedicata al progetto “Programma il Futuro” e a Scratch, ma purtroppo solo poche righe al nuovo tema dei curricoli digitali, che andrà seguito con attenzione.

Questo è l’indice:

Come nasce questo testo
1. Che cos’è il Coding
2. Perché è così importante
3. Una valutazione storica
4. Come si parla del Coding?
Primo Intermezzo: che significa opensource?
5. A che serve il Coding?
6. Chi può insegnare il Coding?
Secondo Intermezzo: le differenze tra linguaggi
7. Che linguaggio?
8. Il modello didattico dietro Scratch
9. Come andrà praticato il Coding
10. Un po’ di storia…
11. E oggi?
12. Come potrebbe funzionare davvero
Suggerimenti di lettura

L’ebook è rilasciato con licenza CC BY/SA e lo potete scaricare da  qui.

C’è una cura per la disillusione digitale?

Ago
11

La Disillusione Digitale è una forma di disagio che colpisce alcune persone, tipicamente over 50, maschi e femmine, indipendentemente dal censo o dal fisico. Tra i suoi tipici sintomi:  sentirsi stonati  in un coro di lodi del Digitale, avere sempre vent’anni di più degli altri seduti al tavolo di progettazione, provare fastidio per le terminologie anglicizzanti e per la parola di moda (ma vedi la Nota in fondo a questo testo).

I Disillusi Digitali vedono la storia alla maniera di Vico: c’è stata un’Età degli Eroi, in cui sono stati fatte tutte le scoperte più importanti, sono stati inventati i paradigmi e sono stati dati i nomi veri alle cose; e ora c’è l’Età degli Uomini, in cui il digitale è democratico e di tutti, ma se ne è perso il significato profondo.

La Disillusione Digitale in fondo assomiglia alla disillusione politica: c’è stata la Rivoluzione, poi l’era grigia del Digitale Reale, e poi il Crollo del Muro Digitale. Come quella, ha forti connotati affettivi, ma cerca di spiegare se stessa in termini di processi sociali, economici, tecnologici.

Ma forse conviene vederla in una prospettiva meno storica e più psicologica. Anzi psicoterapeutica.

Quando si parla di Digital Divide si pensa ad una linea di demarcazione tra generazioni. I giovani nativi e i vecchi immigrati, etc. Invece è un confine che ci troviamo davanti tutti, spesso, a tutte le età.

La caffettiera del masochista

La caffettiera del masochista

Intanto cominciamo a dire che il Digital Divide è solo un caso del Technology Divide (per restare all’Inglese che fa più fico). Ovvero quella sensazione, brillantemente descritta ne “La Caffettiera del Masochista” di Donald Norman, di essere dei cretini, inadeguati agli artefatti che popolano la nostra vita quotidiana.

Per esempio, andiamo al bagno al ristorante. Bagno molto chic, bellissimo, luci soft, rumori attutiti, magari pure una musichetta di sottofondo. Il cesso è il cesso, va bene, ma il rubinetto… come diavolo si usa? cerchiamo manopole, leve, pulsanti, ma niente. Agitiamo le mani sopra, sotto, ci avviciniamo, ci allontaniamo: nemmeno una goccia. Frustrazione.

Qui la semantica dell’oggetto  è chiara (è un rubinetto, deve uscire dell’acqua) ma la grammatica no (come si usa?). La nostra aspettativa di trovare appigli per le dita è frustrata. Come direbbe Norman, l’affordance dell’oggetto è scarsissima.

Un altro caso: il taglia erba si rifiuta di accendersi. Riusciamo più o meno a togliere il coperchio di plastica che copre il motore. Qui ci sono leve, levette, viti, … ma a che serviranno? Cosa regolano? Come bisogna intervenire?

In questo caso ci sfugge anche la grammatica; l’unica cosa che ci sembra di comprendere è il vocabolario  o meglio l’alfabeto (una leva è una leva, una vite è una vite). Ma da solo l’alfabeto non serve. E’ come trovarsi davanti al Cippo di Perugia: di sicuro quelle sono lettere, ma poi?

L’incapacità di regolare un orologio digitale dotato di DUE SOLI pulsante è dello stesso tipo. Ci manca lo schema mentale “menù ad albero” (un pulsante per muoversi nell’albero, un pulsante per scendere di livello o per confermare) che invece è naturale per i bambini. Di qui all’espressione ebete che assumiamo quando ci troviamo davanti una nuova app il passo è brevissimo. Non abbiamo idea di cosa siano quelle tre lineette orizzontali in alto a destra, la freccia a sinistra, i tre pallini collegati, e pazienza. Non sappiamo come si usano, e questo è un po’ peggio. Ma non abbiamo nemmeno idea di a cosa possa servire quella app. Sentiamo che dovremmo fare qualcosa, ma cosa?

Quindi il Digital Divide è solo un caso particolare della incapacità di affrontare con i vecchi strumenti concettuali le nuove tecnologie.

Ma facciamo un altro piccolo passo avanti: le nuove tecnologie non esistono. Sono una categoria psicologica, nel senso che è “nuova” la tecnologia che non c’era quando ci siamo affacciati al mondo delle macchine. Per esempio, per mio padre la radio era una “nuova tecnologia”. Ognuno di noi è portato ad accettare come naturali le tecnologie che esistevano, e guardare con sospetto le altre. Vale per la scrittura, il libro, la televisione, i computer, gli smartphone, la realtà aumentata, etc. Il libro cartaceo è più vero e giusto dell’ebook solo perché c’era nella mia infanzia.

I bambini, ovviamente, non hanno particolari problemi con le nuove tecnologie. E per forza; per loro non sono affatto nuove. Non le vedono nemmeno come tecnologie, sono semplicemente parte dell’ambiente, della natura. Ci sono abituati, non provano nessun’emozione particolare ad usarle; ma questo non è sufficiente perché le capiscano, e nemmeno perché abbiano interesse a capirle.

Radio a galena

Radio a galena

Ci sono delle persone particolari, curiose, che invece per le “nuove” tecnologie non provano ribrezzo immediato, ma le affrontano per capirle. Si domandano da dove vengono, come funzionano. Ci giocano, come farebbero i bambini. Le smontano e le rimontano, le cominciano a usare, se ne impadroniscono (per tornare a mio padre, a distanza di settant’anni mi raccontava con passione di quando aveva costruito la prima radio a galena). Qualche volta ne parlano in maniera entusiasta, come del “nuovo orizzonte” (della didattica, della medicina, etc). Diventano degli apostoli (scusate: degli evangelists), organizzano seminari, scrivono libri.

Quando queste persone sono insegnanti, trasmettono questo atteggiamento positivo, curioso, partecipativo, ai propri studenti. E’ quello che faceva il compianto Seymour Papert, scomparso di recente e mai abbastanza ricordato. L’effetto è che gli studenti – in particolare i più piccoli – non solo si divertono, ma si divertono ad imparare. Si affezionano alla macchina che hanno costruito, ci tengono, le vogliono bene. Riescono a vedere attraverso la macchina la parte che dipende da loro (le idee) e quella che è indipendente (le regole). Probabilmente – ma non è sicuro – manterranno questo atteggiamento positivo e curioso anche in futuro, non si faranno stregare dal canto delle sirene, per ogni nuovo regalo si domanderanno: ma come funziona? cosa c’è dietro?

Quello di questi insegnanti è un atteggiamento fortunato, che purtroppo non dura per sempre, perché negli ultimi cento anni le tecnologie cambiano in fretta. Succede perciò che anche queste persone si ritrovino imbarazzate quando quella tecnologia, con cui pure avevano fatto amicizia, comincia a diventare incomprensibile. Non la riconoscono più, come un cucciolo che è diventato un animale adulto, con personalità e pulsioni che li escludono. La tecnologia buona era quell’altra, quella di prima. C’è un distacco affettivo, oltre che cognitivo. A quel punto anche queste persone fortunate cominciano a parlare di “deriva”, di “usi impropri”, di “evoluzione distorta” eccetera, e si vanno a collocare nella terza schiera: dopo gli apocalittici e gli integrati, i disillusi. Ma non è un fenomeno storico che stanno descrivendo, è il loro (nostro) percorso attraverso la linea del Digital Divide.

Come si evita questo progressivo allontanamento? Non lo so con certezza. Ci si osserva, si studiano i segnali della disillusione. Ci si educa alla tolleranza. Non si smette mai di studiare e di fare, ci si continua a mettere alla prova, ci si fa aiutare da qualcuno più giovane e aggiornato. Personalmente è quello che cerco di fare, con risultati alterni.

Riassumendo: è una buona cosa affezionarsi ad una nuova tecnologia, perché ci mette in una disponibilità mentale tale da permetterci di capirla, ma non è un’acquisizione che dura per sempre. Comunicare questa disposizione agli studenti è una parte fondamentale del compito degli insegnanti. Più importante, secondo me, che insegnare il Computational Thinking.

Nota: quella della lingua del digitale è una questione che un giorno andrebbe studiata per bene. I Disillusi Digitali sono quelli che usano la parola “computer”, e mentre lo fanno pensano che è sinonimo di “calcolatore”. La generazione che attualmente ha in mano il digitale (quelli che oggi hanno trenta-trentacinque anni) non parla di “computer” ma di “device”, intendendo qualsiasi cosa sia connessa a Internet. D’altra parte, all’inizio degli anni ’80 del millennio passato (gli anni dell’Apple II, dell’Atari 400, del Commodore VIC 20 e del PC IBM) non erano nemmeno nati. Non conoscono il significato di “IBM-compatibile” e non vedono cosa c’entri con il loro tablet Android, e in generale non gliene frega nulla dell’etimologia. La lingua, come il digitale, si usa, anche senza capirla.