steve's

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.

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.