Si fa un gran parlare dei Coder Dojo per i giovanissimi (dai 7 anni in poi) e dopo aver esaminato diverse alternative via webcast, ed aver osservato sia quelli organizzati dall’ azienda (i Family day si sprecano) e dalla scuola di mia figlia, sono arrivato a formarmi un opinione. Diciamo che ho una opinione positiva, ma sollevo alcuni problemi, legati ad una visione dell’informatica molto “naif”.
Occorre innanitutto definire un concetto: per come si sta evolvendo l’economia dei servizi e l’economia della produzione, una certa capacita’ di programmare un computer sara’ richiesta a tutti. Quando dico tutti intendo dire che da qui a 20 anni, chi sara’ privo di tali abilita’ sara’ semplicemente un barbone.
Ovviamente l’espressione “programmare un computer” ha una gamma enorme di significati , che vanno dallo sviluppo web allo sviluppo di applicazioni residenti, al padroneggiare linguaggi di macro utili per fare ,c he so io, big data, sino a linguaggi “matematici” come MathLab, Mathematica, etc.
L’abilita’ di programmare un computer, cioe’, la uso nella seguente accezione:
- la capacita’ di definire nei dettagli quantitativi il risultato da ottenere.
- la capacita’ di descrivere e tipare la situazione iniziale ed i dati iniziali.
- la capacita’ di descrivere una serie di operazioni automatiche che portano dalla soluzione iniziale a quella finale.
Questa capacita’ di “programmare un computer” e’ ovviamente una capacita’ che in astratto descrive quello che sinora si e’ chiamato “fasi di lavorazione” in qualsiasi parte dell’industria. Infatti, il mondo dell’industria e’ proprio quello che viene automatizzato di piu’.
Se pero’ pensiamo alla direzione di un’azienda o alla burocrazia, cose come “prendi la domanda X e la porti all’ ufficio Y, poi va all’approvazione all’ufficio Z, infine produce la tale azione dall’ ente K” , e’ un algoritmo a tutti gli effetti, e spesso e’ la descrizione di un “processo” per chi si occupa di ERP.
Possiamo a sua volta descrivere questa attitudine come una specie di “piano di lavorazione”:
- Definire in termini formali il risultato finale.
- Definire in termini formali lo stato iniziale.
- Definire in termini formali una lista di azioni a(1),a(2),….a(n) che passi da llo stato iniziale al risultato finale.
Poi c’e’ un altro lato della programmazione, che non e’ cosi’ astratta, ma e’ la “produzione di software” , ed e’ piu’ specifica. Essa comprende come pre-requisito una abilita’ nel programmare un computer, e poi arrivano tutti i tecnicismi:
- La scelta della piattaforma
- La scelta dell’infrastruttura.
- Il dimensionamento della stessa.
- La definizione dei KPI.
- La definizione degli SLA.
- La scelta del sistema di sviluppo.
- La scrittura dei testbook.
- La scrittura della documentazione.
- La realizzazione del software stesso in un dato linguaggio.
- La gestione dei tempi e del budget del progetto.
- La gestione dei rischi a software in produzione.
- Il lifecycle management (manutenzione, patch, CR, etc).
- Il ciclo di transizione (dismissione del prodotto, migrazione ad altre piattaforme, etc)
- Varie&Eventuali
queste abilita’, che sono implementative, le indichero’ in futuro come “produzione del software”, ovvero il momento in cui la serie di azioni e metodi che avete in mente si trasforma in un programma eseguito in autonomia dalla macchina.
Fatta la distinzione tra “abilita’ nel programmare” e “capacita’ di produrre software”, torniamo al Coder Dojo. Tutti gli esempi che ho visto usavano Scratch, un linguaggio che definirei “macro di automazione” sviluppata appositamente per i bambini.
Nella sua forma meno “scritta”, diciamo adatta per bambini piccoli e/o tablet, esso appare in questo modo:
Le operazioni da far compiere ai personaggi sono descritte dai blocchetti che vengono messi in sequenza.Il personaggio (o piu’ di uno) parte da una posizione iniziale nello scenario, e poi interagisce con gli altri a seconda di una sequenza definita, appunto, dalla sequenza di blocchetti.
Ovviamente, e’ possibile avere anche interfacce piu’ sofisticate per bambini piu’ grandi e capaci di leggere e far di conto , che ricordano di piu’ una descrizione a blocchi dei programmi.
Alla fine , sebbene non si abbiano dei veri e propri programmi, e’ possibile usare questo paradigma per insegnare quella che ho chiamato “abilita’ nel programmare”, ovvero descrivere il risultato voluto a partire dalla situazione iniziale piu’ una serie di passaggi, eseguiti dalla macchina.
Adesso siamo al punto: pensare agli obiettivi da raggiungere in termini di azioni necessarie a raggiungerlo e’ sicuramente l’ ABC della programmazione, cosi’ come e’ l’ ABC del design industriale, ed essenzialmente l’ ABC di qualsiasi cosa sia “fare le cose pensando a come farle”.
Se giudico la questione del Coder Dojo in questi termini, il mio giudizio e’positivISSIMO.
Adesso pero’ andiamo alla differenza tra requisiti ed aspettative.
Se il requisito e’ quello di insegnare ai bambini una mentalita’ capace di prendere un obiettivo, osservare le risorse a disposizione, le azioni possibili e definire il raggiungimento dell’obiettivo, esso e’ stato raggiunto. Ma qual’e’ l’aspettativa che sta dietro a questo requisito?
Se l’aspettativa e’ quella di aver “avvicinato il bambino alla programmazione”, beh, non e’ vero. Non soltanto perche’ era possibile stimolare la stessa forma mentis con dei normalissimi Lego, ma perche’ di fatto non e’ programmazione. Quello che abbiamo fatto e’ aver creato una specie di Lego per computer, e in questo abbiamo avvicinato il bambino al computer, non alla programmazione.
Sia chiaro: non sto dicendo che si dovrebbe insegnare Wirth ai bambini. Come ho detto il mio giudizio e’ positivissimo. Sto solo dicendo che questo stimola un’abilita’ cosi’ generica e visuale che non bisogna aspettarsi che questa abilita’ si traduca necessariamente in una qualche abilita’ informatica.
La stessa abilita’ e’ necessaria al muratore come al manager, dal momento che alla fine si tratta di partire dalle risorse e dalle azioni disponibili per realizzare cio’ che si ha in mente. Anche il piu’ bravo tra i bambini che si metta ad allenarsi con lo Scratch non necessariamente sviluppera’ abilita’ informatiche: potrebbe diventare abilissimo nello scolpire statue, e il tipo di pensiero sarebbe esattamente identico.
Adesso e’ piu’ chiaro cosa intendo quando dico che bisogna distinguere le aspettative dai requisiti: Scratch insegna una mentalita’ generale e visuale per descrivere il processo di passare dallo stato A allo stato B in un mondo deterministico.
Si tratta di un’abilita’ generale, cosi’ generale che non necessariamente “avvicina all’informatica”. Diciamo che, siccome si pratica con un computer, al limite avvicina al computer.
Ed e’ l’aspettativa la parte piu’ criticabile di questa cosa: se io dovessi consigliare Scratch, non lo consiglierei ai bambini che vogliono fare gli informatici: lo consiglierei a tutti, come esercizio di concentrazione. Non e’ un esercizio di informatica quanto non lo siano i Lego: e’ una specie di Lego per computer, in definitiva. Consigliereste i lego per imparare informatica? Di sicuro. E per imparare ad espandere la mente? Di sicuro? A chi? A tutti. Ma poi direste che vostro figlio sara’ un eccellente astronauta solo perche’ coi lego ha costruito un disco volante? NO, ed e’ questo il punto.
La pretesa di specificita’.
La critica che faccio ai Coder Dojo che propongono scratch alle scuole e’ di presentarlo dicendo che questa sia una preparazione all’informatica, o che questo dia ai bambini qualcuna delle capacita’ – cosi’ richieste nel mondo della way newer economy delle startup – che oggi vengono osannate.
La verita’ e’ che si tratta di un esercizio mentale che aggiunge focalizzazione e capacita’ implementativa a qualsiasi bambino voglia fare qualsiasi cosa.
Ma ho parlato di una differenza tra “abilita’ nel programmare” e “produzione del software”. L’ho fatto perche’ vorrei sottolineare una cosa: l’abilita’ nel programmare, sia programmi al computer che procedure per lavorare, e’ necessaria per avere successo al lavoro, ma non sufficiente.
Se dovessi dire che una persona riesce nel lavoro perche’ ha abilita’ nel programmare, direi di no. E’ il minimo richiesto. Ad essere pagate sono le capacita’ specifiche, ovvero la produzione di qualcosa, software compreso.
Il fatto che si chiami “Coder Dojo” e’ scorretto perche’ si lascia trasparire l’illusione che facendo questo il bambino sia sul cammino per diventare un programmatore. Sono palle. E sono palle pericolose perche’
I genitori che vedono un bambino bravo in scratch penseranno che sia destinato a lavorare coi computer. La verita’, stanno solo notando che il bambino sara’ bravo a fare qualsiasi cosa.
Se siete in grado di descrivere con accuratezza la procedura per passare da uno stato iniziale ad uno stato , diciamo, immaginato o progettato, non siete solo ottimi informatici. Siete ottimi qualsiasicosa: e’ un’abilita’ cosi’ generica che potreste usarla con successo in ogni campo. Spingere un bambino verso la programmazione e l’informatica solo perche’ eccelle in scratch e’ insensato.
E quindi, voglio dare la mia opinione, suddivisione tra “pro” e “contro” del Coder Dojo e dello Scratch:
- Pro: allena la mente dei bambini ad una generale abilita’ nell’osservare lo stato iniziale, immaginare il risultato desiderato, e disegnare la sequenza di azioni che serve per ottenere quanto desiderato.
- Contro: insinua nei genitori la convinzione sbagliatissima che il bambino stia acquisendo abilita’ in un preciso settore, l’informatica, quando sta acquisendo una capacita’ utilissima, necessaria, ma estremamente polimorfa.
In parole povere: portate i vostri figli al Coder Dojo e fateli giocare con lo scratch. Ma consideratelo come considerate i Lego: il fatto che ci facciano le casette non ne fa dei futuri architetti.
Ne fa dei personaggi abili a fare da soli le cose che hanno in mente di fare.
Abilita’ che indica sia il vostro idraulico che Alessandro il Grande. “Come” fare le cose e “Cosa fare” sono due concetti che sono assolutamente ortogonali.
