steve's

apprendimento digitale e dintorni

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.

Monitoraggio, brutta parola

Ott
09
Sul sito Programma il Futuro sono scaricabili dei report sui dati sulle attività svolte nel primo (http://programmailfuturo.it/media/docs/Rapporto-monitoraggio-settembre-2014-gennaio-2015.pdf) e nel secondo anno di progetto (http://programmailfuturo.it/media/docs/evento-celebrativo/programma_futuro-MIUR-26mag2015.pdf). Numero di ore, numero di insegnanti per regione e per disciplina, numero di classi e studenti coinvolti, e poi gradimento, valutazioni, osservazioni, tutti corredati di grafici. Dati raccolti in parte grazie a Google Analytics (altrimenti perché si attiva ogni volta che apro una pagina in Code.org?) e in parte grazie a questionari.
Questa cosa mi solletica.
Dieci anni fa, quando lavoravo a Scienze della Comunicazione, ho fatto una ricerca sui forum del corso concorso per dirigenti scolastici di INDIRE (2006). Siccome la piattaforma usata non prevedeva nessun tipo di monitoraggio fine (e peraltro non esisteva più…), siamo partiti da una copia del DB Oracle e siamo riusciti a ricostruire i profili, le conversazioni, i temi, le modalità comunicative. Il risultato principale è stato forse però l’insieme di query SQL che avrebbero permesso di analizzare allo stesso modo i dati di altri forum che usavano la stessa struttura dati, ad esempio per vedere se c’erano invarianti legate alla dimensione geografica, all’età, alle esperienze pregresse. Non mi risulta che siano stati mai usati, ma pazienza.
Cinque anni dopo, il MIUR ci affidò una ricerca per valutare il risultato di tre piani di formazione nazionali. La cosa anche qui fu piuttosto difficile, perché non c’erano dati originali, ovvero il progetto delle attività non contemplava la raccolta di dati prima, durante e dopo. Sono stati analizzati fondamentalmente i risultati di questionari somministrati ai docenti. Il che come si può immaginare non è la stessa cosa di avere accesso alle informazioni primarie.
Nella recente formazione per gli Animatori Digitali del Lazio, che mi ha coinvolto solo come tecnico fornitore di piattaforme, ho proposto di impostare un piano di monitoraggio all’inizio delle attività. Non per valutare nessuno, ma perché quando domani qualcuno arriverà a chiedersi se e come ha funzionato avrà bisogno di qualche informazione in più rispetto ad un sondaggio finale.
 
Insomma la fatica per ottenere dei risultati di qualche qualità mi pare inversamente proporzionale alla lungimiranza di chi gestisce un progetto. Se poi i dati raccolti (naturalmente anonimizzati) venissero resi disponibili come opendata (oltre alle elaborazioni in PDF), si potrebbe lasciare a chi ne ha voglia e competenze il compito di far emergere qualche idea buona (qui ho esagerato, vabbè).
 
Se ogni attività di coding fosse preceduta da una raccolta di informazioni (chi è il docente, che competenze ha, che lavori sono stati fatti con quella classe in precedenza) e magari da un test di ingresso, se durante le ore di coding si potesse registrare lo scambio tra gli studenti e con il docente o il processo di acquisizione di nuove forme sintattiche, se le attività fossero seguite da un test finale, se se se… ci sarebbero alla fine dati su cui riflettere. Anche senza avere per forza la pretesa di dimostrare che il coding serve (o non serve) ad un obiettivo specifico.
Magari verrebbero fuori delle connessioni a cui non si era pensato. Per esempio, l’influenza della famiglia o dell”ambiente sociale, o della lingua materna; il peso delle competenze informatiche del docente (o delle dimensioni dello schermo, o del tempo atmosferico, o del segno zodiacale del docente, o che so io). O magari non viene fuori niente. Ma senza quei dati non si saprà mai. Non mi sto inventando i Learning Analytics: se ne occupa tanta gente, la Microsoft nell’accordo con il Ministero dell’Educazione Nazionale Francese ha specificato che il suo intervento sul coding prevede anche questo tipo di attività di monitoraggio e analisi dei dati (http://cache.media.education.gouv.fr/file/Partenaires/17/7/convention_signee_506177.pdf, pag 4). Se lo fa Microsoft, a qualcosa servirà, no?
 
Quello che voglio dire non è tanto che ci deve essere un quiz alla fine che ci permetterà di dire se Mario ha imparato il pensiero computazionale (o uno strumento di analisi degli elaborati come DrScratch, http://drscratch.org/, – grazie Massimo per la segnalazione – che pure potrebbe essere utile); ma che una Piano Nazionale dovrebbe dotarsi dall’inizio di un protocollo e di strumenti per valutare la qualità di quello che fa, e non solo la quantità e le opinioni. Se Google ha costruito la sua fortuna sull’analisi dei testi e dei comportamenti della popolazione mondiale, ci sarà pure una ragione. Che, nel nostro caso, non è poter vendere pubblicità e servizi mirati, ma valutare globalmente un piano nazionale (non il coding), e per una volta non a posteriori.
E’ un suggerimento per il terzo anno…

Dietro il coding

Set
25

copertina

In occasione dei due seminari in Piemonte (Ivrea e Torino), di cui qui trovate maggiori informazioni, ho preparato delle slide. Troppe slide. Alla fine mi hanno fatto notare che più che una presentazione stava diventando un libro.

 

 

E allora ho colto l’occasione, reimpaginato, aggiunto, corretto, e ho realizzato un piccolo ebook dal titolo “Dietro il Coding”. Non è una difesa del coding né una sua condanna. E’ semplicemente una raccolta di domande e di riflessioni che hanno lo scopo di stimolare quelle degli altri, soprattutto di quelli che intendono dedicare qualche ora al Coding con i propri ragazzi. Riflessioni che partono da lontano, da almeno venticinque anni fa, ma che ho cercato di aggiornare andando a caccia di opinioni, di proposte e di alternative. Una parte importante è dedicata al progetto “Programma il Futuro” e a Scratch, ma purtroppo solo poche righe al nuovo tema dei curricoli digitali, che andrà seguito con attenzione.

Questo è l’indice:

Come nasce questo testo
1. Che cos’è il Coding
2. Perché è così importante
3. Una valutazione storica
4. Come si parla del Coding?
Primo Intermezzo: che significa opensource?
5. A che serve il Coding?
6. Chi può insegnare il Coding?
Secondo Intermezzo: le differenze tra linguaggi
7. Che linguaggio?
8. Il modello didattico dietro Scratch
9. Come andrà praticato il Coding
10. Un po’ di storia…
11. E oggi?
12. Come potrebbe funzionare davvero
Suggerimenti di lettura

L’ebook è rilasciato con licenza CC BY/SA e lo potete scaricare da  qui.

Intelligenza artificiale: media

Mag
23

Il tema dell’IA sta facendo capolino sempre più spesso sui media digitali.
Mi hanno colpito alcuni articoli.

1. Il docente robot
I fatti: al prestigioso Georgia Institute of Technology gli studenti del MOOC su IA hanno difficoltà a trovare le pagine  con i voti o i compiti e scrivono ai tutor chiedendo lumi.
I tutor a loro volta hanno difficoltà  a rispondere a tutte le email.
C’erano varie possibilità:
– migliorare l’interfaccia del MOOC mettendo in evidenza i link a alle pagina utili
– creare delle FAQ con le domande più frequenti e le risposte sensate.

Invece i gestori del corso hanno deciso di creare un BOT, cioè un utente automatico del forum che si basava sulle parole chiave e sulla somiglianza delle domande per fornire delle risposte. Dopo qualche esitazione, il software ha cominciato a funzionare bene e gli studenti non si sono accorti della differenza. Bravi, bell’esercizio.
Il primo commento che mi viene in mente (ma penso sia ovvio per tutti): beh, quel MOOC era proprio progettato malino. Se l’interazione studenti-tutor è talmente limitata che gli studenti non trovano nessuna differenza tra le consuete risposte umane e quelle di Jill Watson (il bot), significa che il corso non è era un granché interattivo. Vuol dire che va migliorato il modello didattico del corso, no?

Il titolo dell’artico però è: “L’insegnante è un robot. Ma non se ne accorge nessuno
Sottotitolo: “Si chiama Jill Watson, e fa l’assistente in un corso di programmazione. Nessuno degli studenti, però, si è accorto che è un computer.
Nel testo: “La piaga più grande dei corsi online”, ha spiegato Goel [Ashok Goel, il docente], “è l’alto tasso di abbandono da parte degli studenti. La causa principale è che gli studenti stessi lamentano di non avere abbastanza interazioni con gli insegnanti. Abbiamo creato Jill per fornire risposte e feedback più veloci. […] ”
Commento dell’articolista: “Chi meglio di un software per insegnare a programmare algoritmi di intelligenza artificiale?” Davvero. Ma qui non c’è nessun docente software…
Battuta finale: “E nessuno degli studenti si è accorto di avere a che fare con un computer. Qualcuno ha chiesto addirittura a Jill un appuntamento dal vivo. Impossibile, peccato.”

Insomma, il MOOC non brilla per la modernità del modello didattico – e gli studenti se ne accorgono –  ma il modo per riparare è fornire risposte più veloci? Si prende un compito ripetitivo di supporto, lo si automatizza: e questa sarebbe la formazione gestita da un’Intelligenza Artificiale? Una confusione tra docente, tutor, FAQ, supporto, insegnamento che non aiuta a promuovere una cultura dell’apprendimento digitale, ma la allontana sempre di più.

http://www.repubblica.it/tecnologia/2016/05/20/news/insegnante_robot-140220189/

2. Machine learning for all

Titolo dell’articolo: “Soon We Won’t Program Computers. We’ll Train Them Like Dogs
Sotto (anzi, sopra)titolo: “The rise of Artificial Intelligence and the End of Code
Si parla delle reti neurali (che in realtà sono in giro da un bel po’) e di big data: tantissimi dati vengono proposti ad un algoritmo che cerca di riconoscere strutture invarianti. Dall’accento sul codice si passa all’accento sui dati. Questo modello di software viene presentato come il futuro: presto tutti i programmi saranno di questo tipo, e non ci sarà più bisogno di programmatori che scrivono codice.
Con le parole di Monaghan: “Our machines are starting to speak a different language now, one that even the best coders can’t fully understand. If you want to teach a neural network to recognize a cat, for instance, you don’t tell it to look for whiskers, ears, fur, and eyes. You simply show it thousands and thousands of photos of cats, and eventually it works things out. […] Programming won’t be the sole domain of trained coders who have learned a series of arcane languages. It’ll be accessible to anyone who has ever taught a dog to roll over. “For me, it’s the coolest thing ever in programming,” Thrun says, “because now anyone can program.”

Ora, a parte il fatto che di programmi che scrivono programmi ce ne sono sempre stati (i compilatori fanno appunto questo, con grande modestia), il machine learning si applica solo ai casi in cui esistono milioni di istanze che si possono confrontare – e non tutti i problemi cui si applica il software sono di questo tipo. A me pare che l’articolista si sia divertito a fare l’apocalittico (perderemo il controllo dei nostri software, tutti i programmatori a casa…) ma faccia finta di non sapere che i programmi si progettano, si producono, si valutano, si modificano, si biforcano. Prospettare un futuro di sole reti neurali significa ridurre tutte le attività dei programmatori alla sola scrittura di codice che implementa algoritmi.
Ancora, un riduzionismo mascherato da visione futuribile. Certo non aiuta a formare una generazione di coders creativi.

http://www.wired.com/2016/05/the-end-of-code/

Elaborazione di testi e fogli di calcolo: ma che palle…

Mag
21

Ieri ultima lezione prima delle presentazioni dei “project work” degli studenti (ovvero dei lavori di gruppo come preesoneri dell’esame). Avevo scelto un tema che  in realtà mi inquietava: elaborazione di testi e fogli di calcolo. Tradotto: Word e Excel. Il resto del corso  è stato sulle reti, i diritti dei cittadini, la privacy, l’accessibilità, e poi avrebbe dovuto toccare mappe, strumenti di collaborazione online, software didattico. Ma mi sentivo in dovere di parlare anche di strumenti che gli studenti di un’Università si suppone che sappiano usare, anche se nessuno gliel’ha insegnato.
Siccome non sono un guru di Word, non conosco a memoria tutte le funzioni di Excel, anzi per la verità non uso nessuno dei dueda quindici anni, mi sono domandato come faccio spesso: qual è la specificità di questa situazione? cosa posso proporre io a  questi studenti di terzo anno, in procinto di laurearsi, che non possano trovare su Youtube o in un libro “Word for Dummies”? Come può aiutarli il fatto che trent’anni fa ho scritto il codice sorgente di un word processor, in Pascal? Qual è il mio valore aggiunto?

Le risposte che mi sono date le elenco qui, magari sono utili a qualcun altro.
1. La storia delle tecnologie della scrittura e del calcolo (supporti, strumenti, conservazione) serve a capire che ci sono modelli d’uso che non si capiscono se non riportandoli alle tecnologie precedenti. Il Caps Lock sulle tastiere dei computer…
2. La storia serve a distinguere gli aspetti davvero nuovi da quelli di re-mediation. Invenzioni, passione. Cosa ha provato il tizio che ha inventato Visicalc, quando non esisteva niente di simile nel mondo? Perché la gente scrive programmi, inventando modi che non esistono di trattare le rappresentazioni del mondo?
3. La storia serve pure a relativizzare la maniera di fare le cose che pensiamo sia unica. La pietra è stata superata dal papiro, dalla pergamena, dalla carta, dal CDROM e dal disco a stato solido. Quando vogliamo lasciare una traccia per gli alieni sulla luna, quale supporto scegliamo? e quale formato?
4. Distinguere alcuni concetti base  può essere util a cavarsela quando le cose non vanno come pensiamo. Usiamo file di cui non sappiamo quasi nulla (chi ha mai aperto un file ODT o DOCX per vedere cosa c’è dentro?) e confondiamo formati, oggetti e supporti. Così a volte siamo bloccati.
5. Word ed Excel non sono solo programmi che fanno cose, sono ambienti dentro cui io posso fare cose. Ambienti che posso usare per scopi diversi. Li posso estendere, adattare, ridurre. Li posso collegare ad altri software. Li posso usare da solo o con altri.
6. Non c’è solo scrivere o mettere numeri, c’è anche – eventualmente, non necessariamente ! – progettare e costruire un testo o gruppo di testi, una matrice o una serie di matrici collegate. Gli artefatti digitali sono flessibili “per loro natura”: si può partire dalla fine e tornare indietro.
7. Ci sono modelli d’uso diversi e obiettivi diversi: risparmiare tempo automatizzando compiti, assicurarsi della validità dei dati, scoprire cose nuove (con le statistiche  o con la risoluzione delle equazioni lineari).
8. Prima dei menù ci sono gli obiettivi. Voglio fare questa cosa: ci saranno una o più strade per farla, me le vado a cercare. Sono ambienti da scoprire un po’ alla volta. Non serve studiare tutto il manuale prima di lanciare Excel.
9. Distinguere i dati dalla struttura di quei dati e dall’interfaccia verso quella struttura è utile, perché permette di fare più cose: strutturare diversamente i dati, applicare interfacce diverse.
10. Non conosco MS Excel 🙁 , ma conosco Libre Office Calc. Ho verificato che in generale gli studenti non sanno nemmeno che esistono alternative.E così non possono scegliere.

Alla fine è questo che ho fatto: ho provato a suggerire visioni allargate, a condividere la mia passione e creare un po’ più di consapevolezza. Tanto peggio per le tabelle pivot e i documenti master, li studieranno un’altra volta.

Perche’ i bambini devono imparare a programmare

Dic
18

Mi sono avvicinato al tema “applicazioni didattiche del digitale” per ragione emotive, estetiche. Cioè perché mi affascinava l’idea. Non avevo nessuna conoscenza e nessuna competenza. Venivo da studi classici e da una laurea in Filosofia. Fine anni ottanta.

Ho comprato un PC (senza sistema operativo) e ho cercato di vedere quello che si poteva fare. Ho letto il leggibile, ho riflettuto, ho sperimentato.

Il primo risultato della riflessione è stato: per usare i computer per l’educazione bisogna prima capire cosa è l’educazione. E prima ancora, cos’è l’apprendimento, visto che l’educazione si suppone serva a migliorare e favorire l’apprendimento.

Sono arrivato (attraverso Dewey e altre letture) all’idea che l’apprendimento non è un fenomeno di introiezione di informazioni, ma nemmeno di costruzione di strutture mentali. E’ una ristrutturazione dell’ambiente, proprio quello esterno. Nel mondo reale è difficile farlo; l’ambiente educativo è invece uno spazio/tempo progettato apposta per permettere questa ristrutturazione, e per gestirla insieme a chi apprende. Ristrutturazione che si scontra con limiti, che vengono spinti sempre più oltre. Ma che nel mondo fisico, ben presto diventano ostacoli insormontabili.

A questo punto viene in aiuto il digitale, che ha molti meno limiti. Come parte di un ambiente educativo, gli artefatti digitali (programmi, dispositivi) devono essere costruiti in modo da facilitare questa modifica dell’ambiente. Devono essere modificabili da chi li usa. Quindi come minimo si deve dare all’utente (ma che brutta parola!) la possibilità di capire come cambiarli per adeguarli. Quindi interfacce riconfigurabili a piacere, modalità operative che si possono incrementare.

L’attività di modifica di un oggetto digitale in generale si chiama programmazione. E a differenza della modifica degli oggetti fisici non ha praticamente limiti.

Quest’attivita è – o dovrebbe essere – la maniera fondamentale, in un ambiente educativo, per interagire con il software. Qualsiasi software: che sia un gioco o un programma di videoscrittura (sono i campi dove ho fatto un po’ di esperimenti), o per fare calcoli, o simulazioni, etc etc. E i software devono essere costruiti in modo da permetterlo, a diversi livelli. Tecnicamente e legalmente. Trascinando pannelli o programmando.

 

L’obiettivo non è imparare a programmare, né per assicurarsi un futuro, né per sviluppare abilità logico-matematiche. L’obiettivo è imparare meglio con strumenti che sono pensati apposta per questo.

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.

Diretti o usabili? forse non basta che siano open…

Ott
05

Raw open, now. Va bene come monito alla pubblica amministrazione,  ma dal punto di vista di chi con quei dati voglia fare qualcosa  è importante anche la maniera in cui i dati sono accessibili. Linkati, daccordo, ma anche significativi, puliti, comprensibili, tradotti. E forse l’accesso diretto al file non è sempre la maniera migliore. Per fortuna ci sono altre possibilità, come quella di inserire, accanto all’accesso diretto ai file, uno strato di API dedicato ad operazioni di livello superiore, come la ricerca,  il confronto, il commento.

La possibilità di accedere agli opendata tramite API standard significa offrire ad imprese e cittadini che vogliano sviluppare applicazioni due vantaggi principali: la semplificazione dell’accesso e e la garanzia che un’applicazione che si appoggi sulle API possa essere utilizzata senza modifiche anche in altre città, a prescindere dalla struttura dei repository adottata. Diversi progetti europei hanno adottato questa filosofia (da CitySDK a  Fiware) e offrono alle città intelligenti una maniera unica per presentare i dati del turismo, della mobilità e – perché no – del lavoro.

Se siete a Bologna per la Smart City Exhibition di quest’anno, siete invitati a discuterne il 23 Ottobre alle 10 nel laboratorio gestito in collaborazione da Istituto Italiano OpenData, Lynx e Rete Italiana OpenSource.:

Open data per le smart cities – uno spazio europeo unico attraverso le API

http://www.smartcityexhibition.it/it/open-data-le-smart-cities-uno-spazio-europeo-unico-attraverso-le-api

 

Year of Code

Ago
12

Il 2014, per chi non lo sapesse, è stato dichiarato “Year of Code” nel Regno Unito. Anno del codice, nel senso di “anno della programmazione”. Da settembre, la programmazione verrà insegnata nelle scuole elementari e medie, ovvero tra i 5 e i 16 anni. http://yearofcode.org/
In September 2014 coding will be introduced to the school timetable for every child aged 5-16 years old, making the UK the first major G20 economy in the world to implement this on a national level”.
Questa decisione ha portato con sé – o forse è la parte visibile e ufficiale di – una miriade di attività collaterali, su base volontaristica, tutte mirate a diffondere la programmazione tra i ragazzi, ma non solo. Coding is empowering: programmare rende più fichi.
http://issuu.com/techmixmag/docs/techmix_magazine_issue__3/15?e=0/8750602

E’ interessante andare a vedere l’immaginario che viene costruito per coinvolgere la popolazione, non solo in UK ma anche negli USA e altrove. Quella che viene presentata non è più la figura del geek, dell’informatico tipico, un po’ secchione e un po’ sfigato, ma quella della mamma disoccupata che si ricicla in un altro settore, quella del genio artistico che inventa una startup, del ragazzino qualunque che tira fuori la app da 200.000 dowload in una settimana
http://www.codecademy.com/stories/99-how-to-outgrow-the-fear-of-starting

Premesso che chi scrive ha passato alcuni anni ad insegnare a programmare a classi di bambini tra 10 e i 14 anni, che è da sempre un appassionato di Logo, di cui ha seguito con interesse tutte le evoluzioni (da MicroWorlds a StarLogo a NetLogo), e che ha continuato ad avere un interesse “estetico” per gli ambienti di programmazione visuale in qualche modo derivati (Alice, Squeak/Etoys, Scratch, ….) che oggi vanno per la maggiore e che rendono il termine “coding” abbastanza pretestuoso. Premesso che anche ora che non la pratico quotidianamente trovo la programmazione un’attività molto gratificante, come ogni tipo di creazione artistica, e che al pari della musica o delle arti grafiche mi dispiace che questo piacere non venga condiviso da molti.
Tutto ciò ed altro premesso, non è quindi per avversione preconcetta verso l’apprendimento della programmazione in giovane età che mi è venuta l’idea di scrivere queste note. Non penso che i bambini debbano essere tenuti lontani dalle macchine, né che la logica dell’utenza passiva multimediale debba restare l’unica, o quella privilegiata, fino alla maturità.
Ma il recente fiorire di iniziative per introdurre i bambini alla programmazione (diciamola meglio: per portare dei ragazzini a sviluppare delle app in una sola giornata) mi lascia invece perplesso.

Cerco, nelle presentazioni delle giornate di introduzione alla programmazione organizzate, per esempio, da CoderDojo, le ragioni di questo rinnovato interesse. Le cerco anche con una certa invidia tutta italiana perché mi ricordo il triste destino che ha avuto da noi quella parte di curriculum informatico scolastico dedicata alla programmazione. Ricordo le ragioni di quell’esclusione: ad esempio, che i bambini, nella scuola dell’obbligo, non devono imparare a programmare più di quanto non debbano imparare a riparare una lavatrice. Ricordo l’informatica “carta e matita” di Giovanni Lariccia, ma anche la scoperta dell’ECDL, l’attenzione per gli strumenti di produzione di media più che su quelli per la produzione di programmi, etc … Oggi, quando vedo gli entusiastici commenti a queste iniziative, mi chiedo: quali sono, stavolta, le ragioni? Perché passare un pomeriggio a programmare, a 10 anni, è meglio di passare un pomeriggio a giocare a pallone? Perché organizzare spazi e tempi extrascolastici per offrire questa possibilità? Perché dedicarci risorse pubbliche, o private?

Mi pare che le ragioni citate siano di almeno due ordini:

1. Aspetti economici: sono facili da citare, molto meno da dimostrare.
Nel 2015 ci saranno in Europa 700.000 posti di lavoro vuoti nel settore ICT (fonte: Commissione Europea, http://europa.eu/rapid/press-release_IP-13-52_it.htm). Negli USA, entro il 2022 ci saranno 2.600.000 posti di lavoro nel settore dell’informazione; di questi, 750.000 per i programmatori, con una crescita del 22,8 % (fonte: Bureau of Labor Statistics, http://www.bls.gov/news.release/pdf/ecopro.pdf).

This means that U.S. companies would be forced to outsource valuable coding jobs to India, China, Eastern Europe, and other countries with growing IT sectors, while thousands of Americans remain unemployed or stuck in low-skilled, low-wage positions” (http://opensource.com/education/13/4/teaching-kids-code).

A parte il fatto che di questi milioni di posti di lavoro solo una parte è riservata ai programmatori propriamente detti, mentre la maggioranza è lasciata a tutti gli altri lavoratori del settore (analisti, progettisti, sistemisti, grafici, esperti di reti, di sicurezza, commerciali, docenti, installatori, …), e a parte il fatto che il lavoro di programmatore non è necessariamente così ben pagato e attraente, il punto è: quale politica educativa e del lavoro porterà a colmare questi vuoti. Da dove si comincia? Dalla riforma dei curricula universitari? Da quella delle scuole tecniche? Dalla riforma del mercato del lavoro? O dai Coding Day per i ragazzi?

Ad esempio, quale legame ci sarebbe tra la giornata festosa in cui si sviluppa un videogioco con gli amici e la capacità di svolgere un lavoro del tipo di quelli di cui il mercato ha bisogno? Non è detto che quello che si apprende oggi sia ancora utile domani. Il ragazzino di 10 anni che oggi produce – in una giornata – una app per Android avrà 18 anni nel 2022, e allora non avrà davanti le stesse piattaforme, gli stessi linguaggi e nemmeno gli stessi concetti. Basti guardare quali erano appunto linguaggi e sistemi operativi dieci anni fa e la distanza abissale che li separa da quelli di oggi. Manca, a mio avviso, uno studio che dimostri gli effetti a medio o lungo termine di queste iniziative. Effetti che potrebbero essere cercati sulla scelta della scuola, sul percorso di apprendimento personale, sulle letture scelte, sull’uso del tempo libero, sullo scambio di conoscenze con i pari. E magari si potrebbe anche ragionare meglio su quali linguaggi, quali sistemi, quali tipi di problemi, quali domini applicativi sono più adatti per avviare il giovane programmatore verso il suo radioso futuro rendendolo più concorrenziale rispetto ad altri.

2. Aspetti sociali: subito dopo quelle economiche, vengono citate le ragioni più “etico-politiche”. Il ragionamento è più o meno questo: la nostra vita è costellata di apparecchiature elettroniche del cui funzionamento non sappiamo nulla; se avessimo le competenze digitali attive (coding specials) saremmo in grado di difenderci; quindi è bene acquisire queste competenze fin da piccoli.
E’ un po’ la motivazione che sottintendeva lo studio dei mass media e della pubblicità a scuola qualche anno fa: se li conosci, li smascheri.

Ad esempio, sempre con le parole di Rebecca Lindegren:
Children’s personal and professional lives will increasingly be shaped by computer programs. Without the ability to code, they will become passive consumers at the mercy of programmers working for technology giants, unable to construct or meaningfully interact with the virtual reality that surrounds them” (http://opensource.com/education/13/4/teaching-kids-code).

Questo passaggio dell’articolo è, a mio avviso, il più interessante. Senza la capacità di programmare, i bambini diventeranno passivi consumatori etc etc. Con la capacità di programmare (acquisita in un paio di pomeriggi tra amici) invece saranno vaccinati e potranno interagire significativamente con il mondo virtuale che li circonda.

Da notare almeno due cose: la prima è che la capacità di programmare vaccina dallo strapotere dei giganti della tecnologia. Si può anche essere d’accordo in teoria, ma va definito cosa intendiamo per “capacità di programmare”. Un’attitudine? Un’esperienza, anche limitata? Una competenza specifica e verificata da terzi?
Stiamo parlando della buona abitudine di leggere il codice sorgente di ogni programma che si utilizza? Della curiosità verso ogni nuova soluzione che viene presentata, curiosità che non si contenta di un’etichetta o di una descrizione ma vuole arrivare a capire come funziona oggi e come funzionerà domani? O della capacità di progettare, sviluppare e manutenere soluzioni alternative?
Sono “capacità” completamente diverse. Si raggiungono, e si perdono, in tempi diversi e in modi diversi. Alcune di queste non sono generiche, ma possibili solo in connessione con certi contesti tecnologici e legali, primo fra tutti quello dell’apertura del codice sorgente.
Ora in generale aumentare la quota di competenze creative che viene appresa a scuola è probabilmente utile a preparare un cittadino capace di costruire narrazioni originali, oltre che di ascoltare quelle degli altri. Competenze che si possono sviluppare componendo musica, scrivendo sceneggiature, disegnando fumetti e persino programmando (uno spartito o un programma non sono poi così diversi, da questo punto di vista). Qui però è in gioco una riforma del curriculum scolastico, e non solo qualche ora di laboratorio.

La seconda cosa da notare è che la possibilità di interagire pienamente con la realtà (virtuale, nel senso dell’insieme di dispositivi, reti, server, …) non sembra dipendere solo da queste competenze. Anche qui, andrebbe forse ricordato che, oggi molto più di ieri, ognuno di noi ha comprato già preinstallati o consentito a installare sui propri dispositivi digitali – pc, tablet, smartphone, televisori, frigoriferi,… – centinaia di programmi del cui funzionamento effettivo non possiamo sapere quasi nulla, se non quello che esplicitamente ci dicono i produttori. Il codice sorgente di questi programmi (che a volte chiamiamo “applicazioni” o amichevolmente “app” per farceli sembrare meno complessi e e pericolosi) non è disponibile per la lettura o la modifica. Sapere programmare non aiuta minimamente a evitare che raccolgano i nostri dati e ne facciano un uso non previsto (da noi). Sapere programmare non ci permette di evitare di usarli: alzi la mano chi si può permettere di non avere un account gmail o una pagina FB. Senz’altro non ci aiuta a modificarli, a impedire che svolgano azioni se non illecite, almeno non gradite. Interagire significativamente con gli altri tramite app e reti, ricevere e fornire dati – filtrandoli – richiede delle competenze, che oggi fanno sicuramente parte di quelle di base di ogni cittadino. Ma allora non è sufficiente un pomeriggio di manipolazione di Scratch, serve anche qualche informazione in più. Informazione che in effetti né la scuola dell’obbligo, né quella superiore, né l’università consegnano.

3. Vengono in mente però anche altre ragioni, forse meno nobili. Per esempio, una generazione di ragazzini che sono in grado di produrre un’app in poche ore significa da un lato un serbatoio immenso da cui andare a pescare i migliori developers senza doversi assumere l’impegno e la responsabilità di formarli adeguatamente e di aspettare il momento in cui, accanto ad altre competenze utili per una vita completa, sviluppino anche quelle di coding; e dall’altro un enorme mercato per quelle app…
Ad esempio la Scuola 42, a Parigi, dichiara esplicitamente di porsi come un’alternativa ai percorsi scolastici tradizionali per scovare dei geni informatici che probabilmente sarebbero degli esclusi nel sistema tradizionale (http://www.42.fr/ledito-de-xavier-niel/). Da notare che la scuola 42 è gratuita. Un progetto simile, ma più orientato al sociale (e quindi finanziato con fondi pubblici) è quello di Simplon (http://lafrancesengage.fr/toutes-les-actions/simplonco.html).
Soprattuto nel primo caso, si unisce l’idea della selezione anticipata con quella dell’investimento vantaggioso: i migliori – indipendentemente dalla posizione sociale – possono ricevere la migliore formazione e avere una via privilegiata per l’accesso al lavoro. Investire in formazione rende meglio che affidarsi ad una selezione, permette di arrivare prima e assicurarsi i servigi di uno sviluppatore che è sempre più giovane.
Non che queste ragioni siano necessariamente quelle che motivano gli organizzatori delle giornate; ma è lecito domandarsi se non sono quelle che motivano gli sponsor, che sono spesso grandi imprese del settore telecom se non direttamente dell’ICT.
Dopo tutto, perché perdere tempo a formare tutti gli studenti alla programmazione per poi verificare con un test quali sono adatti al lavoro? Basta farlo solo con i più svegli.

Riandando a quelle lezioni con ragazzi delle scuole medie, in cui per gruppetti cercavamo di costruire dei videogiochi con i limitati strumenti a disposizione (erano gli anni ’90), la differenza che mi salta agli occhi è che allora si aveva in mente un progetto educativo. Ovvero: si sceglieva un linguaggio perché era stato pensato per i bambini (e non solo perché era una versione semplificata di un ambiente di simulazione di Android); si sceglieva un dominio (ad esempio, ma non necessariamente, quello matematico) perché alcuni aspetti del programma di matematica erano più comprensibili affrontandoli dal punto di vista della costruzione anziché da quello della analisi – per esempio la geometria; ma si usava anche il Prolog per studiare la grammatica. L’obiettivo era pienamente didattico: imparare a programmare all’interno del percorso scolastico non era la preparazione a qualcos’altro, ma un’attività degna di per sé, che aiutava a imparare meglio e più in profondità. Programmare era un modo generale per affrontare l’apprendimento. L’oggetto e le finalità dell’apprendimento però erano determinati da altre considerazioni.

E’ possibile, lo riconosco, che io abbia una visione un po’ edulcorata, mitica, di quelle ore. Forse tutta questa chiarezza teorica non c’era e la consapevolezza del progetto educativo la sto inserendo a posteriori. Allora, come adesso, c’era molta buona volontà e una speranza di fare qualcosa di diverso, e di utile.

Mi auguro almeno che questo stesso spirito animi i volontari che oggi supportano i ragazzi nello sviluppo della loro prima app.