steve's

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

 

Costruire teorie sperimentali con il Coding

Nov
07

Tra le tante ragioni usate per giustificare la pratica (anticipata) del Coding, quella che mi pare più sensata per la scuola è la possibilità che viene data agli studenti di costruire in maniera sperimentale una teoria di un dominio. Per esempio: come funziona il ciclo dell’acqua? Perché a volte i semi germogliano ma poi si seccano? Quando va usato il congiuntivo?

Costruire una teoria significa capire, ma capire ad un livello diverso da “apprendere una regola o una formula”. Costruire in maniera sperimentale significa arrivare un po’ alla volta alla teoria giusta, provando modi diversi di mettere in relazione parametri e vedendo immediatamente, sensibilmente, il risultato.

Questo modo di apprendere è reso possibile dall’esistenza dei computer, nella loro essenza di artefatti digitali programmabili, e dalla loro accessibilità per gli studenti. Esistono esempi meravigliosi di simulazioni digitali  in campi diversi, ma che di solito hanno il difetto di essere chiuse, cioè non programmabili. Si riesce a intuire quali sono le regole in gioco, a verificarne le relazioni, ma non a formalizzarle.

Il coding ha senso in questo contesto a patto di avere presente dove si va a parare fin dall’inizio, e a patto di non fermarsi ai primi passi. E’ praticabile in tempi ragionevoli se si hanno a disposizione degli ambienti programmabili non vuoti, cioè in cui le regole del dominio sono già cablate. E’ utile se dopo la fase di scoperta e costruzione della teoria in un ambito limitato si passa alla sua estensione e riapplicazione in altri domini.

Passo 1. Se creo una storia animata usando un programma di disegno, che permette di aggiungere suoni e musiche e di muovere sprites sullo schermo, sto facendo quello che potrei fare a mano, con infinita fatica e molti più errori, disegnando su una pellicola. Quella storia avrà sempre lo stesso svolgimento non importa quante volte la esegua. Per creare la storia devo aver già chiare le regole dell’ambiente.
Cosa sto imparando? Ad usare certi strumenti, punto. Se programmo questa storia, sto imparando ad usare altri strumenti e concetti (ripetizione, spostamento) ma niente di più.

Passo 2. Se invece ho un ambiente dinamico, in cui succedono delle cose (immaginiamo un gioco: arrivano mostri, si presentano nuovi ostacoli etc) e devo muovere manualmente un personaggio, quello che succede dipende dalle mie azioni e ogni volta è diverso. Se il mostro si avvicina troppo, mi mangia. Ma se sta esattamente sopra di me, in verticale, gli posso sparare. Che invece di spostare il personaggio manualmente utilizzando un joystick, un mouse o un touchscreen io possa scrivere un comando per spostarlo non cambia molto le cose, ma è un primo passo.
Cosa sto imparando qui? A individuare i parametri e a stimare intuitivamente i valori di soglia di questi parametri cui devo reagire. Bene, ma ancora non basta.

Passo 3. Il tutto diventa interessante solo quando riesco a programmare il personaggio non in modo che esegua sempre lo stesso movimento, ma in modo che esegua un movimento diverso in funzione della situazione.

Senza scomodare l’intelligenza artificiale, posso definire delle semplici regole:

  1. se c’è un mostro nella linea di tiro, spara
  2. se il mostro si avvicina troppo, spostati verso l’area dove ci sono meno mostri

Bisogna definire cos’è la linea di tiro, quanto è grande e come si verifica la sicurezza di un’area, eccetera. Cosa si sta imparando qui? A costruire una strategia che sia buona in qualsiasi situazione. Per costruire la strategia bisogna non solo individuare i parametri dell’ambiente più significativi ma anche definire in maniera precisa i valori di soglia, e poi stabilire le azioni migliori per far fronte alla situazione definita dal superamento di quei valori, cioè bisogna costruire una teoria. Il fatto che io debba programmare questa strategia mi obbliga a formalizzarla e a verificarla. La possibilità di rappresentarla in un codice sorgente mi permette di discuterla con gli altri, di rivederla in un momento successivo, di correggerla, di generalizzarla.

Non è tanto importante l’apprendimento delle tecniche di programmazione – che però sono funzionali alla costruzione della teoria e alla sua verifica immediata – , quanto il fatto che questo approccio permette di affrontare domini (che tradizionalmente mi chiederebbero di imparare in maniera fideistica certe nozioni, per esempio che l’accelerazione di gravità sulla Terra è 9,8 m/s) in una maniera costruttiva, esperienziale e collaborativa. Posso sperimentare direttamente la relazione tra certe cause e certi effetti, come potrei fare anche nel mondo reale se avessi risorse a sufficienza o se potessi accelerare o rallentare il tempo (come faceva Galilei). Il fatto che la mia teoria sia scritta in una forma eseguibile facilità sia la verifica immediata, sia il confronto con gli altri.

Per esempio, ho un seme. Se c’è sole e acqua, il seme germoglia e nasce un fiore. Se c’è acqua, ma non sole, il seme germoglia ma non nasce il fiore. Se c’è sole, ma non acqua, il fiore crepa. I parametri qui sono luce e umidità; i valori soglia li devo scoprire. E poi devo trovare le azioni che permettono al mio seme di fornire la performance migliore (innaffiare, drenare, coprire, illuminare). Se riesco a programmare queste azioni significa che ho costruito una teoria dell’ambiente. Non: ho costruito una teoria perché avevo imparato le regole, ma: costruendo una teoria ho capito le regole.

Ci sono infinite applicazioni possibili. Papert ha pensato alla geometria piana, ma si può spaziare dalla fisica alla biologia, dalla storia alla grammatica, dalla musica alla lingua due. Forse all’inizio potrà sembrare bizzarro concepire lo studio della lingua in maniera sperimentale, ma niente lo vieta. L’importante è che ci siano delle regole che producono effetti (diacronici o sincronici) e che queste regole si possano inserire in un ambiente che ne mostra gli effetti. E’ vero che le “regole” in ambito linguistico hanno tantissime eccezioni, mentre la fisica ci ha abituato a situazioni più lineari; ma si può immaginare una lingua artificiale senza eccezioni dove si possa sperimentare in assenza di attrito, o un universo fantastico dove le carestie portino inevitabilmente alle guerre. In fondo, la geometria euclidea o la logica aristotelica sono nate con la stessa idea di fare astrazione dai dettagli reali per arrivare più facilmente ai concetti e alle regole chiave.

Far costruire agli studenti un ambiente del genere partendo da zero è troppo complesso. Per farlo bisognerebbe sapere in anticipo quali sono i parametri fondamentali e la loro relazione, che invece dovrebbe essere l’obiettivo dell’attività. Sarebbe molto meglio avere a disposizione un ambiente con le sue regole già cablate (ma ispezionabili, o addirittura modificabili), che però mi permettesse di programmare le azioni con cui interagisco con l’ambiente. Che so: un ambiente in cui la relazione tra massa e peso è definita, in cui però il tempo si possa rallentare a piacere o la resistenza dell’aria azzerare.

Passo 4. Non si tratta di ricostruire tutto il sapere a forza di esperimenti. Una volta capito il meccanismo dell’elaborazione di teorie, si può cercare di capire se esistono delle invarianti che mi permettono di applicare uno schema che ha funzionato una volta anche in situazioni diverse. Per far questo, devo catalogare i miei schemi in funzioni delle caratteristiche delle situazioni che ne suggeriscono l’applicazione. Naturalmente questa è la parte più difficile. Ma la fase metacognitiva (cosa abbiamo scoperto? come potremmo riusarlo) è altrettanto importante di quelle precedenti e la competenza nell’applicazione di schemi a situazioni nuove è in fondo l’obiettivo che giustifica tutta l’educazione.

Passo 5. Inoltre gli schemi si possono rendere più potenti, grazie ad elaborazioni formali (generalizzazioni, trasformazioni). Qui forse vale la pena non provare a inventare tutto, ma sfruttare le esperienze di quelli che hanno già studiato e sperimentato prima di noi. Ma si inverte l’ordine tradizionale: prima si capisce, sperimentando in un ambiente semplificato e controllato,  quali sono le regole di fondo, e solo dopo si imparano i trucchi che permettono di riapplicarle in maniera estesa e rapida. Non mi si chiede di imparare prima i prodotti notevoli e poi, forse, capire a cosa mai possono servire, ma il contrario.

Serve necessariamente un computer e un ambiente di programmazione semplificato per praticare questo tipo di didattica? No, certo. Ma senza un ambiente digitale programmabile questo approccio sarebbe talmente difficile e lungo che in pratica si finisce per non applicarlo quasi mai.