Digi Tales

Pensiero computazionale sì o no? Boh, dipende dal linguaggio.

Gen
27

Una delle motivazioni dietro la spinta all’introduzione della programmazione dei computer in giovane età (=coding) è quella per cui questa pratica insegna il pensiero computazionale, che è un modo di affrontare i problemi in maniera scientifica. Anche se Jeannette Wing si è affannata a dire che non si tratta di insegnare ai bambini a pensare come i computer, e Seymour Papert a predicare che bisogna insegnare ai computer come se fossero bambini, questo tema resta nell’aria. Computazionale significa “razionale, finito, corretto, misurabile” eccetera. In pratica, imparare il pensiero computazionale significa, per ogni problema, saper immaginare un algoritmo che lo risolva. Questo algoritmo deve essere eseguibile praticamente da un computer: non deve contenere errori, non deve basarsi su termini ambigui, non deve richiedere un tempo infinito o una memoria infinita per arrivare alla soluzione.

Però gli algoritmi si pensano (e poi si scrivono) diversamente a seconda del linguaggio, e a seconda del tipo di linguaggio che si ha in mente. Usare un linguaggio semplice quando si è ai primi passi è sicuramente una buona idea; ma cosa significa “semplice”? Può significare che costringe ad usare dei concetti e delle operazioni di base, vicine a quelle che sa fare il computer; oppure che spinge a nascondere i dettagli e a concentrarsi “semplicemente” sulla struttura dei dati e sugli obiettivi.

Insegnare ai bambini una forma di pensiero computazionale che li abitua a pensare nei termini del primo significato di “semplicità” rischia di creare più problemi – in futuro – di quelli che risolva adesso.

Voglio provare a spiegare questa differenza con un piccolo esempio.

Partiamo da Snap!, un ambiente di programmazione che pochi conoscono, che assomiglia molto a Scratch (ne è derivato) ma ha delle differenze importanti. Intanto è nato all’Università di Berkeley, dall’altra parte degli USA rispetto a Stanford, dove è nato Scratch. Poi ha un target più ampio, nel senso che può essere usato da bambini ma anche da ragazzi più grandi, perché è basato su un modello di linguaggio più potente di quello che sta sotto Scratch. Le differenze tra Snap! e Scratch sono poco visibili ad un primo approccio (si possono disegnare girandole o creare scenette animate con entrambi), ma sono molto profonde. Ne elenco solo tre fondamentali:

  1. A differenza di Scratch, in Snap! si possono creare funzioni, cioè procedure che alla fine restituiscono un valore, e questo è molto comodo perché permette di costruire delle catene di funzioni che si applicano ai risultati di altre funzioni.
  2. In secondo luogo, in Snap! ci sono delle funzioni per creare e gestire vere liste (di numeri, di lettere, di parole, ma anche di sprite, o di qualsiasi oggetto).
  3. Inoltre le funzioni possono essere usate come oggetti da altre funzioni. In altre parole: una funzione si può applicare non solo a oggetti semplici (come numeri, lettere) ma anche ad altre funzioni. In aritmetica conosciamo questo tipo di cose: la moltiplicazione è l’applicazione ripetuta della funzione somma.

Il terzo punto è particolarmente utile quando si vogliono trattare delle serie di dati. Se vogliamo trasformare una lista di numeri, o di lettere, o di parole, in qualche altra cosa dobbiamo applicare una trasformazione ad ognuno degli elementi della lista per ottenere una nuova lista; avere un linguaggio che permetta di fare direttamente questo tipo di operazioni permette di concentrarsi sul problema, e non sul meccanismo delle soluzione.

Mettiamo, per esempio, di voler generare la lista dei quadrati dei primi 10 numeri interi. Partendo da una lista di numeri interi, vogliamo moltiplicare ogni numero per se stesso. Cioè da 1,2,3,4,5… vogliamo ottenere 1,4,9,16,25 …

Questo in Scratch si può fare così:

  • crea una lista di numeri interi e dagli il nome “numeri”
  • crea una seconda lista e dagli un nome “quadrati”
  • crea un contatore e dagli il nome “i”, e valore 0
  • ripeti tante volte quanto è la lunghezza della lista “numeri”:
    • aumenta “i” di 1
    • moltiplica l’elemento i della lista “numeri” per se stesso
    • aggiungi il risultato alla lista “quadrati”

Saltando la parte di creazione delle variabili, ecco i blocchetti:

E’ semplice, sì, ma è anche un modo di pensare molto meccanico, che segue esattamente quello che succede “sotto il cofano”. Siamo noi che ci adeguiamo al modo di lavorare del computer, e non viceversa. Arrivare a questa formulazione non è banale: bisogna imparare a pensare in un certo modo. Bisogna imparare il concetto di contatore, di indice di una lista, quello di ciclo, di test di terminazione, eccetera. Sono gli elementi di base della programmazione classica.

Proprio questo è uno dei limiti dell’approccio “computazionale” di cui parlavamo sopra: si impara a pensare come un computer, o meglio secondo gli schemi che il linguaggio di programmazione che usiamo (in questo caso Scratch) mette a disposizione.

Da un lato questo apprendimento ha degli aspetti positivi: ogni volta che ci poniamo un limite impariamo nuovi modi di risolvere problemi. Dall’altro, restare dentro quei limiti non ci permette di andare molto lontano. Potrebbe esserci (non è mai stato studiato a fondo) una forma di imprinting per cui il primo modello di programmazione imparato resta quello fondamentale, un po’ come la lingua madre. Se i bambini imparano a usare i cicli per scorrere le liste, poi continueranno a farsi venire in mente questa modalità anche in futuro.

Ma usare i cicli è solo uno dei possibili modi di risolvere il problema dei quadrati. Ce ne sono altri, che dipendono dal linguaggio che si usa.

In Snap! si possono disporre i blocchetti esattamente nello stesso modo che in Scratch:

Ma si può fare anche qualcosa di diverso, più semplice e soprattutto più vicino alla struttura del problema.

Per risolvere il problema dei quadrati dei numeri interi non siamo costretti a pensare in termini di contatori e di indici, non dobbiamo per forza preoccuparci di sapere quando fermare il processo, dove mettere i risultati. Queste sono cose che riguardano la meccanica dell’algoritmo, non il problema in sé.

Qual era la cosa che volevamo fare, l’idea iniziale? Applicare la funzione “moltiplica per se stesso” a tutti gli elementi di una lista. Bene, allora cominciamo dalla lista

Questo blocchetto è una funzione che restituisce una lista costruita con gli oggetti che mettiamo negli spazi bianchi, in questo caso i primi cinque numeri interi. Non abbiamo bisogno di creare una variabile perché la funzione restituisce sempre quello che ci serve. Ora possiamo disporre i blocchetti in modo da rispettare esattamente l’idea originale di applicare la moltiplicazione alla lista:

Finito. Non c’è altro da fare. Questo blocchetto (“applica”) fa da solo tutto il lavoro: prende il primo elemento della lista, lo inserisce nei due buchi del blocchetto verde, esegue la moltiplicazione e mette da parte il risultato, poi passa al successivo. Alla fine restituisce una nuova lista con i risultati.

La presenza del blocchetto “applica” è una delle caratteristiche di Snap! (e dei linguaggi funzionali a cui si ispira) a cui facevamo riferimento prima. E’ una funzione che lavora su altre funzioni. Usando questo approccio, non ci servono variabili, contatori, cicli. Per certi versi, è molto più intuitivo e vicino al problema questo approccio di quello precedente, in cui dovevamo introdurre una serie di concetti di supporto.


In Snap! c’è un’altra maniera di ottenere questo risultato, ancora più semplice di quella che abbiamo visto adesso. Torniamo all’idea di partenza: “moltiplicare ogni numero di una lista per se stesso”. Ma invece di moltiplicare ogni numero per se stesso, possiamo partire da due liste identiche, e moltiplicare ogni elemento della prima lista per il corrispondente elemento della seconda.

Proviamo a fare esattamente questo:

Il risultato è lo stesso. In sostanza, l’operazione “moltiplicazione” normalmente si applica a dei numeri; ma in Snap! è stata estesa per applicarsi anche a delle liste. Naturalmente potremmo pensare di utilizzarla anche per moltiplicare due liste diverse, o per moltiplicare una lista per un numero singolo. Forse funziona anche con altre operazioni? Proviamo con l’operazione “elevamento a potenza”:

Funziona. Ed è abbastanza chiaro che è molto più semplice di tutto l’ambaradam che avevamo dovuto mettere in campo prima. Questa modalità ci libera di tutta la parte meccanica e ci spinge invece verso una maniera diversa di concepire il problema che volevamo risolvere, che a sua volta ci apre la strada verso altre possibilità.

In conclusione: attenzione al linguaggio che si sceglie, e non confondiamo la razionalità con la meccanicità.

Tecniche e tecnologie per la fantasia

Dic
11

Fantasia e tecnica non vanno d’accordo, si direbbe. Meno ancora fantasia e tecnologia: se c’è una, scompare l’altra. Quando entra in campo la tecnologia, il libero gioco dell’immaginazione dove va a finire? Però, però…

La tecnica del sasso nello stagno è descritta da Gianni Rodari nel secondo capitolo della Grammatica della Fantasia, come parte dello strumentario che serve a chi vuole inventare storie per i bambini, o con i bambini.
E’ una tecnica fondata sulle relazioni che uniscono parole nella mente, ma anche sul potere del caso nel sorprenderci e generare l’inizio di una storia.

Si pensa una parola… o meglio: la si chiede a qualcuno che passa di là, oppure la si pesca da un dizionario, o da un libro. Perché un libro? Perché è ancora più casuale, e dunque più sorprendente. Apri il libro a pagina 27, prendi la terza parola della quinta riga.
Poi si parte da quella parola per esplorare una serie di associazioni che servono a far emergere altre parole.
Per esempio, partendo da stasera possiamo andare a cercare:

le parole che cominciano allo stesso modo: stabilire, staccare, stagione, storia, studiare, stupido, …

le parole che finiscono allo stesso modo , cioè che sono più o meno in rima con stasera: camera, eccetera, lettera, maniera, opera

le parole simili, che si usano nello stesso contesto: stamattina, stanotte, prima, dopo, più tardi

E già nasce una storia:

Stasera, in camera, apro una lettera: sempre la stessa storia, la solita maniera, come un’opera eccetera eccetera – stupido! –

fino ad usare la lettere che compongono la parola per fare un acrostico:

  • Strada
  • Treno
  • Anima
  • Sangue
  • Egli
  • Ritornare
  • Appunto

Tutte queste parole nuove possono essere usate per creare una storia o una filastrocca.
Posiamo programmare un computer per fare (almeno una parte di) queste operazioni?
Sì, ed è quello che ho fatto qui con iKojo, la versione online di Kojo:
http://ikojo.in/sf/vylXgjC/10
Cliccate su RUN, prendete nota delle parole che vengono fuori (compreso l’acrostico) e poi iniziate a scrivere.
A me, partendo dall’acrostico di sopra – generato appunto dal programma – viene in mente una storia titanica (nel senso del film):

Lui è partito, col treno, chissà quanta strada ha fatto, ma ama lei fin nel profondo dell’anima. Lo ha giurato col sangue. Le aveva detto che sarebbe tornato, una sera di queste, e appunto, stasera…

Fa piangere già così, immaginate se poi lui stasera non dovesse arrivare …

Un altro risultato del Sasso nello Stagno

Il binomio fantastico è un’altra tecnica notissima, sempre dai primi capitoli della Grammatica.
Qui si prendono due parole a caso, possibilmente dalla mente di due persone diverse, o ancora una volta da un dizionario, da un giornale (dal web?).
Gli esempi di Rodari riguardano due sostantivi, ma non si vede perché non si potrebbero usare aggettivi o verbi; anzi, ci sono splendidi esempi di applicazione di questa variante nei racconti che mettono in scena i gemelli terribili, Marco e Mirko: “il leone bela”, “il lupo è dolce”, “il cielo è maturo”.
I due sostantivi si mettono insieme usando delle preposizioni: con, di, su, in (ma io aggiungerei: sotto, sopra, con, senza…).
Cosa fanno? si incontrano, si scontrano, vanno d’amore e d’accordo?
Per esempio: sasso, stagno (guarda un po’ che fantasia…)

  • il sasso nello stagno
  • il sasso di stagno
  • il sasso sotto lo stagno
  • lo stagno del sasso
    eccetera.

Ogni frase può essere l’inizio di una storia.
A me il sasso di stagno piace molto, mi fa pensare ad una palla di carta stagnola, di quelle della cioccolata, che usavo per giocare a calcio in corridoio da piccolo. E’ un sasso gentile e bellissimo, luccica come una pepita.

Una volta un minatore che lavorava a Canale Serci, sul monte Mannu, volle fare una sorpresa a suo figlio di tre anni e gli portò un sasso di stagno. Ma non era un sasso, era …

Se preferite, partiamo con una filastrocca. Il sasso di stagno richiama subito un ragno dispettoso, forse geloso, ma di chi? facile: di un cigno

Quel sasso di stagno
tirato da un ragno
geloso di un cigno
più bianco del regno…

Di nuovo vi chiedo: potremmo programmare un computer per fare (almeno una parte di) queste operazioni?
Sì, ed è quello che ho fatto qui:
http://ikojo.in/sf/EnNhE3O/12
Cliccate su RUN e state a guardare.


Sull’importanza del caso, sulla sua magia che ci costringe a renderci conto di quello che siamo (esseri che non possono impedirsi di dare senso a qualsiasi configurazione casuale, che vedono strutture chiuse ovunque) e sulla sua importanza per la didattica ho già scritto qui.

Se date un’occhiata al codice sorgente (a sinistra) vedete che a dispetto della semplicità apparente c’è invece parecchio lavoro sotterraneo per riuscire a mettere un articolo davanti ad un nome, o per costruire la preposizione articolata corretta. Non perché sia difficile la programmazione: perché è difficile la grammatica italiana, che deve dar conto di quasi mille anni di storia, di prestiti, di varianti locali, di sovrapposizioni. Anche questo è un esercizio di coding interessante, che richiede riflessione su come funzionano i meccanismi della lingua per poterli trasformare in algoritmi. Non è sempre necessario ricostruire tutto da capo, si può partire da pezzettini già pronti – è quello che ho fatto io e che fa chiunque programmi un computer.
L’idea più generale di accoppiare a caso sostantivi, proprietà, azioni, luoghi sta all’origine delle creazione di Limericks casuali a partire da una struttura (sintattica, ma anche narrativa): qualcuno, in qualche posto, fa qualcosa, e allora succede qualche altra cosa. Come finisce? E’ lo schema di tanti giochi, e anche delle fiabe a ricalco, un’altra tecnica descritta nella Grammatica della Fantasia nel capitolo 21 (ma ripresa anche in molti di quelli seguenti).
Entrambe queste possibili “applicazioni rodariane” del coding le ho descritte in “Lingua, coding e creatività”, che è un libro che cerca di scardinare l’idea che fare coding sia solo un’attività carina o che si debba fare solo per studiare le STEM; i codici sorgenti relativi, in Logo, Prolog e Kojo, sono nel sito di accompagnamento al libro e li possono scaricate tutti.

Bene, ora arriva la domanda cruciale: ma se usiamo un computer per tirar fuori tutte queste parole, non stiamo limitando la creatività nostra o dei bambini?
Io non credo. Per due motivi che mi pare possano fondarsi proprio su quello che Rodari ha scritto, come ho cercato di spiegare in “Rodari digitale“, l’ultima fatica di quest’anno.

Primo: la parte creativa non è quella di andare a cercare le parole, ma quella di costruire la storia. La ricerca delle parole è la parte meccanica, che richiede l’accesso ad un archivio di parole e alcune regole. Altrimenti basterebbe avere nove parole per fare una poesia (“Si sta come d’autunno sugli alberi le foglie”).

Secondo motivo: non sto proponendo di usare un programma bello e pronto, e nemmeno di cominciare da zero. Propongo di partire da un codice sorgente che funziona, ma di metterci le mani da subito. Cambiando le parole di partenza, cambiando le regole (per esempio: solo sostantivi o anche verbi? quali preposizioni?). Variando la tecnica: tre parole invece di due; oppure aggiungendo i prefissi e i suffissi, i diminutivi e vezzeggiativi.

Terzo motivo (non era previsto, ma lo aggiungo lo stesso): un computer sarà pure ottuso, ma non c’è limite alle cose creative che possono fare un umano e un computer, insieme.

Caso amico ti scrivo

Dic
04

Il ruolo del caso nella sperimentazione è fondamentale. Lo sanno gli artisti, che l’hanno usato come motore di generazione di opere. Basta andarsi a riprendere gli esempi di Queneau, di Calvino, dei dadaisti.
Ma a me il caso interessa come strumento didattico, di didattica della lingua e delle letteratura.
Per la precisione, come strumento che mette in evidenza la relazione tra semantica e sintassi, o meglio tra la staticità semantica e la tensione sintattica. La sintassi vista come una forza che spinge in una direzione precisa, mentre la semantica cerca di opporsi. Chiaro? Non tanto? Vediamo.

Partiamo da questa affermazione: “Un testo ha un significato complessivo che dipende dalle parole che lo compongono“.
Sembra una teoria banale. Ma è proprio vera?

Prendiamo un esempio: la poesia di Chamie Gorkin “Worst Day Ever?”. Questa poesia ha la particolarità di potersi leggere dall’inizio alla fine, oppure dalla fine all’inizio; ma offre un’interpretazione diversa, anzi opposta, a seconda della direzione. Non è un caso, naturalmente, è stata scritta apposta, sulla base delle convinzioni chassidiche dell’autrice.
Allora possiamo riformulare la nostra teoria: “Un testo ha un significato complessivo che dipende dalle parole che lo compongono e dal loro ordine. Se l’ordine delle parti del testo cambia, cambia anche il significato”.

Che succede se invece si mescolano i versi a caso? Beh, se gli elementi vengono mescolati a caso, il significato del testo si perde del tutto.
Ho scritto un frammento di codice in Snap! che fa proprio questo: scrive la poesia della Gorkin al dritto, al rovescio, e poi mescola i versi, ogni volta in maniera diversa. Lo trovate qui: https://snap.berkeley.edu/project?user=stefano63&project=worst_day

A priori potremmo dire che mescolando non si capirà nulla; ma se provate avrete delle sorprese. Compaiono dei frammenti, a volte lunghi tre-quattro versi, che sembrano avere un significato compiuto.
Perché? E’ una caratteristica di questa poesia particolare? Delle poesie in generale? O della maniera con cui sono stati scritti i versi?

In effetti, alcuni versi sono composti da una singola parola molto generica, che non ha valore di per sé, ma solo come aggancio tra il verso precedente e quello seguente (es. “Perché”, “Anche se”), oppure possono avere facilmente sia il ruolo di soggetto che di oggetti (“La realtà”, “Il mio atteggiamento”).
Altri sono fatti per rovesciare l’interpretazione del verso seguente (“E non è vero che”, “Non provare a convincermi che”). Insomma, il significato dei frammenti si costruisce in base all’accostamento di due o più versi, e il significato complessivo – se esiste – risulta dall’aggregazione di questi sotto-significati. Anzi: il significato si stabilizza alla fine della lettura, come una specie di media tra i sotto-significati.

Si può fare la stessa analisi, in maniera più semplice, a livello di frase. Prendiamo una frase semplice, di tre parole: due sostantivi (lupo, pecora) e un verbo transitivo (insegue).
La sintassi ci dice che quando il verbo è transitivo, il primo sostantivo è il soggetto e il secondo l’oggetto dell’azione espressa dal verbo. Il significato di:
lupo insegue pecora
è molto chiaro. Invertendo l’ordine delle parole la frase diventa
pecora insegue lupo
Dopo un momento di attrito, di sorpresa Rodariana, l’interpretazione torna ad assestarsi su quella precedente. Anzi, tutta la poesia che abbiamo imparato a scuola ci ha abituato a questo tipo di inversioni. Quella pecora messa all’inizio è un rafforzativo: è proprio la pecora che il lupo insegue, non un coniglio o una gallina.
Anche se si mescolano le parole, così:
pecora lupo insegue
insegue pecora lupo

il significato sembra resistere a tutti i nostri tentativi di scardinarlo.

Prendiamo una frase più complessa e mescoliamola.
il vorace gatto insegue un furbo topo
Potremmo ottenere:
topo gatto un vorace furbo insegue il
oppure
furbo un insegue gatto vorace il topo
Anche qui, il significato generale si capisce lo stesso, no? Perché?
Perché le parole sono semanticamente dense, e il rapporto tra esse si definisce indipendentemente dalla posizione reciproca. C’è una conoscenza implicita, anche se non diretta (non tutti hanno visto un gatto inseguire un topo) ma derivata dalle storie che abbiamo ascoltato o letto, che ci spinge verso un’interpretazione statisticamente più accettabile di quella opposta. I topi non sono descritti come voraci, e di solito non inseguono i gatti, tranne appunto nelle opere di Rodari.

Cambiamo frase di partenza:
credi che la vita sia felice non triste
Ora facciamo delle variazioni:
vita triste la credi non felice sia
la non credi felice vita sia triste

sia la vita credi triste non felice

Qui invece è evidente che l’ordine è fondamentale. “Triste” e “felice” si possono entrambi abbinare con “vita” senza che si possa sapere a priori quale relazione è più probabile (almeno, senza altre informazioni contestuali sulla biografia dell’autore, sul suo obiettivo, il destinatario).
Ci sono poi delle parole che acquistano un senso diverso a seconda della posizione. “Sia” è una parola ambigua, come un attore che può recitare parti diverse: può funzionare da verbo o da congiunzione; “credi” può essere un indicativo o un imperativo e anche “la” può essere articolo o pronome. Ovviamente la punteggiatura aiuterebbe a precisarne il ruolo (“ecco a che serve! ecco perché se non si usa succedono pasticci…”).

vita triste, la credi!, non felice sia
la non credi felice vita sia triste

sia vita – la credi triste? – non felice

Ecco allora spiegato il senso dell’esperimento: mescolare a caso consente di evidenziare il peso semantico, l’inerzia dei segmenti (delle parole, dei versi, delle frasi) rispetto alla tensione della sintassi, la quale invece spinge verso un’interpretazione che dipende dall’ordine degli elementi, secondo uno schema che si sovrappone alle parole. A seconda del valore di questo peso, la sintassi riesce, o non riesce, a rompere l’inerzia e a trascinare il significato nella direzione che vuole.
Questo è il valore didattico dell’uso del caso: rompere con l’abitudine a vedere le cose sempre nello stesso modo. Il caso ci propone un mondo non semplicemente al contrario, ma retto da regole diverse da quelle che conosciamo. Ci spinge ad esplorare queste regole, a confrontarle con quelle abituali e a capirle meglio.


Seconda parte: questo esercizio di applicazione del caso alla lingua si può fare a mente? Sì; ma è complicato se il testo è lungo. Si può fare su carta? Sì; ma se vogliamo cambiare testo dobbiamo ricominciare ogni volta da capo. Allora si può far fare ad un programma di computer? Eccoci qua.
Intanto sappiate che non è un’idea nuova; smontare e rimontare frasi lo si faceva anche con il linguaggio Logo, quello delle tartarughe, che oltre a permette di disegnare girandole e casette permette molto, ma molto facilmente di lavorare con liste di parole, rigirarle, estrarre pezzetti. Inoltre i computer sono abbastanza bravi a tirare fuori un numero a caso; più bravi di noi, che in qualche modo rischiamo di essere orientati da qualche associazione inconsapevole. Quindi sì, si può fare, e in più ha il vantaggio di permetterci di sperimentare con tanti testi diversi senza modificare il programma. Per esempio, invece della poesia della Gorkin si può provare con i versi della Divina Commedia. Come ho fatto qui: https://www.stefanopenge.it/inferno/

Il sommo poeta avrebbe amato
i computer?

Ma non c’è solo il vantaggio della forza bruta del computer.

Prima di provare a scrivere un pezzetto di codice che permette di rovesciare una poesia, bisogna domandarsi come si farebbe a mano, sulla carta. La risposta probabilmente è questa: si prende l’ultima riga della poesia, si cancella, e si ricopia in testa, e così via. E invece no, questa modalità non funziona: alla fine si ottiene la stessa poesia iniziale (provate). Quindi?
Quindi si possono usare due liste: quella iniziale (la poesia originale) e quella finale (la poesia rovesciata). Si prende l’ultimo verso dalla prima, lo si cancella e lo si mette come primo della seconda, e così via, finché la prima lista di versi è vuota.
Lo stesso sistema si può usare per mescolare a caso i versi di una poesia. Si prende una riga a caso dalla poesia originale, la si cancella da lì e la si inserisce in testa alla seconda lista. Quando la prima lista è vuota, la seconda contiene una copia mescolata.
Perché questa attenzione alla modalità carta-e-matita? Perché il coding serve soprattutto a questo: a riflettere sulla maniera in cui facciamo le cose, esplicitarla, discuterla, verificarla. A volte alcune cose pensiamo di saperle fare, ma non è vero; in questo caso, è l’occasione per andare a cercare dei metodi, che poi potremo mettere in pratica. In generale, il percorso è da dentro a fuori, e non il contrario. Una volta fatto questo, si può cominciare a scrivere codice (o a trascinare blocchetti, come preferite).
Ma ci sono tanti modi diversi di mescolare un testo. Possiamo aggiungere dei vincoli: nessun verso deve restare nella posizione originale; oppure le coppie di versi presenti nella poesia originale non devono ripresentarsi insieme in quella mescolata. Questo sarebbe un po’ noioso da fare sulla carta, ma non particolarmente con la versione digitale.
Usare un computer per programmare questo frullatore di testi offre però un altro vantaggio che è legato alla “consapevolezza” dei programmi, cioè al fatto che quando fanno un’azione possono registrarne il risultato, cosa che per noi umani è più lungo e faticoso, e soggetto ad errore. Siccome le azioni che fa il programma le possiamo accelerare e rallentare a piacere, possiamo fargli generare cento volte una nuova versione mescolata a caso e registrarle tutte.
Potremmo misurare il grado di mescolamento della frase in termini di distanza dalla versione originale. Poi possiamo “votare” le versioni in cui il significato è più chiaro, e mettere i voti in relazione con il grado di mescolamento degli elementi. Alla fine potremo verificare se è proprio vero che un’insalata più assomiglia all’originale, più mantiene il significato; o forse scopriremo altre regolarità. Per esempio, pensando ad una frase: ci sono parole che galleggiano più facilmente di altre? i verbi hanno un ruolo più importante? oppure le preposizioni? o le parole astratte? E le relazioni transitive soffrono di più dello spostamento rispetto alle descrizioni di una qualità o di uno stato? Eccetera.

Insomma ecco un altro esempio di come fare coding possa servire a mettere alla prova una teoria implicita e a imparare qualcosa su come funziona il mondo.

Ambiguità felice dei linguaggi

Feb
23

C’è una barzelletta che gira da tempo sui programmatori, esseri inadatti al mondo reale. Dice così:

La mamma dice a Pierino: vai al mercato e compra 2 litri di latte. Se ci sono le uova, comprane 6.
Pierino va e torna con 6 litri di latte.
La mamma: Perché hai comprato 6 litri di latte?
Pierino: Perché c’erano le uova.

Finite le risate per la risposta di Pierino (che immaginiamo essere il risultato di una specie di programma: IF ci sono le uova THEN comprane 6), ci accorgiamo che il problema è in quella particella “ne”, che è un riferimento pronominale. Di quelle cose che abbiamo detto prima. Un link, una URL relativa.
In Italiano, di solito, si riferisce all’ultimo sostantivo utilizzato. Quando ce ne sono più di uno (di che? di sostantivi) di solito con un minimo di interpretazione si capisce a quale ci si riferisce.
Se la mamma avesse detto:
[…] Se c’è lo zucchero, comprane 6 litri.
un parlante Italiano avrebbe capito che il riferimento era al latte, perché sa che lo zucchero non si vende a litri.

E’ uno degli aspetti tipici del linguaggio naturale: un riferimento generico può essere comodo in molti casi, ma può creare dubbi in altri. Dubbi che vanno risolti con delle ipotesi, oppure nell’interazione (“Scusa, mamma: 6 di cosa?”).

Si dice che i linguaggi di programmazione, essendo “formali”, non soffrono di queste malattie, anzi sono stati costruiti apposto per esserne immuni. La barzelletta prende in giro proprio questa ottusità dei computer, dei linguaggi, dei programmi. I computer non interpretano i programmi, ma li eseguono rigidamente. Per cui niente libertà, niente interpretazione, niente poesia, solo correttezza e efficienza.

Ma siamo proprio sicuri che sia così? Facciamo un gioco: traduciamo la storiella in un linguaggio molto usato per il web, ovvero PHP (tranquilli: il discorso può essere seguito da chiunque, anche senza nessuna competenza informatica).

$lista = Array (
 latte => 1,
 uova => 6
 );

In questo frammento di codice sorgente viene creato un dizionario ($lista), cioè una set di dati organizzati per coppie chiave/valore (latte=1, uova=6).
Ci si mettono dentro le informazioni e poi si possono estrarre quando servono.
Scrivendo così:

 print_r($lista);

possiamo vedere cosa c’è dentro $lista:

Array
(
    [uova] => 6
    [latte] => 1
)

Oppure, volendo andare più in dettaglio:

 
print_r($lista[latte]);

cioè: scrivi sullo schermo il valore della chiave “latte” nell’array $lista.
Che è, ovviamente, 1.

Se però guardiamo cosa succede dietro le quinte, ci accorgiamo che l’interprete ha segnalato due errori veniali:

PHP Notice: Use of undefined constant latte - assumed 'latte'
PHP Notice: Use of undefined constant uova - assumed 'uova'

E’ un nostro errore di scrittura: le chiavi sono state scritte come se fossero costanti (cioè senza le virgolette che invece accompagnano le stringhe di caratteri), ma non esiste nessuna costante che si chiama latte, né uova. Ma cosa ha fatto l’interprete PHP, oltre a segnalare l’errore? Ha fatto un’illazione, cioè ha supposto che si volesse scrivere:

'latte' =>1,
'uova' => 6

che sembra in effetti l’interpretazione più ragionevole.

Se siamo bravi programmatori e programmatrici, una volta letta la segnalazione correggiamo il codice, e tutto fila liscio.
Anzi, per essere ancora più precisini, creiamo una costante (visto che ci era stato chiesto), ma le diamo un valore un po’ bizzarro:

define('latte',uova);

Cioè: abbiamo definito una costante che ha come nome “latte”, ma come valore “uova”.
Vi sembra confondente? Ma il linguaggi di programmazione sono precisi, no? Quindi nessun problema: da un lato la costante, dall’altro la chiave.
E infatti, se avessimo lasciato le cose come stavano, non ci sarebbero stati problemi. Ma noi abbiamo voluto essere rigorosi e abbiamo creato la costante E messo gli apici intorno alle chiavi.
Ora se chiediamo:

print_r(latte);

(ovvero: qual è il valore della costante “latte”?), otteniamo la stringa “uova”, come prevedibile; mentre se chiediamo di nuovo:

print_r($lista[latte]);

il risultato non è né “uova”, né 1 ma …  6 !
Il che naturalmente ha una sua logica. Si potrebbe dire che l’interprete ha usato il riferimento pronominale nella nostra richiesta, e ha interpretato la chiave dell’array $lista[latte] come la costante “latte” che era stata definita prima. Ma non è quello che volevamo dire. Insomma, dal nostro punto di vista,  si confonde e restituisce 6, cioè interpreta il codice come se avessimo scritto:

print_r($lista[uova]);

Proprio come Pierino.

Ora cambiamo l’ordine delle chiavi:

$lista = Array (
 'uova' => 6,
 'latte' => 1
 );

e chiediamo di nuovo:

print_r($lista[latte]);

Dovrebbe essere uguale a prima, no?
Eh no, adesso il valore restituito è tornato ad essere 1!
Meglio, dite? Insomma… se provate a scrivere:

print_r($lista);

vi accorgete del pasticcio:

Array
(
    [uova] => 1
)

La chiave latte è stata sostituita da uova (con valore 1) e la chiave uova, che avevamo inserito con valore 6, è stata cancellata.

Certo PHP non è un modello di precisione, per un linguaggio di programmazione. Ma insomma: anche un linguaggio di programmazione è soggetto ad una forma di ambiguità referenziale. E questo dipende, come abbiamo visto, dall’ordine in cui vengono inserite le informazioni nel testo.
Come in una qualsiasi lingua naturale…

Ancora sugli algoritmi

Feb
07

Tornano di moda, arrivano sulle prime pagine dei giornali, sono oggetto di approfondimenti (come questo sul Sole 24 ore di qualche mese fa) e di libri (come questo di Mario Pireddu appena uscito). Quanto sarebbe stato felice il vecchio Abū Jaʿfar Muḥammad ibn Mūsā al-Khwārizmī, matematico, geografo, astronomo persiano del IX secolo, autore di un libro famosissimo, tradotto in Latino col titolo di “Algoritmi de numero Indorum” (generando un po’ di confusione tra il nome dell’autore e l’argomento).
Però gli algoritmi di oggi non hanno a che fare con l’algebra ma con l’informatica: si tratta della definizione di una procedura in passi elementari, così semplice che la può eseguire anche una macchina. Ci sono esempi famosissimi: l’algoritmo detto “Crivello di Eratostene” per trovare tuttii numeri primi, oppure il Bubblesort per ordinare una lista.

Gli algoritmi sono quella cosa che, se espressa in un linguaggio di programmazione, dà origine ad un programma. Per esempio, questo algoritmo:

  1. Ripeti per sempre l’istruzione seguente
  2. Scrivi “CIAO” sullo schermo

potrebbe essere rappresentato così:

 

 

 

e potrebbe essere scritto in BASIC così:

10 PRINT "CIAO"
20 GOTO 10

Ma nell’uso attuale (almeno di questi ultimi dieci anni, da quando in Italia è uscito “L’algoritmo al potere. Vita quotidiana al tempo di Google” di Francesco Antinucci, Laterza, 2009) algoritmo ha un’accezione ancora più ristretta. Sono chiamati così quei programmi che:
a) raccolgono dei dati relativi ai comportamenti delle persone, tipicamente online
b) li  utilizzano per costruire un profilo delle stesse persone
c) usano il profilo per fare, o supportare, delle scelte

Ci sono vari punti oscuri: la liceità della raccolta dei dati all’insaputa dell’utente, la maniera in cui viene costruito il profilo e soprattutto l’utilizzo del profilo per scopi illeciti (per esempio, aumentare un premio assicurativo o rifiutare una candidatura per un posto di lavoro).

Ora non entriamo nella discussione sui guadagni reciproci dell’utente e del fornitore di servizi, sulla necessità di policy di trasparenza e cancellazione, sulla possibilità reale di non utilizzare quei servizi. Probabilmente il tema si incrocia con quello del ritorno in auge dell’Intelligenza Artificiale, dei robot, dei big data, del machine learning, in un allarme generale sull’imminente presa del potere da parte delle macchine. Algoritmo è solo un modo diverso di dire “automatismo fuori dal controllo umano”.  Ma allora è proprio l’uso del termine algoritmo che è fuorviante.

Qualsiasi programma – dal client di posta elettronica al foglio di calcolo – contiene migliaia di algoritmi, o meglio può essere letto attraverso la lente dell’algoritmo che implementa, esattamente come un proposizione in una lingua naturale può essere letta attraverso le strutture sintattiche di quella lingua. Gli algoritmi non abitano un loro mondo a parte, non hanno uno statuto speciale. Per essere spiegati, raccontati, analizzati, devono essere espressi anche loro in qualche linguaggio (anche con fumetti, come in questo manuale introduttivo). E’ vero che per mostrare che due programmi, magari scritti in due linguaggi diversi, fanno la stessa cosa nello stesso modo si dice che implementano lo stesso algoritmo e si descrive questa parte comune con un terzo linguaggio  più generale degli altri due. Linguaggio che può essere più o meno formale . Ma insomma, gli algoritmi non sono l’anima dei programmi, non esistono prima del programma o in un universo separato, ma sono solo un modo per parlarne da un certo punto di vista (quello della correttezza, dell’efficienza). In un articolo di qualche tempo fa mi interrogavo sul senso di questa visione platonica, che è talmente presente nella nostra cultura che è difficile esserne coscienti.

E quindi parlare di algoritmo invece di programma è una raffinatezza di cui francamente non capisco il vantaggio. E’ come dire: non metto sotto accusa quel libro, ma le idee che ci sono dentro. Le quali idee però (ammesso che preesistessero alla stesura del libro) sono state estratte e  riassunte da qualcuno dopo aver letto il libro.

Peraltro, nei casi sopra citati, il punto non è l’esistenza di un algoritmo (è ovvio che ci sia, altrimenti non ci sarebbe nemmeno il programma) e nemmeno la natura dell’algoritmo, ma i pesi che gli vengono forniti; pesi stabili da persone umane, non da macchine. Per esempio, il fatto che voi leggiate questo articolo  potrebbe avere un peso negativo, o comunque legato alla reputazione del suo autore, nella costruzione e aggiornamento del vostro profilo da qualche parte. Questo è deciso da qualcuno, non da un algoritmo, il quale si limita a comporre il profilo utilizzando i pesi forniti e applicandoli.

Parlare di algoritmi cattivi ha senso tanto quanto parlare di strutture sintattiche malvage. Gli algortmi possono essere valutati, ma in termini di efficienza, scalabilità, robustezza, magari eleganza. Prendersela con loro per il cattivo comportamento dei consigli di amministrazione delle società che offrono serivizi gratuiti online – in cambio dell’accesso libero a dati che poi rivendono – mi sembra un po’ ingiusto nei confronti del vecchio al-Khwārizmī e francamente anche dell’informatica.

Poeti, navigatori, santi e cuochi: cosa insegna la linguistica computazionale al coding?

Gen
31

L’incontro tra informatica e letteratura avviene ufficialmente, almeno in Italia, quando nel 1949 Padre Busa SJ si dedica all’immane compito di compilare un Index Thomisticus, cioè un repertorio di tutti i termini utilizzati dall’Aquinate nelle sue opere. Per farlo, chiede il supporto dell’IBM (parlando con il suo fondatore, Watson) e inizia un lavoro di lemmatizzazione durato trent’anni. Dopo la versione cartacea (1980) e quella su cdrom (1989), nel 2005 nasce la versione web (http://www.corpusthomisticum.org/it/index.age).

La linguistica computazionale si presenta così con un aria seriosa, doppiamente sostenuta dall’oggetto (il testo classico) e lo strumento (il programma di lemmatizzazione e ricerca), per non parlare dello scopo scientifico.

Ma ci sono stati altri incontri meno nobili, come quello tra il libro cartaceo Cent Mille Miliards de Poèms di Raymond Queneau e il web. Per chi non avesse avuto la fortuna di sfogliare quel meraviglioso oggetto, si tratta di un libro pubblicato nel 1961 che raccoglie dieci sonetti di quattordici versi ognuno. La peculiarità che lo rende unico è la pagina è tagliata in orizzontale in modo da rendere ogni verso un oggetto autonomo; è possibile così leggere (e costruire con la mente) un sonetto costituito, poniamo, dal primo verso della prima pagina, il secondo dalla decima, il terzo dalla quinta, e così via. Le possibilità totali sono 1014, cioè appunto 100.000.000.000.000. Di questa macchina per generare sonetti ne esistono varie versioni consultabili su web, come per esempio questa: http://www.growndodo.com/wordplay/oulipo/10%5e14sonnets.html

Queneau realizza (cioè “dimostra la possibilità”) di qualcosa che nel cielo delle invenzioni letterarie era ben nota. A partire per lo meno dalla macchina creata dagli scienziati dell’Accademia di Laputa:

La superficie risultava di vari pezzetti di legno, grossi press’a poco come dadi, alcuni di maggiore dimensione degli altri. Erano tutti congiunti da esili fili di ferro. Incollata sopra le quattro facce dei pezzetti di legno era della carta, e su questa si trovavano scritte tutte le parole della loro lingua, coniugate nei diversi modi e tempi e declinate nei vari casi, ma senza ordine veruno. Il professore m’invitò a prestare attenzione, ché appunto s’accingeva a mettere in moto la macchina. Ciascun discepolo prese, al cenno del maestro, un manico di ferro (ce n’erano quaranta fissati intorno agli orli della macchina) e d’un tratto lo fece girare. Naturalmente la disposizione delle parole cambiò in tutto e per tutto. Il maestro ordinò allora a trentasei scolari di leggere pian pianino i vari righi così come apparivano sulla macchina; e quando quelli trovavano tre o quattro parole unite insieme che potevano far parte d’una sentenza, le dettavano ai quattro rimanenti discepoli che fungevano da scrivani (Jonathan Swift, I viaggi di Gulliver, Traduzione di Carlo Formichi, a cura di Masolino d’Amico, Mondadori, Milano, 1982, p. 393).

passando, naturalmente, per Borges, Levi, Landolfi e Dahl. Molti altri esempi sono citati in questa trascrizione di una bellissima conferenza del 2015 tenuta da Paolo Albani (a meno che non sia anche questo un testo generato automaticamente) che potete leggere qui: http://www.paoloalbani.it/Letteraturacombinatoria.pdf.

Cosa mostra davvero questo strano artefatto, nella versione cartacea come in quella digitale? Che la letteratura (e in particolare la poesia) non è tutta intuizione ed espressione libera. Che il gioco tra sistema e creatività, tra regola ed eccezione, non è proprio così chiuso come sembra. La poesia, in particolare, nasce proprio dal vincolo (tematico, formale), come orizzonte e come sfida. Non lo dico io, lo dice Calvino: la letteratura è

“un’ostinata serie di tentativi di far stare una parola dietro l’altra seguendo certe regole definite, o più spesso regole non definite né definibili ma estrapolabili da una serie di esempi o protocolli, o regole che ci siamo inventate per l’occasione cioè che abbiamo derivato da altre regole seguite da altri” (Cibernetica e fantasmi. Appunti sulla narrativa come processo combinatorio, in: Una pietra sopra. Discorsi di letteratura e società, Einaudi, Torino, 1980, pp. 164).

E cosa fa il poeta quando crea, se non andare a pescare nella sua memoria linguistica e scegliere combinazioni di parole, vincolate da regole precise (come il metro o la rima)? Certo, la scelta è anche governata dal significato – in maniera difficile da precisare. Il poeta parte con l’idea da esprimere e cerca le parole più adatte? Oppure si lascia guidare dalle parole stesse, sfruttando somiglianze fonetiche, rimandi per analogia o opposizioni? O ancora, più probabilmente, attua un misto delle due strategie? Insomma: come si scrive, praticamente, una poesia?

E di qui l’idea di proporre delle attività didattiche di coding intorno ai temi della forma e della variazione, delle categorie, dell’accettabilità. In un periodo in cui il machine learning sembra riproporre il vecchio mito dell’intelligenza artificiale, viene voglia di ragionare intorno ai processi creativi anche utilizzando paradossi, e di provare a costruire un automa in grado, se non di scrivere poesie originali (come questo: http://thinkzone.wlonk.com/PoemGen/PoemGen.htm, o quest’altro fatto addirittura in Scratch che lavora per sottrazione da una poesia di Walt Whitman: https://scratch.mit.edu/projects/12331423/) almeno di inventare ricette sempre nuove, che tutto sommato sono sempre forme di testo vincolate, come questa: http://www.lynxlab.com/staff/steve/public/ricette.

Per restare nel dominio letterario, due modesti esempi di macchine figlie di quella di Queneau (ma che pescano nel testo di due classici sempreverdi come l’Inferno di Dante Alighieri e l’Orlando Furioso di Ludovico Ariosto) li trovate qui http://www.lynxlab.com/staff/steve/public/inferno e qui http://www.lynxlab.com/staff/steve/public/orlando. Oltre a Queneau, questi due oggetti digitali si ispirano più precisamente a “Il centunesimo canto. Philologica dantesca“di Luca Chiti, che è un meraviglioso esempio di centone umoristico che “crea” un intero canto giustapponendo versi esistenti ma dandogli un senso completamente nuovo. Per realizzarli, ho dovuto affrontare problemi letterari, come la definizione di rima, di struttura metrica, di novità e ripetizione (oltre che qualche problema informatico, come il loop infinito o la conversione dei caratteri in UTF-8). Non ho seguito alla lettera le indicazioni di Nanni Balestrini, ma ci sono andato vicino. Ed ecco apparire terzine più o meno improbabili come la seguente:

Parlando cose che ‘l tacere è bello
rispuosemi: «non omo, omo già fui
venimmo al piè d’un nobile castello

o come questa:

Nel nome che sonò la voce sola
poscia vid’io mille visi cagnazzi
cosí vidi adunar la bella scola

Una valutazione estetica del risultato? Non è l’obiettivo, anche se può essere divertente provare e riprovare, fino a far emergere dei frammenti di senso che possono essere anche divertenti. Ma quelle che mi paiono importanti, come sempre, sono le domande che emergono ogni volta che si prova a realizzare un modello funzionante di una teoria: come si riconosce una rima? Come si produce una struttura metrica? Come si ottiene un testo casuale sempre diverso? Come si riconosce che il testo non è stato scritto da un poeta umano?

Mi sembrano tutte domande legittime da porsi in una classe che studia letteratura: portano con sé riflessioni e discussioni che integrano, anche se non sostituiscono, l’apprendimento di nomi di forme di testo come “trimetro scazonte” o “endecasillabo sciolto” o di opere particolari.

E ancora una volta mostrano come la costruzione reale di un programma possa essere un’attività didattica sensata al di là di ogni mitologia computazionale.

 

Un elefante, sei ciechi e quattro saggi

Gen
12

Warning: count(): Parameter must be an array or an object that implements Countable in /web/htdocs/www.stefanopenge.it/home/wp/wp-includes/formatting.php on line 3361

Giocando con gli articoli

Dic
02

Sono capitato su una proposta di esercizio di coding con Scratch che ha il pregio di non portare in giro il gattino, ma di occuparsi di lingua, il che è una bellissima cosa.
La proposta è quella di realizzare un quiz. Nell’immagine si vede il codice: il quiz è programmato in modo da chiedere al bambino un articolo, determinativo o indeterminativo.
Se viene fornito un esemplare corretto, il gioco-quiz risponde “bravo” altrimenti “hai sbagliato” (non ho chiesto il permesso di ripubblicare l’immagine, spero che nessuno se ne abbia a male).
esercizio sugli articoli
Si potrebbero dare alcuni suggerimenti generali (“bravo”: e se risponde una bambina? “hai sbagliato”; non è molto invitante a continuare…). Il tutto potrebbe essere reso più divertente con poco sforzo dal lato dei messaggi, inventando un contesto più o meno fantastico, una storia intorno, etc.

Ma qui vorrei parlare del senso dell’attività e non della sua forma, che è sicuramente embrionale e migliorabile anche nelle intenzioni di chi ha proposto l’esercizio.

Veloce ripasso: nella grammatica tradizionale ci sono le parti del discorso variabili e quelle invariabili. Tra quelle variabili, almeno per l’Italiano, ci sono gli articoli. Gli articoli si dividono in determinativi e indeterminativi. Poi ci sarebbero gli articoli partitivi ma lasciamoli da parte.
Ci sono due modi di fare attività sulla classe degli articoli e sulle sue sottoclassi:
– data la classe, elencarne i membri (elencazione esaustiva);
– dato un articolo, dire a quale classe appartiene (categorizzazione).

Sembrano equivalenti, ma non lo sono. Il primo modo ha un valore solo didattico/valutativo, ovvero ha senso solo per verificare se si conosce la collocazione degli articoli nella gerarchia, all’interno delle attività di apprendimento.
Il secondo invece ha un senso pratico, cioè va a toccare la capacità di fare inferenze, che è poi il motivo per cui si impara la grammatica. Le etichette servono come ganci mnemonici, ma quello che è importante è sapere quando va usato un tipo di articolo. E questo può servire a parlare e scrivere correttamente, oppure – più importante – a far capire quello che si intendeva dire, o a capire quello che è solo sottinteso. E’ la potenza meravigliosa del linguaggio, che consente di dire molto con poco; ma questa potenza si controlla solo con la conoscenza delle regole grammaticali (sintattiche, etc).
Ad esempio, dalla frase:
1)    Giovanni è venuto con il figlio.
se sono in grado di categorizzare correttamente “il” come determinativo, e so cosa significa determinativo, posso inferire che Giovanni ha un solo figlio, maschio.
Invece dalla frase:
1a)    Giovanni è venuto con un figlio.
se sono in grado di categorizzare correttamente “un” come indeterminativo, e so cosa significa, posso inferire che Giovanni ha più figli (o figlie), di cui almeno uno è maschio.
Ci sono casi più complessi dell’uso dell’articolo determinativo, come quando si premette ad un sostantivo per indicare un caso tipico, generale (“L’uomo è un animale razionale”) invece dell’individuo, ma lasciamoli da parte.
Volendo programmare un quiz sugli articoli mi sembrerebbe più utile lavorare sul secondo modo (categorizzazione). Per esempio, dato come stimolo un articolo a caso, chiedere al bambino di categorizzarlo come determinativo o indeterminativo.
In entrambi i casi, chi programma deve sapere quali sono gli articoli, come si chiamano le sottoclassi e quali articoli ne fanno parte; e poi saper gestire un ciclo, la generazione di un numero casuale, un input, un test di appartenenza ad una lista e un output. Sono cose che deve sapere già, non le scopre programmando.

Però i computer si possono usare anche in altri modi, oltre che come esercitatori automatici. Si possono programmare come automi (linguistici in questo caso) che siano in grado di agire, rispondere, categorizzare. Non è il computer che sa e che mi interroga (surrogato del maestro), ma sono io che gli insegno (à la Papert). La differenza forte è che in questo modo si procede a partire dalla conoscenza implicita della lingua che i bambini hanno, si cerca (attraverso un confronto di gruppo e con l’insegnante) di formalizzarla e poi di codificarla. Si possono fare delle ipotesi, su quella base creare un programma e poi valutare se il risultato è soddisfacente ed eventualmente tornare sul codice.
Ad esempio, si può programmare un robot che sia in grado di dire se un articolo (fornito dal bambino) sia determinativo o indeterminativo. Meglio ancora, un robot che sia in grado di fare un’inferenza basata su questa informazione.
Il robot potrebbe:
– ricevere una frase in input (es. “Giovanni è venuto con il figlio“)
– cercare all’interno della frase un articolo;
– se lo trova, cerca di categorizzarlo come determinativo o indeterminativo, e come maschile o femminile.
– inferire delle informazioni e restituirle in output (“Giovanni ha un solo figlio ed è maschio“).

Il robot non è perfetto, e ci sono parecchie cose interessanti che possono succedere. Per cominciare, la frase potrebbe non contenere un articolo; o contenere un ambiguità (“Giovanni è venuto con l’insegnante“). Il robot dovrà essere in grado di trattare con la mancanza di informazioni sufficienti (“Giovanni ha un(una) insegnante, ma non so se è maschio o femmina“).

Il robot si può, un po’ alla volta, rendere più intelligente. Potrebbe cioè essere in grado di decidere quale, delle tre forme possibili di articolo maschile (un/uno/un’ e il/lo/l’)), si può applicare davanti ad un sostantivo che comincia per vocale, per consonante, o per una serie particolare di consontanti (Z, GN, SB, SC, SF, SG, SL, SM, SN, SP, SQ, ST, SV). La composizione di questa speciale serie di consonanti si può scoprire un po’ alla volta, facendo delle prove ad orecchio (“Il gnomo? un spazzacamino?”),
Si può anche andare oltre la lingua italiana per come la conosciamo, e domandarsi come si dovrebbe comportare il robot con parole come “swarosky”, o “ngorongoro”. Qui non può che aprirsi una discussione, interessantissima a mio parere, su cosa è più “logico”, su che significa “normale”.

Questo schema generale si può applicare ad altre parti variabili del discorso. Per esempio, sui sostantivi e sul genere: come si fa a determinare il genere di una parola?
Che rapporto c’è tra genere (grammaticale) e sesso? Ci sono altre informazioni che possono essere utili, oltre alla finale della parola, per inferire il genere (es. “l’insegnante severa“).

Oppure si può applicare ad ambiti completamente diversi di categorizzazione. Per sempio, si può programmare un robot che sia in grado di distinguere i triangoli equilateri, isosceli e scaleni. Qui non c’è una conoscenza implicita da parte dei bambini, o è molto vaga. Si può partire da alcune domande, per esempio sul rapporto tra angoli e lati; si possono mostrare dei triangoli diversi e provare a categorizzarli intuitivamente. Dipende dagli obiettivi dell’attività e dal livello di conoscenza della geometria.
Il robot potrebbe:
– ricevere tre angoli in input (es. 80, 20, 80)
– verificare se si può disegnare una figura chiusa con quegli angoli (come?), se si disegnarla
– verificare se ce ne sono tre uguali; se si, è equiangolo (ed equilatero), se no:
– verificare se ce ne sono due uguali; se si, è isocele, se no è scaleno
– inferire delle informazioni e restituirle in output (“Siccome due angoli sono uguali, lo sono anche due lati“).

Prima di arrivare agli angoli, si potrebbe provare a usare i lati, per scoprire che i lati non sono sufficienti per disegnare il triangolo. Oppure, previo qualche esperimento, scoprire che non servono tre angoli, ma ne bastano due. O andare avanti a scoprire le proprietà di simmetria dei triangoli equilatero e isoscele (se li si gira su un asse restano “uguali”). Si può sperimentare con un numero di lati maggiore di tre. Non sono un insegnante di geometria piana, quindi sicuramente manco qualcosa di fondamentale, ma credo di aver reso l’idea.
Fare entrambi i tipi di attività (sulla lingua e sulla geometria) aiuta a definire una tipologia di problema, quella della categorizzazione, e riflettere sulle strategie trasversali che si mettono in anno per risolverla, sulle differenze tra i domini, sull’essenza delle definizioni, sul concetto di norma. Programmare il robot è un ottimo modo, a mio parere, di rendere visibili, condividere e discutere, queste strategie. Purché lo si faccia in maniera costruttiva, sperimentale, e non limitandosi a disporre blocchi.

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”.