Il coding e Molière

Che c’entra Molière col coding? C’entra, c’entra…

Quando ho iniziato il mio laboratorio di creazione di giochi, tutto avrei immaginato tranne di fare una cosa che qualcuno in seguito avrebbe chiamato coding. Eppure, era proprio quello che facevo. Mi ritrovavo, insomma, nella posizione di quel personaggio di Molière, Monsieur Jourdain, al quale il maestro di filosofia rivela che sta parlando in prosa. Perbacco, dice Jourdain, e pensare che è tutta la vita che parlo in prosa, e non lo sapevo.

Ecco, io ho fatto coding per dieci anni e non lo sapevo.

Ora che ho lasciato alle spalle l’impegno attivo, ho la possibilità e l’opportunità di riflettere sulla reale utilità del coding. E vorrei cominciare con l’esprimere un timore che ho sempre avuto: cioè che quella del coding possa essere una attività autoreferenziale.

La maggior parte dei giovani che fanno coding non diventeranno programmatori. Saranno biologi, magazzinieri, insegnanti o qualsiasi professione nuova sarà necessaria negli anni a venire.

In realtà, anche se non sempre si dice chiaramente, il coding ha un obiettivo molto ambizioso: vorrebbe essere un esercizio di metodo, un modo per esercitarsi a pensare in maniera corretta.

Se volessi fare una battuta, direi che il coding aspira ad essere una sorta di latino che insegna a pensare del terzo millenio.

Faccio finta di crederci (le cose, temo, sono sempre più complicate di quel che vorremmo) e mi chiedo allora: quali caratteristiche dovrebbe avere l’attività di coding per assolvere a questo compito, per (concorrere a) formare cioè adeguate strutture di ragionamento? Una decina di anni d’attività di laboratorio mi hanno insegnato che il coding da solo non basta.

Comincerei col fissare lo stato dell’arte, cioè le considerazioni di base sulle quali pare ci sia un accordo universale. Sono condizioni necessarie, si, ma probabilmente non sufficienti.

Il coding, dunque:

  • Deve avere le caratteristiche di una attività laboratoriale. Niente lezioni frontali, per carità.
  • Deve basarsi su un ambiente di sviluppo padroneggiabile rapidamente. L’esperienza ci dice che è opportuno che tale ambiente sia ad interfaccia grafico.
  • Deve consistere in una attività di programmazione inizialmente semplice e via via, gradualmente più complessa. Semplici videogiochi in stile anni ‘80 possono essere un buon modello per tali attività.

Come ambiente di sviluppo, Scratch sembra aver avuto la meglio sul diretto concorrente StarLogoTNG. Staccatissimo, anche per una discutibile politica commerciale, il mio preferito, GameMaker. Altri ambienti come Game Editor o Construct2 non sono mai stati testati per questi obiettivi, e probabilmente a ragione. Quanto al prodotto della Microsoft, Kodu, sospendo il giudizio perché non lo conosco ancora abbastanza. Al momento mi sembra che sia più attento al risultato (è un 3D! )che al processo, ma potrei sbagliarmi.

Tutti questi ambienti di sviluppo hanno, in definitiva, strutture abbastanza simili.

  • la distinzione base è fra oggetti/attori e ambiente;
  • gli oggetti/attori lavorano nella logica del se-allora: se acccade un evento all’oggetto/attore, questi reagisce con un’azione;
  • gli oggetti/attori possono essere ripetuti in più esemplari
  • è possibile fare un oggetto/attore padre, che trasmetterà a una serie di oggetti/attori figli le sue poprietà, in aggiunta alle quali ciascuno potrà averne di proprie.
  • In definitiva, gli oggetti/attori interagiscono fra loro; il giocatore può interagire con loro attraverso tastiera, mouse oppure gamepad.

Fin qui, molto riassuntivamente, lo stato dell’arte; come ho accennato prima, credo che non bastino le caratteristiche su ricordate del coding (laboratorialità, ecc) per renderlo uno strumento formativo.

Nel prossimo post comincerò ad esaminare alcune caratteristiche che a mio avviso questa attività dovrà presentare per potersi dire realmente utile.

Scritto da: Paolo Freschi