steve's

Cosa significa “capire un testo”?
Sono più importanti le conoscenze sull’argomento (il background) oppure quelle sintattiche? Conoscenze o competenze?
Quanto conta la capacita di analizzare un testo alla ricerca di segnali conosciuti, o la capacità di astrarre strutture da frasi anche quando non si conoscono tutte le parole? O di cogliere analogie e immaginare varianti possibili?
Quanto è importante fare esercizi di questo tipo?

Roba vecchia trita e ritrita, sui cui sono stati fatti infiniti studi ma su cui molti, a mio parere, parlano un po’ a casaccio.
Più difficile avere un’opionione quando si parla di linguaggi di programmazione e di lettura di codice sorgente. Che però è un’attività reale, utile e molto comune. I programmi non solo si scrivono e si eseguono, ma si leggono. Sapere leggere un codice sorgente è un’abilità (o competenza?) fondamentale. Magari poco studiata.
Facciamo un esperimento. C’è un lettore medio a cui viene presentato un testo. Senza spiegazioni, senza commenti, senza contesto.
Un po’ come si fa con gli esercizi di italiano. Il testo è il seguente:

def trovaNano(nano: String, setteNani: List[String]): Boolean = setteNani.contains(nano)

Supponiamo che il lettore non abbia conoscenza approfondita di programmazione, ma conosca la matematica. Per esempio, che conosca il significato di funzione e di parametro, e il significato di tipo di parametro.
Potrebbe capire che:
– def è la dichiarazione di una funzione, il cui nome è trovaNano
– i parametri di questa funzione sono due: nano  e setteNani
– i parametri di questa funzione hanno un tipo: una stringa il primo e una lista di stringhe il secondo. Questo è un suggerimento sull’uso futuro di questo funzione: dovremo stare attenti a passargli dei dati che corrispondano a questi tipi
– il tipo del valore di ritorno (il risultato) è un altro suggerimento: la funzione restituisce true o false, quindi è una specie di test.

Il corpo della funzione è costituito dalla parte dopo l’uguale:

 setteNani.contains(nano)

Anche qui, senza particolari conoscenze, il lettore arriva a capire che
– contains è una funzione già presente nel linguaggio, o definita altrove.
– contains viene applicata ai due valori passati alla funzione, in un modo bizzarro ma che corrisponde abbastanza alla sintassi delle lingue naturali (soggetto-verbo-complemento).
Insomma: la funzione controlla se nano (che è il valore passato al primo parametro) è contenuto nella lista setteNani (il valore del secondo parametro) e restituisce true o false a seconda dei casi.

Può insomma immaginare come si userebbe questa funzione. Qualcosa di questo tipo:

trovaNano("Brontolo",List("Eolo","Mammolo","Dotto","Brontolo","Gongolo","Cucciolo","Pisolo"))

Quanto sono importanti le conoscenze della favola e del cartone Disney? Direi poco, ma un po’ conta senz’altro. Se il codice fosse stato:

def xyuw(werwer: String, dfsgaswerwer: List[String]): Boolean = dfsgaswerwer.contains(werwer)

di sicuro non sarebbe stato lo stesso, no?
Quanto è importante la conoscenza dell’inglese e della sua sintassi? Un po’. Almeno contains qualcosa ci ha detto.
Quanto la conoscenza di altri linguaggi formali? Se non si ha idea di cosa sia una funzione, e che una funzione ha bisogno di parametri e che restituisce un valore, non si capisce nulla. La matematica qui aiuta.

Lo stesso lettore, in seguito, si trova di fronte quest’altro testo:

def trovaNanoF(nano: String, setteNani: List[String]): Boolean = {
(
 for (n <- 0 to 6
 if setteNani(n) == nano
 ) yield "trovato"
).contains("trovato")
}

La lettura è un bel po’ più faticosa. Bisogna arrivare fino alla fine, magari rileggere più volte.
La prima riga è quasi uguale, salvo che il corpo della funzione stavolta è su più righe, inserite tra parentesi graffe {}. Questo non dovrebbe essere un problema per il lettore, che è abituato alle parentesi.
Poi c’è una paroletta magica, che il lettore avrà magari incontrato altrove: for. For si usa in quasi tutti i linguaggi per eseguire un ciclo, cioè una serie di operazioni ripetute.
Si capisce facilmente cosa fa questo ciclo: conta da 0 a 6, e per oguno dei nani della lista setteNani controlla che sia uguale al nome del nano passato alla funzione; se si, il ciclo restituisce “trovato”.
Qualche dubbio potrebbe esserci su quel doppio uguale (==) e sulla paroletta yield, che è si inglese, ma non proprio comunissima come for e if. Magari un dizionario inglese aiuta: raccogliere, rendere, produrre.
Se il lettore conta le parentesi tonde, si accorge che la parentesi che si apre prima di for viene chiusa dopo yield “trovato”. Dopo c’è una parola che ha già incontrato (contains) e di cui ormai sa il significato (un test che verifica se un valore è presente in una lista).
Ecco spiegato l’arcano: for produce una lista, e contains verifica che ci sia “trovato” in quella lista.

Il lettore curioso si domanda: perché usara una lista come risultato? E anche: perché scrivere una funzione di sette righe quando se ne poteva usare una di una riga sola? Beh – si potrebbe rispondere il lettore in quel dialogo interno che è così importante nella lettura –  perché avremmo potuto usare la funzione anche con una lista un po’ ingrossata di nani:

trovaNano("Brontolo",List("Eolo","Mammolo","Dotto","Dotto","Brontolo","Gongolo","Cucciolo","Brontolo","Pisolo"))

E avremmo potuto inventare una variante  in cui yield restituisca non vero o falso, ma un numero, cioè l’ordine del nano (o dei nani) trovati nella lista:

def trovaNanoF(nano: String, setteNani: List[String]): Seq[Int] = {
for (n <- 0 to 8
 if setteNani(n) == nano
) yield n
}

Quanto è stata difficile la comprensione? Non è tutto chiaro, ma insomma il grosso si capisce.
Almeno per chi abbia già letto o scritto codice in altre occasioni. Senza una conoscenza pratica di for e if, senza la capacità di fare analogie o di immaginare varianti… mmmh.

Infine, l’intrepido lettore si imbatte in questo testo:

def trovaNanoR (nano: String, setteNani: List[String]): Boolean = {
setteNani match {
 case List() => false
 case unNano::altriNani if unNano==nano => true
 case _::altriNani => trovaNanoR(nano,altriNani)
}
}

Avendo letto i testi precedenti (che ora fanno parte del background), il lettore può immaginare che la funzione faccia qualcosa di simile alla precedente, ma stranamente senza usare cicli. L’inglese non ci aiuta molto (match? case?). Cosa è quel List()? Se ha sviluppato una capacità di vedere le strutture facendo astrazione dai contenuti, il nostro lettore andrà a cercare frasi che hanno un andamento regolare, con ripetizioni. Magari ipotizzerà che è stata usata una struttura sintattica formata da:

X match {
 case a => ...
 case b => ...
}

Vedere questa struttura però non è facile, almeno se non si ha un editor che evidenzia la sintassi con i colori. Come non è facile intuire cosa faccia se non se ne ha un’idea precedente. Ancora più difficile è fare ipotesi di interpretazione del simbolo :: o della sequenza _::
E poi una stranezza: all’interno del corpo della funzione è riportato il nome della funzione stessa (trovaNanoR), il che sembra un errore o almeno un paradosso. Come fa una funzione ad essere definita sulla base di se stessa?
E dove è la parte che dice che la funzione restituisce qualcosa?

Insomma senza una conoscenza specifica di questo linguaggio (che, per soddisfare la vostra legittima curiosità, è Scala), o almeno di altri linguaggi funzionali, e della ricorsività, il lettore non sarà in grado di seguire il discorso, non sarà in grado di verificare se la funzione contiene errori prima di eseguirla. Anche se ha capito come si usa la funzione e che risultato produce. Insomma ha una comprensione solo parziale, che gli permetterà di usare la funzione ma senza averla capita e senza poterla modificare e adattare a contesti diversi.

Cosa se ne conclude?
Che parlare di conoscenze e competenze nella lettura è una cosa complessa e che non si risolve in quattro righe su un giornale.

La quantità di discorsi sulla tecnologia (digitale e non) è talmente elevata che non ce ne accorgiamo nemmeno più. Qualsiasi testata giornalistica ha una sezione dedicata all’high-tech, la tecnologia si mescola ai discorsi su educazione, didattica, politica, ambiente. Come se davvero sapessimo di cosa si tratta. Invece provate a darne una definizione. Allora? Avete pensato a “strumento, artefatto, meccanismo”? Seriamente vi pare che Internet possa rientrare in questi concetti? Allora proviamo con le negazioni: non organico? Non intelligente? Non biologico? Basta poco per trovare un controesempio, magari in un romanzo di fantascienza o nei laboratori di Mountain View. Il punto di partenza (errato) è l’idea che gli umani usano la tecnologia, mentre mi pare chiaro che non è più così: abitiamo nella tecnologia, come abitiamo la cultura o la lingua; ma la pensiamo ancora nei termini di qualche secolo fa: come nostro artefatto, o al massimo come estensione utilitaristica dei nervi e dei muscoli.

L’aspetto che mi solletica da un po’ di tempo è quello dell’emotività. Tecnologia fa rima con neutra efficienza, no? Eppure basta guardarsi agire per qualche minuto per vedere che la tecnologia entra nella sfera emotiva in maniera potente. Trattiamo – non da oggi, ma oggi in una maniera pervasiva – gli oggetti tecnologici con affetto o rabbia, ci innamoriamo e ci sentiamo traditi; insomma tutto lo spettro, meno che l’indifferenza con cui si prende in mano un compasso. Abbiamo fatto entrare la tecnologia nella sfera degli affetti, oppure siamo entrati nella sfera della tecnologia con tutta la nostra affettività. Ecco i robot carini, i telefoni sexy, i siti web irritanti.

Contemporaneamente, neghiamo questo affidamento e vorremmo continuare a pensare la tecnologia come uno strumento esterno che se ne sta lì, tranquillo. E così siamo condannati a non capirla.

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.

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.