Coding: la resa dei conti

Che cos’è?

Per chi avesse bisogno di una rinfrescata veloce, coding significa letteralmente “l’attività di scrivere codice sorgente”, che è uno dei quasi-sinonimi di “programmare”. Quasi, perché programmare può significare anche analizzare, progettare, verificare, integrare un codice sorgente, mentre coding fa riferimento solo alla scrittura del codice. Così coder è un quasi-sinonimo di programmer, developer.

Con “coding”, in questo momento e in Italia, ci si riferisce però alle attività di introduzione dei bambini alla programmazione, attraverso ambienti di programmazione visuale, cioè in cui paradossalmente non serve (anche se è possibile) scrivere il codice, ma è sufficiente posizionare oggetti simbolici che stanno al posto di operatori, variabili, condizioni.

Il MIUR, in collaborazione con il CINI, all’interno del programma “La buona scuola” ha spiegato come e perché va introdotto il coding nella scuola in un sito dedicato (http://programmailfuturo.it/come/ora-del-codice). L’obiettivo dichiarato è “fornire alle scuole una serie di strumenti semplici, divertenti e facilmente accessibili per formare gli studenti ai concetti di base dell’informatica”. L’iniziativa in realtà ripropone corsi e ambienti di lavoro creati e gestiti da una associazione no profit statunitense (Code.org) che ha come partner Microsoft, Google e tanti altri. Code.org ha in realtà obiettivi più ampi: punta all’integrazione razziale e a diminuire il gap di genere, a modificare i curricula delle scuole elmentari e medie negli Stati americani, a soddisfare la richiesta di più informatica da parte dei genitori.

Coding è anche praticamente sinonimo dell’uso di Scratch, ambiente/linguaggio sviluppato e messo a disposizione gratuitamente dal MIT.

Ma perché ci tengo così tanto a parlarne?

Perché è così importante parlare del coding?

Perché ritorna improvvisamente anche in Italia, portata da un vento dell’ovest, l’idea che si possa non solo usare la tecnologia digitale a scuola, ma anche produrla. Dopo anni e progetti ministeriali in cui l’informatica (parola desueta) veniva inserita in vari modi nel curriculum, l’idea di far costruire programmi agli studenti era stata abbandonata. La tecnologia andava usata, studiata, ma non prodotta. Ora, sulla spinta di movimenti internazionali presenti in USA, GB, Francia, e sostenuti esplicitamente dai rispettivi Governi, si torna in qualche modo indietro. Come mai?

E’ diventata indiscutibile l’idea che per cavarsela in un mondo sempre più digitale occorra sapere non solo come funziona l’app che usiamo per chattare, ma anche sapere come si sviluppa. Per ragioni economiche, etiche, politiche: “Program, or be programmed.”

Ora, al di là della condivisibilità dell’idea in sé – che pure andrebbe analizzata meglio – è il ruolo della scuola pubblica che è in gioco. La scuola, viene detto, si deve occupare di questa esigenza, deve investire risorse non per educare nelle materie tradizionali anche tramite l’uso di tecnologie ma per salvare i bambini da un futuro di cui non avranno la possibilità di essere attori. Questo è ben diverso da quanto ipotizzato nei vari Multilab, PNTD, Scuola 2.0 etc. Lì si parlava di didattica multimediale o di alfabetizzazione digitale – cioè in qualche modo del presente. Qui si parte dal futuro. E’ un passo importante, a cui potrebbe corrispondere un analogo interesse per il ruolo che avranno nel futuro le competenze linguistiche, matematiche, storiche che vengono acquisite oggi. Serviranno? Saranno fondamentali? Salveranno i giovani? Vanno aggiornate sulla base di come sarà la società tra dieci, venti anni? Belle domande.

Sarebbe però altrettanto importante, a mio parere, riesaminare tutti questi programmi ministeriali e farne una valutazione: cosa ha funzionato? Quali obiettivi sono ancora condivisibili e quali strategie si sono rivelate sostenibili? Sono stati investite risorse ingenti: prima di lanciarci in un ennesimo programma – anche se, in questo caso, quasi a costo zero – non sarà il caso di sviluppare una critica onesta delle azioni passate? Magari si scopre che qualcosa si può ancora recuperare. Ad esempio, ci sono migliaia di lavori fatti a partire almeno dagli anni ’80 da insegnanti con il Logo nelle prime classi (vedi sotto): vogliamo provare a riprendere e a capire cosa ha funzionato, che effetti hanno portato? I bambini che hanno giocato con la tartaruga oggi hanno forse trenta o persino quarant’anni: vogliamo provare a vedere se quelle attività gli sono state utili ad avere un diverso approccio al digitale (oltre che una migliore comprensione della geometria piana)?

Insomma parlare del coding in Italia significa ripensare quello che stiamo facendo con i computer nelle scuole, quello che abbiamo fatto e quello che vorremmo fare. E scusate se è poco.

In attesa di questo ripensamento, almeno auspicato, quando leggo di “coding” cerco dei pareri oggettivi, delle valutazioni delle esperienze fatte, dei progetti a medio termine.

 

Gli schieramenti in campo

Quelli che ho trovato finora, con rare eccezioni, sono due partiti schierati: quelli che sono incondizionatamente a favore del “coding in classe”, dei Dojo, della settimana, il giorno e l’ora dei codice; e quelli che sono contrari per principio all’insegnamento della programmazione ai bambini.

Chiarisco subito che non faccio parte di nessuno dei due partiti e faccio fatica a discutere con entrambi. Dei primi, non condivido l’entusiasmo acritico, senza radici nella storia e senza una visione degli aspetti culturali, sociali, economici che sono intorno al coding. Non capisco come ci si possa dedicare a Scratch come se non esistesse altro, e Scratch non fosse nato sulle ceneri del LOGO. Non capisco come si possa copiare un modello educativo statunitense senza adattarlo al contesto italiano, o almeno senza capirlo.

Dei secondi, non condivido l’idiosincrasia verso tutto quello che sa di macchina e ancora di più la netta separazione tra mondo digitale e mondo “vero” (complesso, affettivo, etc). Sarà perché la mia vita professionale si è giocata tutta nello spazio tra questi due mondi: non solo perché sono nato in uno e mi sono trasferito nell’altro, ma perché il dialogo tra questi due mondi mi sembra interessante, anzi fondamentale. O ancora: perché finisco, oggi, per non vederla più, questa differenza. C’è un mondo solo e noi ci siamo dentro.

Provo a dettagliare le ragioni di questa posizione intermedia esaminando alcuni elementi della proposta di coding corrente, partendo dagli obiettivi.

A che serve il coding?

Un’attività didattica non può essere raccomandata solo perché è “carina” e facile, perché docenti e discenti si divertono. Deve avere uno o più obiettivi. Quali?

Ne ho raccolta una lista disordinata prendendo qua e là; alcuni secondo me sono condivisibili, altri meno. Alcuni sono molto alti, altri del tutto pratici. Ma è fondamentale che chi organizza l’attività ce li abbia chiari, altrimenti si muove casualmente, spreca tempo ed energie e rischia pure di fare danni.

1. Quello dell’insegnamento del computational thinking? La questione è spinosa. Intanto non è facile definire il pensiero computazionale. Computazionale dovrebbe voler dire “calcolabile”. Una funzione è computabile se esiste un algoritmo – cioè una serie di passaggi predefiniti, eseguibili da una macchina senza necessità di intervento esterno – che la calcola in un tempo finito. Ma sempre citando dal sito MIUR, “[i]l lato scientifico-culturale dell’informatica, definito anche pensiero computazionale, aiuta a sviluppare competenze logiche e capacità di risolvere problemi in modo creativo ed efficiente, qualità che sono importanti per tutti i futuri cittadini”. Qui il termine “creativo” è quello che stona di più con la nozione classica di “computazionale”. Non voglio dire che non serva creatività per programmare, anzi; ma che la relazione tra creatività e computazione è quanto meno intrigante e andrebbe approfondita: ci sono aspetti estetici nella logica? E come si coniugano con esigenze di rigore e efficienza? Non basta mettere due aggettivi insieme in una frase.
   E’ anche facile obiettare che il modo di ragionare analitico, scomponendo problemi complessi in passi più semplici, è sicuramente una competenza utile, come lo è il modo opposto per aggregazioni, per sintesi, in cui si cercano somiglianze tra situazioni a livello più alto. Il pensiero computazionale ha a che fare con uno solo di questi modi, o con entrambi?
   Inoltre mi pare discutibile l’identità tra coding e pensiero computazionale, nel senso che mentre è chiaro che non si possono costruire programmi se non si ha in testa un algoritmo, scrivere programmi non è solo implementare algoritmi in un certo linguaggio di programmazione. Non si scrivono programmi solo per risolvere problemi, e l’ideazione (appunto, la creatività) serve quanto il rigore, altrimenti staremmo da anni a risolvere gli stessi problemi in maniera più efficiente. Affidarsi solo al pensiero computazionale mi pare molto restrittivo e poco fedele alla realtà.
   In ogni caso: tanti anni fa un ricercatore del CNR, Giovanni Lariccia, proponeva nelle scuole un approccio didattica all’informatica senza computer (“carta e matita”). Lo faceva sia perché di computer, onestamente, ce n’erano pochi, sia perché così era possibile collegare l’informatica all’esperienza quotidiana. Non sarebbe male, per una volta, ripartire da esperienze Italiane invece di importare modelli statunitensi senza adattamenti. Ma di questo, più avanti.
2. Quello di preparare le nuove generazioni ai nuovi lavori? Questa è una delle argomentazioni più stupide che abbia mai sentito. Non c’è nessuna connessione tra un ambiente come Scratch e gli ambienti di programmazione professionali. E vista la distanza che c’è tra concetti, modelli, strumenti di dieci anni fa e quelli di adesso, la pretesa che insegnare oggi quello che sarà utile tra dieci anni è ridicola. Come è ridicolo pensare che l’informatica sia solo programmazione. Ci sono milioni di posti di lavoro in attesa nel comparto informatico, là nel 2025, ma non abbiamo nessun’idea precisa di quali saranno, e certamente non sono tutti posti di sviluppatori di app. Anzi, c’è chi sostiene che di programmatori domani non ne servirà nessuno, visto che la programmazione sarà gestita autonomamente dai programmi stessi (http://steve.lynxlab.com/?p=426)
3. Quello di far costruire ai ragazzi delle storie in maniera alternativa alla scrittura? Bene, è un’attività molto utile e interessante, ma che si può fare benissimo in altri modi, dal disegno al teatro, dai fumetti al video. In qualche modo, però, questa è la motivazione che condivido di più, ma per un motivo diverso. Programmare – progettare e scivere qualsiasi programma – è un altro modo di raccontare una storia: inventare un contesto, degli attori, un plot. Sapere creare delle storie (o saperle smontare) è una competenza significativa in tanti campi, e mostrare come questi campi non siano poi così lontani è un obiettivo sensato. Un po’ paradossalmente: se a scuola si insegnasse diffusamente e coerentemente a costruire storie, allora farlo con un programma sarebbe un’estensione utile. Però attività di costruzione in classe di problemi di matematica, o di scenari storici alternativi, non ne vedo tante in circolazione.

4. Quello di vaccinare i giovani contro lo sfruttamento indebito dei loro dati raccolti da un’app o da un social network system, o contro la pratica di spacciare come utilities gratuite programmi e siti che hanno scopi diversi da quelli dichiarati? Daccordo, ma allora occorre parlare anche di altro: di codice aperto e licenze, di privacy, di diritti, di mercato dei dati, di equilibrio tra gratuità e sostenibilità. C’è da affrontare un discorso vasto sul ruolo egemone di Google e di Facebook, sul diritto all’anonimato o all’oblio. Niente che non si possa spiegare ai bambini, con qualche attenzione, ma vorrei almeno vedere qualche passo in questa direzione critica.
5. Quello di dare ad ognuno le competenze minime per scriversi un programma per risolvere i propri problemi? Questo sarebbe un obiettivo pratico, utile almeno quanto far sì che uscendo dalla scuola un ragazzo sappia sostituire un interruttore, curarsi una ferita, fare la dichiarazione dei redditi o cambiare l’olio alla macchina (temo che non sia così). Ma allora lo strumento da proporre dovrebbe essere qualcosa in grado di produrre programmi che girano su PC, smartphone, tablet, su sistemi operativi diversi, non un ambiente esclusivamente web. Forse non tutti conoscono, ad esempio, http://www.catrobat.org/ che è un’iniziativa ispirata da Scratch ma supportata dall’Università di Graz, Austria. E’ per questo, tra parentesi, che era stato inventato il BASIC (vedi sotto).
6. Quello di affrontare la didattica di qualsiasi disciplina in maniera costruttiva? Nessuno più di me sarebbe daccordo, e tra l’altro questo è uno degli obiettivi dichiarati di Scratch. Qui però il centro non è la tecnologia, è la didattica. Che un ambiente di apprendimento debba essere aperto, modificabile, che si capisca meglio qualcosa se si sperimenta e si costruisce, dovrebbero essere tutte premesse che una didattica moderna accetta senza troppi problemi (ma probabilmente nei fatti le cose stanno diversamente). Ma allora deve essere chiaro che il punto non è né divertirsi, né imparare le iterazioni, ma comprendere il funzionamento di una cellula o la struttura di un romanzo. E direi anche che non serve per forza partire sempre da zero: si potrebbe iniziare con simulazioni già preparate e poi modificarle, estenderle, riapplicarle altrove.

 

Come si vede, di obiettivi possibili ce ne sarebbero molti. Ma servono revisioni dei programmi (quelli scolastici) e risorse umane preparate. Ci sono?

Chi può insegnare il coding?

Questo è un tema delicato, mi rendo conto. Si tocca non solo la preparazione dei docenti, ma in generale il rapporto col digitale, gli aspetti sociali, la reputazione, la divisione tra umanistico e scientifico.

Sul sito citato di “Programma il futuro” si dice che gli strumenti adottati sono “[…] progettati e realizzati in modo da renderli utilizzabili in classe da parte di insegnanti di qualunque materia. Non è necessaria alcuna particolare abilità tecnica né alcuna preparazione scientifica”. Non si parla degli studenti, ma dei docenti. Strumenti scelti perché sono facili da insegnare, non da imparare. Come si arriva a proporre un metodo e un set di strumenti in funzione non della specificità e dell’adeguatezza a uno scopo ma in funzione del numero di operatori che sono in grado di gestirli?

In breve, gli insegnanti di materie umanistiche si sono sempre sentiti esclusi dal mondo digitale. Perché era troppo complesso. Creare un programma con un linguaggio come C o Java, o anche con il meno blasonato Javascript, o persino creare a mano una pagina HTML+CSS, è un’attività che richiede troppe competenze. Alcuni ne hanno sofferto, altri se ne sono fatti una ragione. Molti hanno alzato come una bandiera la loro impermeabilità al digitale (“ah io di queste cose… insegno letteratura”).

Poi sono arrivati i CMS, e chiunque oggi può creare un sito web – magari con WordPress – senza avere la più pallida idea di cosa sta facendo. E l’onnipresente MS PowerPoint, con la possibilità di creare degli slideshow per mostrarli in classe, complice la LIM. Poi è arrivato Code.org.

Il coding (inteso come attività all’interno di un ambiente visuale come Scratch) è qualcosa che può fare, e insegnare, chiunque. I concetti informatici da comprendere sono pochi: lo stato di una variabile, le istruzioni condizionate, i cicli. E’ la grande rivincita del docente non informatico.

Ora io vorrei guardare un po’ in avanti. Cosa succede dopo che si è costruita la storia del lupo e dell’agnello con i bambini? Ci si ferma qui? O questo è solo il primo passo – come sembrerebbe a giudicare dagli obiettivi – di un percorso che dalla programmazione visuale porta a guardare il codice sorgente, e poi a scriverlo, e poi alla conoscenza di altri linguaggi ed ambienti diversi? Se si, allora “non avere abilità tecniche e preparazione scientifica” non è un requisito sufficiente. Non servirà avere un dottorato in basi di dati non relazionali, ma sapere cosa sono le basi di dati e come si può usare un file CSV per simularle, si. Sapere che significa codice sorgente, la differenza tra compilare e interpretare, saper assegnare una licenza o dare un permesso d’autore. Allora i docenti di coding vanno formati. Sempre che ne abbiano voglia.

Prima che partano delle obiezioni facili: non sto dicendo che basta essere informatici per insegnare ai bambini, o che solo gli informatici possono farlo. Sto dicendo che oltre a tutte le altre competenze, che do per scontate (pedagogiche, organizzative, psicologiche, valutative) servono anche quelle informatiche, e queste come quelle non si improvvisano. E’ faticoso? Senza dubbio. E’ più facile far finta di niente? Altrettanto.

Ma dovendo imparare un linguaggio, quale?

 

Che linguaggio?

Mi pare che in Italia ci sia una totale, incondizionata adesione alla (validissima) proposta del MIT. Coding uguale Scratch. Ma con una breve indagine via Wikipedia si scopre che di linguaggi “facili”, educativi, visuali, giocosi, ne sono esistiti, e ne nascono ogni giorno, una marea. Non servono tutti esattamente allo stesso scopo, sono diversi per espandibilità, possibilità di eseguirli su dispositivi diversi, licenze d’uso. Alcuni sono dichiaratamente alternativi a Scratch, come ad esempio Kojo (http://www.kogics.net/kojo). Sarebbe bello che una volta decisi gli obiettivi e preparate le risorse umane, si andasse a scegliere il linguaggio più adatto, tra tutti quelli disponibili, invece di scegliere sempre  e solo quello più conosciuto.

Comunque, Scratch non è nato dal nulla: deriva da Squeak!, che deriva a sua volta da SmallTalk ma innestando le idee pedagogiche del Logo. Un breve riepilogo di questi linguaggi e ambienti educativi, per lo più visuali, è qui http://steve.lynxlab.com/?p=334.

Ma per essere precisi, tutto è iniziato con il bistrattato BASIC, negli anni sessanta del millennio scorso. Per dare un’idea, non erano ancora nati né il C (1973), né il PERL (1987) per non parlare di Java (1995). In quella caverna preistorica c’erano degli uomini forse primitivi, ma con delle idee luminose.

 

1. Quando Kemeny e Kurtz nel maggio del 1964 inventano il BASIC (Beginners’All-purpose Symbolic Instruction Code) l’idea era quella di proporre uno strumento con cui chiunque potesse programmare (e si, il pensiero va a Ratatouille e al motto dello chef Gusteau “Chiunque può cucinare”). Un linguaggio talmente facile da poter essere imparato senza conoscenze pregresse in matematica e logica. Perché? Perché a quell’epoca programmare era un’attività riservata a pochi super esperti, che avessero accesso a macchine costose. E perché c’era l’idea – stiamo parlando degli anni ’60 ! – che sapere programmare fosse una competenza che avrebbe migliorato la vita di chiunque. Nasce perciò un linguaggio con una sintessi semplice, con delle istruzioni che assomigliano all’inglese, pensato in funzione dell’utente.

Un’idea che avrebbe dovuto aspettare ancora dieci anni prima di essere davvero realizzata, con la diffusione degli home computer con un interprete BASIC, capace di fare grafica e suonare. Incidentalmente, l’interprete che ha contribuito di più alla diffusione del linguaggio è stato scritto da Paul Allen, Monte Davidoff e Bill Gates.

 

2. Il Logo, altro elemento chiave del discorso, nasce pochi anni dopo l’invenzione del BASIC, cioè nel 1967. L’obiettivo è completamente diverso: in origine era stato pensato da un gruppo ricercatori nel campo della nascente Intelligenza Artificiale (del calibro di Bobrow, Feurzeig e Salomon) per insegnare la programmazione in LISP agli studenti, ma con l’intervento di un matematico (Seymour Papert) Logo diventa una maniera alternativa di imparare la geometria che non passasse per la lettura di teoremi ma per la costruzione automatica di figure in soggettiva, dal punto di vista dell’utente, che si identifica in un avatar digitale: la famosa tartaruga. Dunque con un obiettivo didattico, non legato alle tecnologie. Anche stavolta il linguaggio è progettato per essere semplice, alla portata di bambini. La base di partenza scelta è un po’ più nobile del BASIC, in termini di “generazioni dei linguaggi”: viene scelto il LISP che è un linguaggio funzionale, non imperativo. Il modello di interazione è quello dell’insegnamento ad un robot. Quando – molto più tardi – vengono realizzati degli interpreti per Apple e per PC IBM, cominciano a essere disponibili delle traduzioni nelle lingue nazionali, cioè in cui le istruzioni fossero parole comuni della lingua madre di chi lo utilizzava (SE…ALLORA, RIPETI…FINCHE), con l’idea di facilitare la scrittura di programmi da parte di bambini che non conoscono l’inglese.

Dal Logo originale sono gemmate altre versioni che hanno lasciato da parte la geometria piana e si sono concentrati sulla concorrenza o sulla multimedialità, fino a versioni in cui non era più necessario scrivere i programmi, ma era sufficiente selezionare le azioni da un menù e comporle.

 

3. Con un finanziamento considerevole dell’ARPA, mirato a ripensare il mondo dell’interazione uomo-macchina, Alan Kay e altri colleghi del Learning Research Group allo Xerox Parc nel 1971 creano il linguaggio SmallTalk. Per dire, quel gruppo di lavoro e quelle ricerche sono all’origine di innovazioni come finestre, mouse, ipertesti, tablet, programmazione ad oggetti e altre quisquilie.
SmallTalk introduce un nuovo modo di programmare, in forma di dialogo tra oggetti. E’ semplice, ha una sintassi elegante e coerente (per sommare due numeri si “dice” al primo di sommarsi con il secondo). Nasconde completamente i dettagli di implementazione, punta a far concentrare chi programma sulla struttura del problema, non sul come della sua risoluzione.
Scratch è figlio – tra l’altro – di queste tre idee potenti nate negli anni sessanta. Un linguaggio semplice, un ambiente pensato per l’educazione, una logica ad oggetti. Ma che ne è stato di quelle idee?

E oggi?

Se oggi ci guardiamo intorno, vediamo una situazione completamente diversa da quella che avevano immaginato i mitici precursori. I programmatori sono aumentati moltissimo di numero, ma non è l’uomo qualunque che programma, è solo chi ha intrapreso un percorso formativo specializzato. I programmi sono ovunque, ma quasi nessuno sa/può modificarli (o almeno sceglierli con consapevolezza di quello che fanno). Tutti sanno cos’è un’app, ma nessuno ha un’idea vaga di come funziona, quali dati gestisce, a chi li invia. Con gli evidenti rischi per la privacy, e con l’arricchimento velocissimo di chi costruisce e vende profili e pubblicità, eccetera eccetera. Tutti hanno in bocca il termine “opensource”, usandolo magari a sproposito e confondendolo con “gratis”, ma dimenticano che quasi nessuna delle app che hanno felicemente installato sul proprio smartphone lo è.

Il sogno di Kemeny dell’uomo qualunque in grado di programmare non si è realizzato, ma anche quello di Papert di cambiare radicalmente la didattica tramite la tecnologia digitale non sembra passarsela molto meglio. SmallTalk non è più utilizzato, anche se ha dato origine a quasi tutti i linguaggi moderni.

Una domanda che a me viene spontanea è: ma se, sostanzialmente, non c’è grande differenza tra le caratteristiche dei primi linguaggi “educativi” e quelli di oggi, perché stavolta dovrebbe andare meglio?

Perché il BASIC è stato snobbato (pure se esistono implementazioni moderne, per Windows e per Linux) e il Logo dimenticato nelle scuole? Come facciamo ad assicurarci che non succeda di nuovo? Non sarà il caso, stavolta, di fare attenzione alla situazione globale e di assicurarci che le condizioni di successo per l’iniziativa ci siano tutte?
A proposito di risorse, ma quanto tempo ci va dedicato?

 

Un’ora di coding è sufficiente?

No. Ma non perché bisogna fare due ore di coding.

Perché insieme al coding vanno affrontati altri temi. Ci deve essere un piano didattico più esteso che comprenda le competenze di cittadinanza digitale, i nuovi diritti e i doveri “digitali” – la privacy, la condivisione, l’attenzione alle risorse.

E in questo piano devono essere prese in carico (o smontate e rimontate) le altre “materie”, senza le quali il coding perde di senso a scuola. Perché non può essere un’attività ricreativa incastrata tra matematica e storia, ma deve fare i conti con entrambe.

Deve essere rivalutata la componente linguistica del coding, la sua parentela con le altre forme di scrittura. Il coding deve essere affrontato nel quadro di un ripensamento della didattica che prepari non solo alla soluzione di problemi dati, ma anche alla posizione di nuovi problemi, all’invenzione di narrazioni in tutti campi.

Si dovrebbero andare a ristudiare le esperienze passate, valutarle, estrapolarne, se ci sono, gli aspetti positivi.

Deve essere scelto un ambiente e un linguaggio adatto, in funzione dell’età, degli obiettivi, dei dispositivi.

Per tutto questo, si devono formare i docenti in maniera non randomica e superficiale.

Insomma: coding si, ma sul serio.