steve's

apprendimento digitale e dintorni

The body snatcher (carrozze, videoconferenze ed educazione)

Apr
07

Tempo fa, a proposito degli ipertesti, scrivevo che il digitale è un vampiro, che succhia la realtà. Avrei dovuto scrivere che è più simile agli ultracorpi del film omonimo del 1955 (che penso tutti conoscano, in una delle sue versioni). Il titolo originale del film era “The body snatchers”, i ladri di corpi.

Secondo Bolter e Grusin (che all’epoca non conoscevo), il digitale “remediates” l’analogico, secondo una dialettica propria del processo mediatico, di tutti i media: la fotografia rimedia la pittura, etc. Mescola insieme media diversi (hypermediacy) e così facendo tenta di diventare trasparente (immediacy) come medium.

A me sembra che il digitale faccia una cosa un po’ diversa e specifica. Imita e sostituisce. Copia con il preciso scopo di prendere il posto dell’originale, come gli ultracorpi appunto.

La maggior parte degli artefatti digitali nasce come imitazioni di artefatti analogici. A partire da immagini e suoni digitali, che sono campionamenti discreti e che vengono rimesse insieme con un software per dare l’illusione della realtà. Lo smartphone imita il telefono, non solo nel senso che ne assume tutte le funzioni, ma nel senso che digitalizza tutte le sue parti (la rubrica, la selezione, la codifica della voce, l’invio e la ricezione) e le trasforma in software e dati.

Una volta fatta questa operazione, l’intero oggetto telefono si può rappresentare dentro un altro sistema digitale, cioè un computer. Per esempio ci sono simulatori di videogiochi, ma anche simulatori dei computer con cui si giocava a quei videgiochi.

La pagina del quaderno e quella del libro, compreso l’inchiostro, e poi l’indice e la copertina, sono stati digitalizzati. A questo punto, l’hardware che li contiene e permette l’interazione da parte di organismi fisici come noi diventa quasi indifferente (immediacy). Di qui, tra l’altro, l’ambiguità e confusione tra ebook (contenuto), ebook reader (software) ed ebook reader (hardware contenente).

Va anche detto che di solito si pensa solo ai dati che vengono convertiti e si mette meno l’accento sul software, che invece è essenziale per imitare i comportamenti che ci sono consueti con quei dati. Se i dati possono essere semplicemente campionati e riprodotti, le funzioni invece vanno analizzate e ricreate (poggiare la punta della penna sul foglio, premere, trascinare, staccare; e poi cancellare, sottolineare, etc.).

Non affronto questo tema per denunciare i rischi della virtualizzazione e per decantare la bontà del buon vecchio oggetto fisico o della sua rappresentazione analogica. Voglio solo sottolineare il fatto che questa capacità di replicare completamente per sostituire è tipica del digitale ed è una rottura rispetto a tutta la storia dei media precedenti.

Qual è il vantaggio di questo processo? Sullo stesso hardware posso simulare infiniti oggetti diversi. Quindi mi costa di meno. Con lo stesso linguaggio di programmazione posso creare infinite simulazioni. Quindi ottimizzo le competenze. Lo stesso stile di interazione si può applicare a infiniti ambiti diversi. Quindi ne facilito l’uso.

Queste, in breve, le ragioni economiche e sociali che hanno spinto il digitale fino alla situazione di dominio che oggi gli riconosciamo. Ma più interessante è, a mio parere, quello che succede quando ci si allontana dall’imitazione e si provano a creare modi di interazione del tutto nuovi. Interessante soprattutto per i fini educativi.

___

L’automobile è stata concepita, e poi presentata e quindi venduta, come carrozza senza cavalli. Si è portata dietro questo schema antico, per evolversi e allontanarsene un po’ alla volta (ma ancora parliamo di potenza in termini di cavalli). Non può staccarsi troppo perché trova dei limiti: il guidatore e il passeggero devono essere seduti comodamente, protetti dalle intemperie, ma contemporaneamente devono poter vedere la strada, etc. Fa qualcosa di diverso del carro con i cavalli: corre molto di più, è più piccola, ha maggiore autonomia, può rimanere ferma per mesi e poi ripartire, se non è in funzione non gli si deve dare da mangiare. Ma in fondo niente di radicalmente diverso dal carro.

Un po’ come la videoconferenza usata per le lezioni a distanza. Oggi è usata come una cattedra molto, molto lontana. Ancora non riusciamo a immaginarne un uso in quanto tale, non come simulazione di qualche altra cosa.

Spostiamoci un attimo nel mondo del coding. Guardando agli ambienti di programmazione visuale (sì, parlo di Scratch; ma pure di Snap! e di tanti altri) viene inevitabilmente in mente il LEGO come metafora. Ora immaginiamo una simulazione digitale proprio del LEGO originale (esiste davvero, in una versione più semplice di come la descrivo nel seguito, http://ldd.lego.com/en-us/). I mattoncini sono parallelepipedi colorati su uno schermo. Si possono girare in tutte le direzioni, spostare, congiungere.

Quali sarebbero le differenze con il LEGO del mondo reale?

  1. il numero dei mattoncini è teoricamente infinito (non lo è in pratica perché la il software, e la macchina su cui gira, hanno dei limiti fisici)
  2. è facile assegnare ai mattoncini digitali altre proprietà o comportamenti. Potrebbero diventare trasparenti, crescere; ma anche suonare, muoversi da soli, staccarsi e attaccarsi dopo un certo tempo.
  3. sulla base di queste proprietà si possono immaginare regole, giochi, interazioni che con i mattoncini di plastica non sarebbero possibili.
  4. queste nuove regole e interazioni possono essere immaginati da chi ha progettato il software, ma anche da chi lo usa, ammesso che il software lo permetta

Insomma questa immaginaria versione digitale del LEGO potrebbe essere riprogrammata, anche dai bambini. Questa è una differenza importante. Non è solo questione di portabilità, leggerezza, facilità, ma di legge costitutiva, di regole che sono in mano all’utente e non solo al produttore.

Qui il digitale mostra la sua potenzialità.

Ecco, questa è la strada. Staccarsi dai limiti che erano appiccicati all’immagine precedente, il LEGO, la cattedra,la carrozza con i cavalli, e creare qualcosa di davvero nuovo.

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…

Le sfide del digitale

Feb
16

A conclusione ed integrazione del corso “Le sfide del digitale”, due seminari aperti al pubblico.

Quando: Lunedì 26 Febbraio 2018 h 18
Dove: CESEDI della Città metropolitana di Torino, Via Gaudenzio Ferrari n. 1
Cosa:  “Dialogo tra un libro e un e-book
Con:
R. Marchisio docente corso e autore. “Dialogo tra un libro e un e-book.”
M.A. Donna scrittrice e poetessa. “Le ragioni del libro.
C. Manselli scrittrice e docente di scrittura creativa. “Le ragioni dell’e-book.”

______________________________________________________________

Quando: Giovedì 8 marzo 2018 h 16 – 18
Dove: Museo tecnologic@mente di Ivrea, Piazza San Francesco d’Assisi 4

ma per chi se lo fosse perso, anche:

Quando: Venerdì 9 marzo 2018 h 15 – 18
Dove: CESEDI della Città metropolitana di Torino, Via Gaudenzio Ferrari n. 1
Cosa: “Linguaggio e cultura digitale: progetti, idee, riflessioni”,

Con:
Rodolfo Marchisio “Perché è necessario continuare a parlare di cultura digitale.”
Eleonora Pantò, “Diversità in classe e Rosadigitale.”
Stefano Penge, “Codice sorgente, lingue e letteratura.”

I seminari di Torino  fanno parte del corso, autorizzato dall’USR Piemonte con decreto prot. n. 6547 del 19 luglio 2017 e, vista la presenza di esperti qualificati, sono aperti a tutti, ai soci della Associazione, ai corsisti Cesedi e a tutti i docenti interessati alle tematiche.
Per motivi organizzativi si prega di segnalare la propria partecipazione a mariagrazia.pacifico@cittametropolitana.torino.it (Maria Grazia Pacifico), marchisi@inrete.it (Rodolfo Marchisio).

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