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.

Critical Code Studies

Gen
20

Critical Code Studies è un’etichetta che copre le attività di discussione e studio del codice sorgente che si svolgono presso l’Università della Southern California (Humanities and Critical Code Studies Lab, HaCCS).

Oggetto di studio sono i codici sorgente, cioè quella cosa scritta da umani (per lo più) e che poi viene eseguita dai computer, telefoni, satelliti, droni, etc. Solo che, avete letto bene, non è il dipartimento di Computer Science che se ne occupa.

“Critical” è un termine chiave. Si può leggere in due modi: il primo è come parallelismo alla critica letteraria, cioè come richiamo all’utilizzo di approcci e tecniche che finora sono state applicate ai testi tradizionali (digitalizzati o meno). Significa che i codice sorgenti vengono trattati come opere, con una dignità che va oltre quella di pure macchine strumentali fatte di codici binari. Un codice sorgente è scritto in un linguaggio (uno dei circa 2500 censiti), e viene non solo scritto per essere “interpretato” dal computer, ma anche per essere letto, discusso, modificato, copiato. E – come è normale per ogni prodotto di scrittura – presenta aspetti estetici, stilistici, retorici. Se esistono poesie scritte in linguaggi di programmazione (la prestigiosa e serissima Stanford University fa annualmente un concorso, http://stanford.edu/~mkagen/codepoetryslam/), virus presentati come opere d’arte http://0100101110101101.org/biennale-py/, programmi scritti per sfidare il lettore alla loro comprensione http://ioccc.org/, linguaggi in cui si programma usando i colori in omaggio a Mondrian http://progopedia.com/language/piet/, significherà pure qualcosa.

L’altro senso di “Critical” è più forte: indica che non ci si vuole limitare a studiare i testi, ma anche i contesti della loro produzione e uso. Significa che l’approccio usato vuole tener conto anche delle questioni di genere, di cultura, di divario economico. Perché non basta allenare i bambini al pensiero algoritmico: il software è qualcosa di ben più complesso di un algoritmo che muove un pupazzetto su uno schermo.

Per farsi un’idea, si può leggere questa introduzione di Mark Marino, del 2006: http://www.electronicbookreview.com/thread/electropoetics/codology

Trovate tanti riferimenti alle persone che hanno riflettuto su questo tema: da John Cayley a Florian Cramer, Loss Pequeño Glazier, Geoff Cox, Alex McClean, Adrian Ward.

A partire dal 2010, viene tenuto annualmente un Working Group (http://haccslab.com/) dove si possono discutere online frammenti di codice. Quello di quest’anno è appena cominciato.

Tutto questo accade a Los Angeles, USA.

Qui da noi, sono anni – almeno dal 1999 – che cerco di impostare un lavoro simile (con seminari, articoli, slide, wiki: http://ada.lynxlab.com/staff/steve/public/docu/lidia/), ma ahimé senza molto successo. Ma sono io che ho sbagliato Paese.

 

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.