steve's

Introduzione al Prolog per docenti di materie umanistiche

Gen
14

Prolog è un linguaggio che ha più di quarant’anni ed è nato come esempio di ambiente di programmazione logica. Che è una cosa completamente diversa da quella imperativa, o da quella funzionale, o da quella a oggetti. Già solo per questo mi pare interessante: non si impartiscono comandi, ma si chiede di dimostrare teoremi sulla base di fatti e regole. Ora uno potrebbe pensare che sia un linguaggio inventato per la geometria o la logica. Invece è stato inventato per fare linguistica computazionale, cioè analisi e produzione di testi in linguaggio naturale.

Ho conosciuto Prolog tanti anni fa, con un paio di testi oggi introvabili, che ne proponevano l’uso a scuola, per l’insegnamento dell’italiano, della geografia, del latino (uno di Giorgio Casadei, l’altro di Vittorio Midoro). O meglio, nel contesto dell’insegnamento di queste materie. Siamo a fine anni ottanta, gli anni in cui si pensava che programmare fosse un’attività interessante, prima che si passasse a usare i computer per scrivere, per fare multimedia o per comunicare. Anni  in cui ai bambini si proponeva il Logo, e qualcuno riteneva che non ci fosse un motivo speciale per riservare le applicazioni della programmazione alle discipline STEM.

Ho provato a immaginare, oggi, delle possibili attività di coding con linguaggi alternativi a quelli visuali (qui il resoconto dell’esperimento mentale). Poi mi sono detto: e perché non con Prolog? Forse è addirittura più semplice iniziare da lì, anche se non ci sono variabili, comandi, cicli, condizioni.

Però mi sono accorto che non esisteva una facile introduzione in Italiano al Prolog per gente “normale”, cioè che non fossero studenti di informatica o non conoscessero già altri linguaggi. Allora ho pensato: quasi quasi la faccio io. Sarà sempre meglio di niente.

Ho cominciato, e una prima versione di un tutorial introduttivo lo trovate qui.

Spero di migliorarlo con il contributo di tutti.

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.