steve's

Ma perché non sono nato là?

Ott
09

La citazione (che dovrebbe essere chiara per chi ha almeno cinquant’anni) è da Claudio Baglioni, ebbene si, “Viva l’Inghilterra”, anno 1973.

Si riferisce al fatto che mi danno (voce del verbo dannare) almeno dal 1999 intorno alla necessità di un’analisi (socio)linguistica del codice sorgente e non trovo un cane disposto ad ascoltarmi. O quasi, come si vede da http://steve.lynxlab.com/?p=73

Invece in USA e in Canada ci lavorano sul serio, dentro l’università, mettendo insieme ricercatori di linguistica e di informatica. E quest’articolo, pubblicato  nei Proceedings di una conferenza annuale del Psychology of Programming Interest Group che si tiene nel’UK, è finalmente (finalmente?) un esempio pratico di un tentativo reale di applicazione di modelli e strumenti sociolinguistici al codice sorgente da parte di un gruppo di ricercatori dell’Università di Lethbridge. Molto minimale ed embrionale, ma insomma esiste.

Schermata da 2016-10-10 21-59-45

Il tema è quello del genere. Si può riconoscere solo leggendo il codice se l’autore è uomo o donna? Pare di si. E che ce ne importa, diranno i miei piccoli lettori. Ci importa, perché come premettono le autrici, è il primo passo per vedere se nel codice ci sono tracce anche della lingua materna, delle conoscenze pregresse di altri linguaggi, del livello sociale o della cultura generale. E allora? Allora è il primo passo per riconoscere che il codice sorgente è un testo, risultato di un’attività di scrittura, e quindi può contenere  tutte le varianti possibili che una scrittura permette: stili, personalità, mode, esperienze trascorse. Non importa che il lessico sia limitato (ma estensibile a piacere) e che la grammatica sia molto restrittiva (ma permette forme alternative). Un programma, definitely, is not just an implementation of an algorithm which solves a problem. Si scrivono programmi per scopi diversi: per gioco, per sfida, per sperimentazione, per produrre un effetto artistico, per imparare. A monte si sceglie il linguaggio in cui scriverli, il che ha un effetto sull’orientamento generale del programma, su come viene letto, come verrà modificato e come sarà punto di partenza per nuovi programmi.

Ne deriva che quando si insegna a scrivere codice, come quando si insegna a scrivere – ma a scrivere bene – non basta insegnare la grammatica e il lessico. Ci vuole molto, moto di più. Ci vogliono buoni esempi (lettura), modelli, obiettivi, strumenti di valutazione. Ne deriva, probabilmente (ma questa è solo una mia ipotesi) che chi legge e scrive molto, programma meglio; che introdurre lo studio di come si crea e sviluppa una storia permetterebbe di ottenere dei codici sorgenti migliori, che come le buone storie “si reggono”. Le buone storie si tramandano nei secoli, come le fiabe; forse è così anche per i buoni programmi.

Rice, J. E., I. Genee, and F. Naz. “Linking linguistics and programming: How to start?(work in progress).” Proc. 25th Annual Psychology of Programming Interest Group Conference-PPIG. 2014.

Creative computing from scratch

Dic
13

Scratch è ormai diventato una moda. Quando si parla di “coding”, di programmazione per bambini, si parla inevitabilmente di Scratch. Questa equazione mi infastidisce un po’, come se non si potesse giocare con la programmazione in altro modo, come se Scratch avesse una patente speciale e tutto il resto non fosse mai esistito. Questo naturalmente non è colpa di Scratch e dei suoi creatori, ma è una miopia tutta nostra. Probabilmente in Italia non è chiaro nemmeno il significato del nome: “scratch” è la linea di partenza di una corsa. Costruire qualcosa “from scratch” significa cominciare da zero.

Penso di fare un servizio utile provando a fare un po’ di chiarezza intorno al tema, all’oggetto Scratch e al suo modello didattico. Credo che chiunque voglia organizzare un pomeriggio di gioco con Scratch – ma come ho già scritto in precedenza, non basta un pomeriggio – dovrebbe almeno riflettere un po’ su questi argomenti.

 

Perché Scratch? Cosa ha di particolare? Almeno due aspetti mi sembrano alla base della sua fortuna. Ed entrambi meritano analisi e discussione.

  1. Il fatto che intorno a Scratch ci sia una comunità internazionale. Scratch è una “online community where children program and share interactive stories, games, and animations”. Bisogna quindi essere necessariamente connessi per programmare? In realtà esiste un editor offline, basato su Adobe Air. E’ una scelta strana per il MIT; né Adobe Air né l’editor offline sono OpenSource (a differenza di quasi tutti gli altri ambienti dello stesso genere). Non ho idea di quanti usino la versione offline, talmente è più facile utilizzare la versione online. In ogni caso c’erano, e ci sono ancora, anche altre comunità dello stesso genere. Quasi ognuno degli ambienti di programmazione per bambini ha un team di sviluppo che mantiene un sito con esempi, suggerimenti, guide. La comunità intorno a Scratch è la più recente, probabilmente la più attiva, non necessariamente la più interessante. Potrebbe valere la pena andare a curiosare anche nelle altre.
  2. Il fatto che non sia necessario scrivere codice sorgente (il che è piuttosto curioso, visto l’uso continuo del termine “coding”). La questione è rilevante. Uno dei passaggi chiave nella storia degli ambienti di programmazione per bambini è proprio il passaggio dalla scrittura di codice alla programmazione visuale. Significa che invece di scrivere “if questo then quest’altro” il programmatore deve trascinare oggetti grafici, disporli in un certo ordine, e scrivere solo dati all’interno di buchi (le variabili). La sintassi è affidata alla posizione degli oggetti, la semantica alla scrittura. Ci sono enormi vantaggi: il rischio di commettere errori di sintassi è annullato, la struttura del codice è rappresentata in forma visuale ed è più comprensibile con uno sguardo d’insieme. Si introduce però uno iato forte tra l’attività presente (visuale) e quella futura (scrittura). Infatti gli ambienti di programmazione visuale per adulti professionisti sono piuttosto pochi, dedicati di solito a domini specifici come il multimedia e, nel 99% dei casi, un programmatore scrive o modifica codice scritto. Ci sono degli evidenti vantaggi anche nell’uso della scrittura: un codice scritto in qualsiasi epoca e in qualsiasi linguaggio può essere modificato con un editor di testo (se la licenza lo permette). E abituarsi a leggere e rileggere, vale per un testo scritto in una lingua naturale come per un codice sorgente, non è un’attività poco utile nella vita.

Scratch nasce al MIT nel 2003 con un grant della NSF, in collaborazione con diverse altre università statunitensi (Pennsylvania, Harvard, Washington e altre). Tra i ringraziamenti, vengono citati Seymour Papert e Alan Kay, ovvero l’autore del LOGO e uno degli inventori della programmazione orientata agli oggetti e delle finestre, nonché di Squeak, Etoys e Tweak.

La storia degli ambienti di programmazione per bambini – in cui Scratch affonda le radici – è infatti molto lunga. A partire dal LOGO (1967 !) e i suoi derivati (StarLogo/NetLogo, 1999) passando per ToonTalk (1992), Stagecast Creator  (1996),  SmallTalk/Squeak/ (1996), Etoys (1997), Alice (1999),  fino al recente AppInventor per Android (2010). Una lista completa la trovate qui: http://en.wikipedia.org/wiki/Visual_programming_language.

Ognuno ha delle particolarità interessanti. Ad esempio Alice era basata sul modello della programmazione orientata agli oggetti, NetLogo sugli agenti concorrenti, Stagecast Creator sulle programmazione per regole. Sono tutti modelli alternativi alla programmazione “imperativa” (che è la più vecchia, quella in cui si comanda il computer con istruzioni e test, IF_THEN_ELSE), modelli che oggi sono studiati ed adottati su larga scala.

L’autorità principale dietro Scratch, Mitch Resnik (LEGO professor al MIT Media Lab), parla degli obiettivi del progetto in questi termini: “Quando qualcuno impara a programmare con Scratch impara allo stesso tempo importanti strategie per risolvere problemi, creare progetti e comunicare le proprie idee.” Le stesse idee sono espresse nella guida del 2011 pubblicata dall’Università di Harvard (http://scratched.gse.harvard.edu/sites/default/files/CurriculumGuide-v20110923.pdf). La guida è una miniera di idee e contenuti, declinati in 20 sessioni didattiche. Nell’introduzione si dice fra l’altro:

“Engaging in the creation of computational artifacts prepares young people for more than careers as computer scientists or as programmers. It supports young people’s development as computational thinkers – individuals who can draw on computational concepts, practices, and perspectives in all aspects of their lives, across disciplines and contexts.”

Il pensiero computazionale (traduzione dubbia; ma in questi casi è difficile resistere al calco) è quindi visto come una maniera di affrontare i problemi della vita, attraverso concetti come sequenze, cicli, parallelismo, eventi, condizioni, operatori e dati. Le pratiche che vengono incoraggiate come più adatte sono “essere iterativi e incrementali, verificare e correggere, riusare e mescolare, astrarre e modulare”.

Da un lato questa visione mi attrae, dall’altra devo confessare un po’ di spavento. Davvero i problemi reali vanno affrontati in termini di algoritmi formalizzabili? Davvero le azioni nei complessi contesti quotidiani vanno regolate in funzione di condizioni, operatori e dati? I bambini devono giocosamente imparare a comportarsi nella vita come automi perfettamente informati?

Persino l’idea dell’introduzione giocosa alla programmazione, per preparare i futuri sviluppatori di cui avremo bisogno nei prossimi dieci anni, andrebbe esaminata un po’ di più prima di essere accettata come una verità incontestabile. Non solo perché nel comparto informatico ci serviranno molte figure professionali diverse dagli sviluppatori; e non solo perché la programmazione richiede tanta creatività nell’inventare quanta abilità nel portare a termine l’idea.

Il punto centrale, il fulcro, è la strategia didattica.

Che “chi impara prima, impara meglio”, sembra essere un proverbio uscito dalla saggezza popolare, e quindi poco discutibile. Per diventare un musicista, un ballerino, un calciatore, un cantante, bisogna cominciare da bambini. Vale anche per le lingue straniere, vale anche per la matematica. Lo sappiamo per esperienza. Vale anche per la programmazione dei computer? Beh, qui troppi dati statistici non ci sono, dobbiamo procedere per analogia; e le analogie vanno tenute sotto controllo perché tendono a sfuggire.

Come si insegna ad un bambino una materia complessa, composta di tecnica e conoscenze, senza che le difficoltà impediscano i progressi?

Tradizionalmente, abbassando il livello della qualità richiesta, semplificando gli obiettivi, ma lasciando intatti gli elementi e le regole. Non si insegna ad una bambina di sei anni a suonare il violino con uno strumento con due sole corde, ma con un violino ¾, che ha la stessa complessità di uno 4/4 . Ma c’è una sterminata letteratura didattica composta per guidare lo studente dal facile al difficile. Non si semplifica il contesto, si modulano le richieste. La strategia didattica è lineare: c’è una gradazione infinita di modi di far vibrare una corda, e chi apprende procede lungo questo sentiero infinito. Limiti: la bambina si annoia, soprattutto se non capisce dove la porterà questa lunga strada, perché i risultati iniziali non sono troppo incoraggianti. Finirà probabilmente per abbandonare.

C’è un altro modo, più moderno: si crea un ambiente “didattico”, semplificato, in cui elementi e regole sono ridotti rispetto all’originale. Un flauto con i tasti invece dei fori; un toy piano diatonico. Qui i risultati gradevoli si raggiungono presto, la motivazione è rafforzata.

Questi giocattoli educativi non sono in continuità con il mondo reale. C’è una cesura netta: da un lato il giocattolo, dall’altro lo strumento vero, da un lato gli spartiti colorati, dall’altro i pentagrammi.

Questa strategia è senz’altro più efficace per iniziare, è più “democratica”, ha successo nella quasi totalità dei casi. Non serve a preparare musicisti professionisti, ma a comunicare l’amore per la musica (per esempio, io ho cominciato a suonare su un pianoforte giocattolo, e da allora amo disturbare il vicinato con ogni tipo di strumento – per questo vivo in campagna). E’ molto chiaro che non c’è un passaggio graduale dal modo “semplificato” a quello “avanzato”. Sono due mondi diversi, che si assomigliano in alcune parti, ma che non sono in connessione diretta. Alcuni degli studenti arrivati ai confini di uno si affacceranno sull’altro, si accorgeranno che la complessità è enormemente più elevata, ma decideranno di entrare lo stesso; altri si fermeranno nel primo mondo, come ho fatto io.

Tra gli ambienti di programmazione per bambini, però, alcuni sono stati pensati proprio come un raccordo, una via di mezzo tra i giocattoli e le cose serie. Sono ambienti dinamici, modificabili, evolutivi, in cui il bambino può iniziare in un contesto semplice e poi aggiungere complessità fino ad arrivare all’editor testuale di codice sorgente che è identico a quello del programmatore professionista. Questo è uno dei motivi per cui gli oggetti digitali sono più potenti di quelli fisici.

Ora, quali sono gli obiettivi di Scratch? Apparentemente, due: preparare futuri programmatori e iniziare i bambini all’amore per il computational thinking.

E la strategia didattica dietro Scratch, di quale delle due categorie delineate sopra fa parte? Direi della seconda, visto che l’ambiente che si propone è giocoso, facile, divertente, ma non ha le stesse regole del “mondo adulto” della programmazione. Non si scrive e legge codice. Non ci si preoccupa della correttezza sintattica. Non ci si preoccupa dell’efficienza, della velocità, della comprensibilità, della standardizzazione, dello stile, etc etc. Non c’è niente di male, come non c’è niente di male in un toy piano. Ma solo nei fumetti Schroeder suona Beethoven con quello.

Il problema nasce proprio quando si immagina che entrambi gli obiettivi possano essere raggiunti con una sola strategia, ovvero quando questa differenza di approcci strategici non viene proprio percepita,  cioè quando si pensa che iniziare a programmare con Scratch sia solo il gradino più basso di una scala che porta, gradualmente, alla produzione dei software che usiamo ogni minuto. E questo è tipicamente un errore di chi non ha una grande esperienza della programmazione.

Programmare non è solo un po’ più difficile di creare un gioco con Scratch, è enormemente più complesso; come realizzare un film o registrare un concerto non è solo un po’ più difficile di girare un video con uno smartphone.

Personalmente ho visto tanti bambini (studenti, figli, figli di amici) giocare con ambienti di programmazione fatti apposta per costruire giochi. Di tutti questi, solo uno, che io sappia, ha avuto la voglia e la costanza di continuare. Gli altri, quando hanno capito che programmare è difficile, si sono arresi e sono tornati a giocare.

____

Ci sono infine alcune domande che credo sia importante porsi quando si inizia un progetto didattico con Scratch.

1. Possono condurre un curriculum (nel senso di un progetto didattico) basato su Scratch anche docenti che non sono informatici di estrazione? Non è ovvia la risposta. Nel senso che le competenze tecniche per usare e far usare Scratch sono ovviamente molto basse. Ma non avere il background necessario potrebbe essere un limite grosso quando si cerca di espandere le idee e i concetti di Scratch e applicarle al mondo quotidiano (gli smartphone, il web, i programmi per PC). Non significa che solo i laureati in informatica possono condurre un laboratorio Scratch. Servono competenze pedagogiche, capacità di giocare insieme ai bambini e competenze informatiche.

2. Le idee dietro Scratch hanno una lunga storia, quasi tutta scritta negli Stati Uniti, quindi legata a quel modello educativo e sociale. Possiamo prenderle in prestito così come sono o possiamo/dobbiamo pensare ad un adattamento europeo e italiano? Ad esempio, se il peso delle attività di scrittura/lettura è diverso nei curricula statunitensi e italiani dei primi anni scolastici, non dobbiamo tenerne conto?

3. Perché dobbiamo sempre ricominciare “from scratch”? Ci sono, in tutto il mondo, migliaia di esperienze di introduzione alla programmazione con altri linguaggi e ambienti, in Italia almeno a partire dagli anni ’80. Possiamo ritrovarli, studiarli, verificarne i risultati? Potremmo, ad esempio, andare a vedere quali effetti hanno avuto nel tempo sui bambini coinvolti (quanti hanno scelto l’informatica come professione, quanti riconoscono un valore a quelle esperienze)?

Insomma, mi sembra che ci sia ancora tanto da fare e tanto su cui riflettere.

Che significa Code Week? (in difesa della conoscenza della lingua del digitale)

Ott
18

C’è una certo fastidio diffuso, per lo meno tra i miei amici e conoscenti, per l’esterofilia linguistica e gli stranierismi (leggi anglicismi, leggi meglio americanismi) usati nell’universo educativo.

Ci sono due aree linguistiche fondamentali che sono responsabili di questo male endemico: il business (americanismo) e l’informatica (“computer science” da noi non ha attecchito). In entrambi i casi si tratta di parole che viaggiano insieme ai discorsi, ed entrambi questi discorsi sono nati e si sono sviluppati da sempre in ambiente angloamericano.

Che questi due discorsi, insieme alle loro parole-vessillo, si impongano anche in un ambito diverso, quello educativo, è in effetti un problema grave. Pensare l’educazione in termini di competitività, di target, di budget, è indice di un più generale assetto di valori che si può criticare. Usare le parole dell’informatica in lingua originale anche dentro la scuola forse è meno grave perché finora non si è assistito ad un ripensamento dell’educazione in termini algoritmi, programmi e architetture di rete. Tuttavia anche qui c’è chi si domanda perché usare email invece di posta elettronica, streaming invece di diretta, BYOL invece di PITC (Porta Il Tuo Computer), etc… Chi usa il termine originale vuole mostrare di essere aggiornato, e vuole concedere all’ascoltatore la stessa patente (“qui siamo tra esperti, sappiamo tutti cos’è il digital divide”). E a volte invece l’uso di queste espressioni è proprio causa di divisione e genera incomprensioni; ma nessuno ammetterebbe di non sapere esattamente cosa significa HTTP, parola che digita tutti i giorni.

Ora però – anche alla luce delle riflessioni che facevo qualche giorno fa sullo stesso tema, anche se forse non era troppo evidente – vorrei provare ad approfondire un po’ il discorso.

Alcune delle parole sotto accusa sono difficili da tradurre in maniera sintetica (provate con “debriefing”), ma d’altra parte non sempre essere sintetici è un valore. Altre sembrano proprio un esercizio gratuito di pigrizia (“screensaver” non è un termine tecnico). In altri casi la traduzione italiana esiste, ma non è detto che abbia proprio lo stesso valore.

Per esempio confrontiamo i vocaboli “calcolatore” e “computer”. Hanno esattamente lo stesso significato, nel senso che dovunque si usa il primo si potrebbe usare il secondo. Non indicano due oggetti diversi.

Ma se vi rotolate nelle bocca queste parole sentite cose diverse. Uno sa di università, di laboratorio, l’altro di Euronics.

La diffusione lessicale è ovviamente molto diversa: calcolatore viene usato solo dai pochi che hanno appreso l’informatica almeno trent’anni fa, computer da tutti gli altri. L’etimologia è poi interessante: “calcolatore” viene, dopo vari passaggi, da calculus, il sassolino che si usava per contare, magari disposto in scanalature di una tavoletta o su fili diversi come nel pallottoliere; “computer” da com-puto, il verbo delle operazioni aritmetiche (la somma, in particolare). Uno punta sul supporto materiale, sull’ausilio tecnologico, l’altro sull’operazione mentale di trarre una conclusione da una situazione complessa.

Naturalmente l’etimologia non partecipa alla determinazione dell’uso di un termine, almeno quando è ignota. Ma saperne di più aiuta a modulare l’uso dei termini, a scegliere. C’è chi non capisce il successo del nome (prima dell’oggetto) Whatsapp, principalmente perché non coglie il nesso con “what’s up?”, che succede? O chi non sa che “tube” significa “televisione” (dal tubo catodico), e quindi non collega Youtube con “fai la tua televisione”.

Un altro esempio che è sotto i riflettori in questi giorni (Code Week): “coding” potrebbe essere tradotto con “programmare, programmazione”. Ma esiste “programming”, che equivale a “programmare”. Nel quadrilatero che possiamo immaginare, uno dei vertici è vuoto. I due termini inglesi hanno – nella mia mente, sulla base delle mie esperienze –  due sfumature diverse: coding è “codificare”, cioè trasporre uno schema operativo in un certo codice linguistico, partendo da una versione astratta o da un altro codice. Programmare è “costruire un programma”, un artefatto digitale che viene eseguito da un calcolatore. Il primo termine sottolinea il processo, l’attività linguistica; l’altro il fine e l’utilizzo del prodotto finale. Uno si presta bene a sviluppare gli aspetti narrativi, l’altro quelli ingegneristici. Quando dico “un programma è la materializzazione in un linguaggio specifico di un algoritmo che risolve un problema”, ho in mente il risultato, non il processo di scrittura. Quando dico “coding is fun”  ho in mente l’avventura di trovare dentro di me le parole giuste per dirlo.

“That is why I enjoy computer programming more than anything I have encountered in this life. Not because of the boring “move, modify, store, repeat” routine of the daily work, but in studying how I write code and from the knowledge and insight I get into the code, I also get into myself.” Mark Janssen qui parla evidentemente di coding, non di programming.

Ora non giurerei che chi parla oggi di “Code Week” intenda una cosa diversa da “Settimana della Programmazione”; però sarebbe bello se i corsi di “coding” e quelli di “programmazione” fossero riconosciuti come cose diverse e un potesse iscriversi all’uno o all’altro con cognizione di causa. Sarebbe bello se chi parla di certi argomenti avesse una conoscenza meno superficiale; conoscenza (non solo competenza) che non deriva solo dalla pratica di una disciplina, ma anche dalla riflessione sulle proprie esperienze e dallo studio delle parole di quella disciplina, del loro uso non solo qui ed ora. Mi rendo conto che  è una posizione che può apparire retrograda. D’altra parte, penso ancora che ci siano più parole che cose, e che rinunciare alla parole in favore delle cose sia almeno altrettanto rischioso dell’inverso.

 

Il problema, secondo il mio modesto parere (IMHO), è quindi non tanto nell’usare un termine straniero per ossequio ad una potenza nemica, ma usarlo inconsapevolmente senza cercare di coglierne tutti i significati e i sapori. Come per la zappa.

Anche in questo caso, un’educazione all’uso delle parole, trasversale a tutte le discipline, sarebbe benvenuta.