steve's

Capire un testo: e che ce vo’?

Apr
20

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.

Mezzi e fini

Apr
15

Come sempre in cerca della terza via.

Ho visto spesso progetti iniziare senza nessuna idea dei mezzi disponibili.
“Questi sono gli obiettivi, qual è la tecnologia che si accompagna meglio?” Un po’ come il vino sulla portata principale.

Ne ho visti altri partire dai mezzi e poi andare in cerca dei fini compatibili.
“Questa è la tecnologia disponibile, che obiettivi possiamo raggiungere?” Un po’ come il cuoco alle prese con il frigo semivuoto.

Raramente questi progetti hanno funzionato, e a posteriori ci si è domandati perché. Dentro di me, mi dicevo che avrebbe dovuto essere chiaro il perché fin dall’inizio.
Nel primo caso, si finisce per sottosfruttare le potenzialità della tecnologia, nel secondo per lasciarsi guidare solo dalle finalità standard, già note e più o meno cablate nelle tecnologie conosciute.

A me pare – senza ricerche neuroscientifiche a supporto – che la mente non funzioni necessariamente così (da A a B, oppure da B ad A).
Questi modi sequenziali sono utili, ma sulla base della mia introspezione direi che ne esiste almeno un altro: quello parallelo.
La storia che ci raccontiamo è questa: voglio andare al mare, quindi cerco il mezzo di trasporto adatto.
Ma quando decido per il mare (in alternativa a Marte, al Polo Nord e all’altro lato della strada) so già quali sono i mezzi di trasporto disponibili, il loro costo, la complessità. Non scelgo prima la destinazione e poi mi accorgo che ahimé non posseggo un razzo nel garage.
Né faccio un censimento dei mezzi (macchine, moto, biciclette, skate, scarpe) per poi scegliere una destinazione raggiungibile con uno di quelli.
E’ la forma narrativa che, a posteriori, ci racconta la storia dei fini e dei mezzi. Non è colpa della narrazione né del linguaggio, è la nostra abitudine ad applicarli sempre e comunque. Il linguaggio e gli schemi narrativi forniscono alternative a “poiché…quindi”: per esempio “mentre”, “nel frattempo”, “contemporaneamente”. Ma sono più complicati da gestire e in ogni caso vanno sequenzializzati nel racconto.
Quello che succede nella mia mente (almeno credo) è più o meno questo: mentre guardo la moto in garage e penso a dove potrei arrivarci (“con un pieno, posso fare 400 km, ma poi mi fa male la schiena, quindi meno”)  intanto mi vengono in mente destinazioni piacevoli, sconosciute, adatte alla stagione. Alcune sono talmente attraenti che sposto lo sguardo dalla moto alla bicicletta. O viceversa, mentre guardo sulla cartina e calcolo i kilometri, in un processo mentale parallelo seleziono automaticamente la bicicletta o il treno. Non sono due processi uno dopo l’altro, avvengono insieme con delle continue retroazioni, correzioni, aggiustamenti. Certo perché accada bisogna avere una conoscenza abbastanza approfondita dei mezzi, e avere una certa gerarchia dei fini (ottimale, preferibile, sufficiente) intrecciata con quella dei costi.

E dunque: obiettivi e tecnologie vanno scelti insieme.

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.

Emotechnology

Feb
04


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.

 

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