4.Linguaggi per elaboratori e per persone

Il millepiedi era tanto beato
Finchè il rospo burlone gli chiese:
In qual ordine muovi il tuo piede?
Ciò portò la sua mente in tal stato
Che ancor giace in un fosso a pensare
Come avesse mai fatto a camminare.
Anonimo

Usare il calcolo per descrivere giochi di destrezza o come cammina un millepiedi, provocherebbe confusione. Se si tentasse di imparare qualche attività fisica con l'aiuto di tali descrizioni, quasi certamente ci si ritroverebbe nel più vicino fossato, con la testa febbricitante. Questo metodo di descrizione formale non è adatto al compito. Ma esistono altri formalismi. Nel campo della ricerca pedagogica non si è ancora lavorato in questo senso. Ma un'altra comunità di ricerca, quella degli informatici (per ragioni sue proprie), ha dovuto lavorare sul problema dei linguaggi descrittivi diventando quindi una fonte inaspettata d'innovazione educativa. Agli elaboratori si chiede di fare molte cose, e l'ordinare a un elaboratore di fare qualcosa, richiede che il processo sottostante sia descritto, a un certo livello, con sufficiente precisione perché sia eseguito dalla macchina. Così gli informatici (computer scientists) hanno dedicato molto del loro talento e della loro energia allo sviluppo di formalismi descrittivi efficaci. Si potrebbe anche dire che la « scienza degli elaboratori » * sia così chiamata erroneamente: gran parte di essa non è scienza degli elaboratori, ma scienza delle descrizioni e dei linguaggi descrittivi. Alcuni dei formalismi descrittivi prodotti dall'informatica sono esattamente quelli necessari per tenere sotto controllo il processo d'apprendimento di un esercizio fisico. E' quello che qui dimostriamo scegliendo un importante nucleo teorico della programmazione: il concetto di programmazione strutturata, che illustreremo con l'esperienza d'apprendimento, in ambiente LOGO, di un bambino al quinto anno di scuola.
Keith si era dato l'obiettivio di far disegnare all'elaboratore una figura stilizzata, come quella del riquadro rappresentato in fig.10a.
La sua intenzione era di iniziare con un piede e di tracciare le mosse Tartaruga illustrate nella sequenza PER UOMO. Questo modo di procedere gli era dettato da un'immagine familiare della sua cultura preinformatica, avendo imparato a disegnare collegando un punto a un altro, e a descrivere le sue attività passo passo. Gli era dunque del tutto naturale adottare questo metodo. Il compito era facile, anche se noioso (vedi Fig. 10b)

	PER UOMO AVANTI 300 DESTRA 120 AVANTI 300 DESTRA 180 AVANTI 300 SINISTRA 120 AVANTI 300 SINISTRA 120 AVANTI 300 DESTRA 180 AVANTI 300 DESTRA 120 AVANTI 300 DESTRA 180 AVANTI 300 SINISTRA 120 AVANTI 150 SINISTRA 45 AVANTI 50 DESTRA 90 AVANTI 50 DESTRA 90 AVANTI 50 DESTRA 90 AVANTI 50 FINE
Fig.10a Obiettivo
Fig.10c Uomo mancato	Fig.10b

   Ciò che apparve sullo schermo fu l'inaspettato disegno di un « uomo non riuscito » (vedi Fig. 10c). Che cosa non andava? Keith era preparato a sorprese di questo tipo. Il gruppo di concetti connessi a bugs e debugging, l'abbiamo già detto, è uno dei pilastri dell'ambiente LOGO. Non ci si aspetta che tutto funzioni al primo colpo. Non si giudica con i soliti « esatto, hai preso un buon voto » e « sbagliato, hai preso un brutto voto ». Invece, ci si pone la domanda: « Come posso aggiustarlo? », e si deve prima capire che cosa di fatto è successo. Solo allora si potrà farlo riuscire come vogliamo noi. Ma in questa situazione Keith non era capace di stabilire che cosa era successo. Aveva scritto il suo programma in modo tale che era estremamente difficile mettere in evidenza il suo errore. Dov'era, dunque, il bug nel suo programma?Quale errore aveva potuto provocare una trasformazione tanto forte delle sue intenzioni? Per capire la sua difficoltà, confrontiamo il suo programma con una diversa strategia di programmazione, conosciuta come «programmazione strutturata ». Il nostro scopo è di   suddividere il programma in parti semplici, per poter isolare e rettificare gli errori separatamente in ciascuna parte. Mentre nella lunga, informe sequenza di istrúzioni date da Keith, è difficile isolare un bug, lavorando su piccole parti si può più facilmente circoscriverli ed evidenziarli. In questo caso, una suddivisione del tutto naturale consiste nell'elaborare un programma per disegnare un'entità a forma di V da usare per braccia e gambe, un altro programma traccerà il quadrato della testa. Una volta che queste «sottoprocedure» sono state scritte e verificate, è estremamente facile scrivere la « superprocedura » che ci darà la figura stilizzata. Possiamo scrivere un programma molto semplice:

PER UOMO
VI
AVANTI 50
VI
AVANTI 25
TESTA
FINE

PER LINEA :DISTANZA
AVANTI : DISTANZA
INDIETRO :DISTANZA
FINE

Poiché quest'ultima procedura usa soltanto istruzioni LOGO primitive *,
[* Si dicono primitivi i comandi che fanno parte del linguaggio di     elaboratore usato, in questo caso appunto il linguaggio LOGO. ]
funzionerà senza ulteriori definizioni. Per completare il programma UOMO, bisogna definire TESTA:

PER TESTA
DESTRA 45
QUADRATO 20
FINE   

Robert, un allievo al settimo anno di scuola, espresse la sua conversione a questo stile di programmazione esclamando: « Vedete, tutte le mie procedure sono bocconi a misura di mente». Ha poi ampliato la metafora con altri commenti:     «Prima ero solito confondermi con i miei programmi, ora non mordo più di quel che posso masticare». Aveva fatto, una scoperta fondamentale: si può costruire un vasto sistema intellettuale senza fare mai un passo che non sia stato ben compreso. E nello stesso tempo, il costruire con una struttura gerarchica permette di impossessarsi del sistema nel suo insieme, vale a dire di vedere il sistema come se fosse   «guardato dall'alto ».    A Keith, l'autore del programma non strutturato UOMO, era stata suggerita l'idea di utilizzare sottoprocedure, ma lui vi aveva opposto resistenza. La forma di programma lineare era più vicina al suo modo di fare le cose.  Egli non aveva mai sentito un bisogno impellente di programmazione strutturata fino al giorno in cui non poté mettere a punto il     suo programma UOMO. Nelle esperienze LOGO ciò è accaduto spesso. Quando un bambino si trova in situazioni simili e chiede che cosa deve fare, di solito è sufficiente dire: «Tu sai che cosa fare! ». E spesso il bambino dirà, talvolta trionfante, talvolta timido: « Penso che dovrei trasformarlo in sottoprocedure, vero? ». Il « modo giusto» non fu imposto a Keith; l'elaboratore gli offrì sufficiente elasticità e potenza perché le sue ricerche fossero naturali e personali. Questi due stili di approccio alla preparazione ed esecuzione di un progetto si possono applicare a qualunque situazione. Possiamo ritrovarli osservando gli stili di apprendimento sia di abilità «fisiche» che «intellettuali». Consideriamo, per esempio, due allievi del quinto anno di scuola che si esercitavano, nel nostro laboratorio, in attività sia di programmazione che fisiche.

Michael è robusto, atletico, si considera «un duro ». Paul è introverso, studioso, di costituzione fisica esile. Michael è mediocre a scuola e Paul è bravo. Cosi, nessuno era sorpreso quando Paul migliorava velocemente nel lavoro all'elaboratore, avventurandosi in procedure di programmazione strutturata molto complesse. Dopo molte settimane, Michael era solo capace di scrivere programmi lineari. Senza alcun dubbio possedeva tutti i concetti necessari per scrivere programmi più elaborati, ma era trattenuto da una forte e tipica resistenza nell'utilizzare sottoprocedure.

In questo stesso periodo tutti e due cominciarono a imparare a camminare sui trampoli. La tattica di Michael era di fissare nella sua mente un modello in forma sequenziale: a Un piede sulla sbarra, mi alzo, un piede sull'altra sbarra, il primo piede avanti... ». II primo tentativo sfociò in una rapida caduta, ma con coraggio Michael ricominciò una volta due volte e cosl via, fiducioso che finalmente ci sarebbe riuscito, e cosl accadde. Ma, con sorpresa di tutti e due, Paul c'era riuscito prima.

La tattica di Paul era stata diversa. Aveva iniziato allo stesso modo, ma quando si era accorto che non faceva progressi, aveva cercato di isolare e correggere quella parte del metodo che gli procurava noie: il bug. Quando si avanza il piede per effettuare il primo passo, si tende a lasciare il trampolo dietro. Una volta identificato questo errore, non è difficile eliminarlo. Un espediente per arrivarvi sta nel pensare di fare il passo con il trampolo, invece che con il piede, e di lasciare che il trampolo a porti » il piede. Ciò si ottiene sollevando il trampolo col braccio contro il piede. L'analogia col suo approccio alla programmazione fu cosl evidente a Paul, che può essere stata una causa del «transfert» dalla programmazione all'apprendimento di questa attività fisica. In realtà è più probabile che tutte e due le situazioni derivassero da caratteristiche latenti nel suo generale atteggiamento cognitivo. Ma l'esperienza con LOGO rese Paul capace di articolare questi aspetti del suo atteggiamento. Nel caso di Michael, il rapporto tra la programmazione e l'allenamento con trampoli era ancora più evidente. Fu solo attraverso questa analogia che arrivò a riconoscere esplicitamente la differenza tra il suo metodo e quello di Paul. In altre parole, l'esperienza acquisita con la programmazione aiutò i due ragazzi a comprendere meglio le proprie azioni e ad avere un'opinione più articolata di se stessi.

La validità generale dell'idea di programmazione strutturata presa come principio matetico, vale a dire come aiuto all'apprendimento, sarà ancora più evidente attraverso il prossimo esempio: si tratta del processo d'apprendimento di un'altra attività fisica, i giochi di destrezza. Non è un caso se lo scegliamo. Il cerchio Tartaruga si prestava all'apprendimento della matematica «col proprio corpo »; i giochi di destrezza si prestano altrettanto bene ad imparare un'attività corporea «con la matematica ». Naturalmente il quadro reale è complesso e più interessante, perché in ambedue i casi il processo opera in due direzioni, dalla metafora informatica al linguaggio corporeo e viceversa. Sperimentando la geometria della Tartaruga, i bambini affinano il senso che hanno dei loro corpi e dei loro movimenti, nonché la loro comprensione della geometria formale. I concetti teorici relativi ai programmi strutturali, tradotti in termini di giochi di destrezza, in termini realmente corporei, acquistano nuova concretezza ed efficacia. Nell'uno e nell'altro caso, la conoscenza assume la qualità che noi abbiamo chiamato «sintonica».

Ci sono molti tipi di giochi di destrezza. Quando si pensa al giocoliere ci si riferisce a uno che compie esercizi di destrezza secondo una procedura detta « a pioggia ». In questo tipo di gioco, le palle si muovono una dietro l'altra in cerchio, passando da sinistra a destra in alto e da destra a sinistra in basso (o viceversa). Questo comporta due tipi di lanci: un lancio corto e basso, per far passare le palle da una mano all'altra nella parte bassa del cerchio (vicino alle mani), e uno lungo e alto, per far ruotare le palle seguendo la parte alta del cerchio (vedi Fig. 11).

Il gioco «a cascata» ha una struttura più semplice. La parte inferiore del cerchio è assente; le palle circolano nelle due direzioni lungo l'arco superiore. Non c'è che un tipo di lancio: lungo e alto (vedi Fig. 11). La sua semplicità lo rende il migliore esercizio d'avviamento per l'apprendista giocoliere e nello stesso tempo l'esempio migliore per il nostro proposito. La domanda da porci è la seguente: chi vuole imparare il gioco troverà un aiuto o un ostacolo nella descrizione verbale e analitica di come farlo? La risposta è:

Fig11a - Pioggia	Fig11b - Cascata

dipende. Dipende dagli strumenti di cui dispone l'apprendista giocoliere per fare descrizioni analitiche. Noi utilizziamo il gioco a cascata per dimostrare come dei buoni modelli per elaboratori possano aiutare a sviluppare «procedure umane» che migliorino delle prestazioni fisiche e come la riflessione su queste procedure possa aiutarci ad imparare a programmare e fare matematica. Ma è pur vero che certe descrizioni verbali rischiano di confondere invece di essere utili. Consideriamo, per esempioa la descrizione seguente:

1. Cominciare col mettere le palle 1 e 2 nella mano sinistra e la palla 3 nella mano destra.

2. Lanciare la palla 1 verso la mano destra, facendole descrivere una parabola alta.

3. Quando la palla 1 è al vertice, lanciare la palla 3 verso la mano sinistra facendole descrivere una parabola similare, ma fare attenzione a lanciare la palla 3 sotto la traiettoria della palla 1.

4. Quando la palla 1 arriva nella mano destra e la palla 3 è al vertice, afferrare la palla 1 e lanciare la palla 2 in modo che passi sotto la traiettoria della palla 3. e così via...

Questa descrizione è sostanzialmente un brutale programma lineare. Non può essere di alcun aiuto ad un apprendista giocoliere. Le persone estranee alla cultura informatica potrebbero trovarlo molto simile a un programma d'elaboratore: «proprio un'istruzione dopo l'altra ». Ricorda certi programmi, come quello del primo UOMO di Keith. Ma abbiamo visto che allineare le istruzioni senza dar loro una valida struttura interna non è neppure un buon metodo di programmazione, e constateremo che le tecniche di programmazione strutturata che sono davvero efficaci Per scrivere programmi, lo sono anche come descrizioni matetiche del gioco di destrezza.
Il nostro scopo è di inventare una procedura umana: PER GIOCOLIERE. Il primo passo nella definizione di questa procedura consiste nell'identificare e designare le sottoprocedure che avranno la stessa funzione di quelle usate da Keith nel disegnare la sua figura stilizzata (PER VI,PER TESTA, PER LINEA) Nel caso del nostro gioco si tratta di due normali sottoprocedure che indichiamo con LANCIO DESTRA e LANCIOSINTSTRA. Come l'istruzione VI era definita operativamente dal fatto che faceva tracciare all'elaboratore sullo schermo una certa figura a forma di V, così l'istruzione LANCIOSINISTRA data al nostro apprendista giocoliere dovrebbe fargli lanciare, in direzione della mano destra, una palla che presupponiamo egli abbia nella sua mano sinistra.
Ma c'è un'importante differenza tra il programma PER UOMO e il programma PER GIOCOLIERE: nel programn PER UOMO il programmatore non doveva preoccuparsi d fattore tempo, mentre nell'elaborare la procedura per il gioco si deve tenerne conto. Il giocoliere deve eseguire le azioni LANCIODESTRA e LANCIOSINISTRA in momenti precisi di un ciclo, e le due azioni dovranno sincronizzarsi. Avendo scelto di includere la fase di presa della palla nella stessa sottoprocedura del lancio, si intende che la procedura LANCIODESTRA debba includere la ricezione del palla quando raggiunge la mano sinistra. Similmente, LANCIOSINISTRA è un'istruzione per lanciare una palla dalla mano sinistra verso la destra e prenderla quando arriva.3
Essendo la maggior parte delle persone capace di esegui queste azioni, considereremo le due istruzioni LANCIODESTRA e LANCIOSINISTRA come acquisite, per concentrare la nostra attenzione sul modo di combinarle, al fine «ottenere una nuova procedura che designeremo PER GIOCOLIERE. Questa combinazione differisce in un punto essenziale da quella delle sottoprocedure PER VI e PER TESTA che formava la procedura PER UOMO: bisogna la procedura LANCIOSINISTRA sia iniziata prima che l'azione avviata dalla precedente LANCIODESTRA sia completata. Nel linguaggio dell'informatica, si parla in quesl caso di processi paralleli in opposizione ai processi seriali utilizzati per tracciare la figura stilizzata.
Per descrivere la combinazione delle sottoprocedure introduciamo un nuovo elemento di programmazione: il concettodi «QUANDO MAGO ». Spieghiamolo, considerando l'istruzione QUANDO AFFAMATO MANGIA. Tradotta dal LOGO in linguaggio chiaro, questa istruzione significa: ogni volta che si verifica la condizione AFFAMATO esegui l'azione MANGIA. La metafora del mago esprime l'idea che l'istruzione crea un'entità autonoma nel sistema dell'elaboratore, tale che se ne resta addormentata finché non accade un certo tipo di evento, e allora, come un mago, salta fuori a compiere la sua azione. Si ottiene il gioco con due QUANDO MAGO.

Le definizioni da introdurre saranno del tipo seguente:

QUANDO qualcosa LANCIODESTRA
QUANDO qualcosa LANCIOSINISTRA ¶

Per riempire gli spazi non definiti, i « qualcosa », dobbiamo descrivere due condizioni, o due « stati » identificabili del sistema, che daranno il via all'azione del lanciare.
In un momento chiave del ciclo, le palle sono disposte pressappoco così (Fig.12): ¶

Mano sinistra   Fig.12      Mano destra	Fig.13a
Fig.13b - ALTODESTRA: la palla è in alto e si dirige verso destra	Fig.13c - ALTOSINISTRA: la palla è in alto e si dirige verso sinistra

Ma questa rappresentazione dello stato del sistema è incompleta: non indica in quale direzione si muove la palla in alto. Per completarla, aggiungiamo una freccia che indichi una direzione (Fig. 13a) e otteniamo due descrizioni di stato (Figg. 13b e 13c).
Se supponiamo, ragionevolmente, che il giocoliere sia capace di identificare queste due situazioni, il formalismo seguente non dovrebbe necessitare di alcuna spiegazione:

PER GIOCO_CONTINUO
QUANDO ALTODESTRA LANCIODESTRA
QUANDO ALTOSINISTRA LANCIOSINISTRA

o ancora più semplicemente:

PER GIOCO_CONTINUO
QUANDO ALTOX  LANCIOX
e significa che quando si verifica lo stato ALTODESTRA, deve lanciare la mano destra, e quando si tratta di ALTOSINISTRA, è la volta della mano sinistra. Una breve riflessione ci permetterà di provare che questa è una descrizione completa: il processo del gioco continuerà all'infinito poiché ogni lancio crea uno stato del sistema che induce il lancio successivo.
Come può questo modello, che ha tradotto il gioco di destrezza in una procedura umana, essere convertito in una strategia didattica? Prima di tutto bisogna notare che questo modello sottintende che siano realizzate diverse ipotesi:
1. che l'apprendista sappia eseguire le istruzioni LANCIODESTRA e LANCIOSINISTRA;
2. che egli sappia identificare gli stati-segnale ALTOSINISTRA e ALTODESTRA;
3. che egli possa combinare queste abilità d'esecuzione secondo le definizioni della procedura PER GIOCO_CONTINUO

Ora trasferiamo in una strategia didattica le nostre ipotesi e la nostra procedura umana.

FASE 1: Verificare che l'apprendista giocoliere sia in grado di lanciare. Gli si dia una palla, gli si chieda di lanciarla nell'altra mano. In generale questo avviene facilmente, ma vedremo in seguito che spesso occorre rifinire, seppure di poco, il procedimento spontaneo, che comporta un bug.

FASE 2: Verificare che l'apprendista sappia combinare i lanci Provare con due palle, dando per istruzioni:

PER INCROCIO
LANCIOSINISTRA
QUANDO ALTODESTRA LANCIODESTRA
FINE

Lo scopo è di scambiare le palle tra mano sinistra e mano destra. Benché sembri una semplice combinazione di LANCIOSINISTRA e LANCIODESTRA, ciò non avviene quasi mai immediatamente

Fase 3:Cercare i bugs nelle procedure di lancio. Perché PER INCROCIO non riesce? Normalmente ci si accorge che l'apprendista non sa lanciare cosl bene come sembrava nella fase 1. La difficoltà (bug) più comune deriva dal fatto che l'apprendista segue la palla con gli occhi, nel lanciarla. Poiché abbiamo solo un paio d'occhi, il primo lancio li impegna a tal punto da rendere il secondo quasi impossibile e di solito le palle finiscono disastrosamente a terra.

Fase 4: Operazione di debugging. Se il bug consiste nel seguire la prima palla con gli occhi, vi si ovvia riportando l'apprendista a lanciare una sola palla senza guardarla. La maggior parte dei debuttanti scopre (con grande sorpresa) che basta poco esercizio per essere capaci di edattare un lancio, se si fissa lo sguardo attorno al previsto apice della parabola descritta dalla palla in movimento. Quando il lancio singolo è stato perfezionato, l'apprendista prova di nuovo a combinare i due lanci. Molto spesso la cosa ora funziona, sebbene possa esserci ancora un altro errore da eliminare.

Fase 5:Si passa a tre palle. Una volta che l'apprendista giocoliere sa eseguire senza difficoltà la procedura che abbiamo chiamato INCROCIARE, si può affrontare questo stadio. Cominciare con due palle in una mano e una nell'altra (Fig. 14).

Fig.14

La palla 2 è lanciata come se si stesse eseguendo INCROCIO, ignorando la palla 1. Il LANCIODESTRA di INCROCIARE mette le tre palle nella condizione voluta per passare a GIOCO CONTINUO la transizione da INCROCIO a GIOCO CONTINUO presenta qualche problema per alcuni apprendisti, facilmente superabile. Quasi tutti possono diventare bravi giocolieri in meno di mezz'ora, seguendo questa strategia.

Varianti di questa strategia didattica sono state utilizzate da molti insegnanti LOGO. Uno di loro, Howard Austin, le ha studiate in modo particolareggiato e ha fatto oggetto della sua tesi di dottorato l'analisi di questo gioco. Non ci sono dubbi che la strategia sia molto efficace e c'è poco da dubitare anche riguardo al motivo: L'uso dei concetti della programmazione come linguaggio descrittivo facilita la ricerca e l'eliminazione degli errori (debugging).

Nel descrivere il disegno di una figura stilizzata e l'apprendimento del gioco di destrezza, il nostro tema centrale era che il debugging è facilitato da una descrizione appropriata dei procedimenti complessi. Nei due casi, la descrizione riflette una rappresentazione del processo in una forma modulare, vale a dire frazionata in unità del tutto naturali e funzionali e la caccia al bug diventa agevole, avendolo circoscritto entro singoli passaggi semplificati al massimo. Le peggiori condizioni di caccia all'errore si hanno quando molti bugs si presentano contemporaneamente: conviene che le unita modulari siano tanto ridotte da rendere improbabile che questo si verifichi.

Le difficoltà causate da bugs molteplici sono ben illustrate da quello che accade ai principianti quando cercano di imparare un gioco di destrezza affrontandolo brutalmente. In effetti spesso ci riescono (come Michael era riuscito a camminare sui trampoli), generalmente dopo ore di tentativi frustranti per mantenere tre palle in aria senza essere neppure capaci di farne incrociare due. Ma ci mettono molto tempo per imparare. Quando Howard Austin studiò più da vicino le azioni del principiante, notò gli stessi bugs che abbiamo rilevato nella nostra strategia razionale, per esempio, quello che consiste nel seguire la palla con gli occhi. A forza di ripetizioni, il cosiddetto «apprendimento per tentativi ed errori», finiva col produrre un comportamento efficace. Per puro caso, durante un lancio capiterà che gli occhi si muovano un po' meno. Gli esseri umani, come altri animali, sono dotati di meccanismi d'apprendimento capaci di captare questi momenti e di accrescere la probabilità che si ripetano. Infine, gli errori sono eliminati e il soggetto impara il gioco di destrezza. Le persone sono capaci di imparare allo stesso modo dei topi in un labirinto. Ma il processo è lento e primitivo. Possiamo imparare di più, e più in fretta, se acquisiamo un controllo consapevole del processo d'apprendimento, articolando e analizzando il nostro comportamento.

Se le procedure di tipo informatico migliorano l'apprendimento, non ne consegue che si possano sopprimere, come per magia, tutti i processi ripetitivi che ogni acquisizione esige o che si possa ridurre a quasi niente il tempo necessario per imparare i giochi di destrezza. Ci vuole tempo per trovare i bugs ed eliminarli, come per raggiungere le diverse abilità necessarie. Ciò che si potrà eliminare, invece, sono i metodi dispendiosi e inefficienti. Quando il metodo d'apprendimento è povero, bisogna esercitarsi per ore ed ore prima di saper giocare con tre palle correttamente. Quando è buono, il tempo è di gran lunga ridotto: spesso sono sufficienti venti o trenta minuti.

I bambini, molte volte, oppongono una resistenza alla ricerca degli errori analoga a quella che abbiamo riscontrato per le sottoprocedure. L'ho osservato durante i primi incontri di bambini con l'ambiente LOGO. Il bambino decide di far tracciare alla Tartaruga una certa figura, per esempio una casa o un uomo stilizzato. Un programma è presto scritto e provato. Non funziona. Invece di essere corretto, viene cancellato. Talvolta l'intero progetto è abbandonato. In altri casi, il bambino s'intestardisce, prova, riprova e riprova con ammirevole costanza, ma sempre ripartendo da zero, nelI'evidente tentativo di riuscire di un sol colpo. Il bambino può fallire o riuscire a far disegnare la figura all'elaboratore, ma non è certo riuscito ad acquisire la strategia di correzione (debugging).

È ben comprensibile. L'etica scolastica se n'è lavata le mani. Ciò che noi riteniamo un buon programma con un piccolo bug, il bambino lo considera come « sbagliato », «cattivo» «nullo». La scuola insegna che gli errori sono male; l'ultima cosa che uno desidera è di andarli a cercare, di soffermarcisi o di pensarci su. Il bambino è felice di utilizzare l'opportunità che gli offre l'elaboratore di cancellarli senza che ne resti traccia per lo sguardo altrui. La filosofia del debugging suggerisce un atteggiamento opposto. Gli errori ci aiutano perché ci guidano a studiare ciò che è accaduto, a capire che cosa non andava e, attraverso la comprensione, a sistemare le cose. L'esperienza della programmazione, più di qualsiasi altra attività, porta i bambini a «credere » in questa filosofia. Il contatto con l'ambiente LOGO smuove gradualmente le tenaci resistenze a operare correzioni e a servirsi di sottoprocedure. Alcune persone che osservano la crescente tolleranza dei bambini per i loro « errori », attribuiscono la trasformazione d'atteggiamento agli insegnanti LOGO che sono pragmatici e possibilisti davanti ai programmi che i bambini considerano « sbagliati ». Io penso che, a ben vedere, c'è qualcosa di più sostanziale ancora. Nell'ambiente LOGO, i bambini imparano che anche l'insegnante è un allievo e che ciascuno di noi apprende dagli errori. ¶

Un gruppo di dodici allievi del quinto anno lavorava all' esperienza LOGO per molte ore alla settimana, dall'inizio del semestre di settembre. Ai primi di dicembre, il gruppo decise di lanciarsi in un progetto collettivo. Una Tartaruga meccanica sarebbe stata programmata per scrivere  «Buon Natale» su delle immense bandiere di carta da appendere nei corridoi della scuola. Un progetto ideale. Le lettere dell'alfabeto furono divise tra i membri del gruppo. Ognuno doveva scrivere programmi per due o tre lettere, per disegni decorativi e per messaggi interi, utilizzando i programmi lettera come sottoprocedure.

Ma tempeste di neve e altri inconvenienti ritardarono il lavoro; così arrivò l'ultima settimana di scuola e le bandiere non erano ancora state preparate. L'istruttrice responsabile del gruppo decise di infrangere le regole abituali e di preparare lei stessa parte della programmazione. Lavorò a casa senza Tartaruga e quando arrivò il giorno dopo, aveva una collezione di programmi da correggere: lei e i bambini avrebbero lavorato insieme. L'istruttrice e un bambino, seduti per terra, guardavano la Tartaruga che stava disegnando qualcosa che doveva essere la lettera R, ma la battuta obliqua era messa fuori posto. Dov'era la causa dell'errore? Mentre tutti e due cercavano di riflettere. il bambino ebbe una rivelazione: « Ma allora » disse a tu non sai davvero come correggerlo? ». Il bambino non sapeva ancora come dirlo, ma quello che lo stupiva era che sia lui che la sua insegnante si erano impegnati insieme in un progetto di ricerca.

Questo aneddoto fa riflettere. Ci fa pensare a tutte le occasioni in cui questo bambino si è sentito dire dal maestro « facciamolo insieme », ben sapendo che la collaborazione era finta. La scoperta non può essere un gioco truccato; I'invenzione non può essere preordinata.

Nelle scuole tradizionali, gli insegnanti cercano veramente di lavorare in collaborazione con i bambini, ma di solito è la materia stessa che non genera problemi di ricerca. Un adulto e un bambino possono collaborare in modo genuino sull'aritmetica della scuola elementare? Una caratteristica molto importante del lavoro con l'elaboratore è che l'insegnante e l'allievo possono essere coinvolti in una vera collaborazione intellettuale; insieme possono tentare di far fare all'elaboratore questo o quello e di capire ciò che esso sta facendo. Si presentano spesso situazioni nuove che né l'insegnante né il bambino avevano incontrato prima, cosicché l'insegnante non deve fingere di non sapere. Condividere il problema e l'esperienza della sua soluzione permette al bambino di imparare dall'adulto non « facendo quello che il maestro dice », ma « facendo quello che il maestro fa ». E una delle cose che il maestro fa è di ostinarsi su un problema fino ad averlo interamente compreso. L'ambiente LOGO ha di speciale che può fornire numerosi problemi che i bambini di scuola elementare riescono a comprendere con una completezza che è rara nella vita quotidiana. Per approfondire questo punto, può essere utile riesaminare i semplici esempi di ricerca d'errori già discussi.

Abbiamo visto il programma:

PER CASA
QUADRATO
TRIANGOLO
FINE

PER QUADRATO
RIPETI 4
    AVANTI  100
    DESTRA 90
FINE

PER TRIANGOLO
RIPETI 3
    AVANTI  100
    DESTRA 120
FINE

Ma questo programma contiene un bug e traccia il triangolo dentro il quadrato anziché sopra. Perché? Sulle prime, a un bambino potrebbe sembrare un mistero. Ma si può immaginare « perché la Tartaruga ha fatto questa sciocchezza » seguendo il consiglio euristico ben noto: gioca alla Tartaruga. Fallo da te, ma fingi di essere sciocco come lei. Scoprire perché la Tartaruga ha fatto così, suggerisce quasi immediatamente una soluzione. Alcuni, per esempio, dicono: «La Tartaruga ha girato dentro il quadrato perché TRIANGOLO dice GIRA DESTRA». Un rimedio semplice (uno dei tanti possibili) è implicito in questa diagnosi: stabilire una procedura per il triangolo con rotazioni a sinistra.

Ugualmente un adulto che pensasse di poter far tracciare alla Tartaruga un triangolo con RIPETI [AVANTI 100 DESTRA 60], avrebbe la sorpresa di veder apparire un esagono. Ma è possibile « entrare » nel programma e scoprire perché questo avviene. Inoltre, si può riflettere e scoprire che lterrore deriva da una comprensione molto superficiale del più comune enunciato del teorema d'Euclide sui triangoli: « la somma degli angoli di un triangolo è 180 gradi ».

Il bambino (e senza dubbio anche la maggior parte degli adulti), vive in un mondo in cui ogni cosa è capita soltanto in parte: abbastanza bene forse, ma mai completamente. Per molti, è un'esperienza rara, forse unica, comprendere l'azione della Tartaruga tanto a fondo che non ci sia più nulla da dire in proposito. Per alcuni è un'esperienza esaltante: lo si vede dall'ardore con cui i bambini spiegano quanto hanno compreso. È per tutti un esempio chiarificante di conoscenza analitica, migliore di quello che la maggioranza della gente potrà mai incontrare.

Il lettore potrebbe obiettare che, lungi dal comprendere tutto della Tartaruga, un bambino programmatore difficilmente capisce i complessi meccanismi all'opera dietro le quinte, ogniqualvolta una Tartaruga esegue un comando LOGO. Infatti, non rischiamo di ingannare i bambini ponendoli in un ambiente di tecnologia sofisticata, le cui complessità sono solo parzialmente comprese dagli specialisti d'informatica?

Tali dubbi ci riconducono direttamente alle problematiche iniziali di questo capitolo. Io ho proposto, a titolo di esempio, una descrizione del gioco di destrezza nella forma di un semplice programma. Ma sorge la stessa perplessità: la descrizione in linguaggio procedurale coglie l'essenza dell'azione del giocoliere, oppure è una mistificazione che ne dissimula la complessità?

Questi interrogativi sono universali e toccano istanze fondamentali del metodo scientifico. Newton « capì » I'universo riducendo tutti i pianeti a punti che si muovono secondo un insieme invariabile di leggi del moto. Così facendo, egli coglieva l'essenza del mondo reale, oppure ne minimizzava le complessità? In parte, essere capace di pensiero scientifico significa avere una comprensione intuitiva di tali questioni epistemologiche e credo che il lavoro con la Tartaruga fornisca ai bambini l'opportunità di venirne a conoscenza.

In realtà i bambini capiscono subito che la Tartaruga definisce un universo chiuso, in cui certe questioni sono pertinenti e altre no. Nel capitolo seguente parlerò di come quest'idea possa essere sviluppata grazie alla costruzione di molti altri « microcosmi », ciascuno con le sue ipotesi e le sue restrizioni. I bambini giungono ad apprezzare l'esplorazione delle proprietà di un dato microcosmo, senza essere disturbati da questioni estranee; in tal modo imparano a trasferire gli abituali atteggiamenti di esplorazione dalla propria vita quotidiana all'ambito formale dell'elaborazione di teorie scientifiche. L'intelligibilità interna dei mondi informatici offre ai bambini la possibilità di realizzare progetti di una complessità maggiore di quella normalmente possibile nel mondo fisico. Molti bambini immaginano di poter edificare complesse strutture con un gioco di costruzioni, oppure fantasticano di organizzare un gruppo di amici per grandiose imprese, ma quando tentano di realizzare i loro progetti, ben presto si scontrano con i limiti imperscrutabili delle cose e delle persone. Proprio perché i programmi d'elaboratore, per principio, possono essere fatti agire esattamente come nelle intenzioni, è possibile combinarli con maggiore soddisfazionc in sistemi complessi. Perciò i bambini sono in grado di sentirsi a loro agio nella complessità. La scienza moderna e l'ingegneria ci hanno dato l'opportunità di realizzare progetti con un grado di complessità fino a ieri difficilmente immaginabile. Ma la scienza ci insegna anche il potere della semplicità e io termino il capitolo con la storia, a mio parere commovente, di una bambina che ha imparato qualcosa del genere, in un'esperienza particolarmente semplice ma personalmente importante.

Deborah era al sesto anno e aveva dei problemi a scuola; fu introdotta nel mondo delle Tartarughe da schermo, e le fu mostrato come esse ubbidivano ai comandi AVANTI, SINISTRA e DESTRA. Molti bambini trovano una piacevolissima fonte di potere e uno stimolante campo di esplorazione il fatto che a questi comandi si possa abbinare qualsiasi numero. Deborah lo trovò terrificante: la stessa reazione che aveva per la maggior parte delle attività scolastiche. Nelle sue primissime ore di lavoro con la Tartaruga, mostrò un'assillante dipendenza dall'istruttore, chiedendo costantemente rassicurazioni prima di intraprendere il più piccolo passo esplorativo. Si ebbe una svolta quando Deborah decise di limitare i suoi comandi, creando un microcosmo nel microcosmo dei comandi Tartaruga. Si permise solo un comando di rotazione: DESTRA 30. Per far girare la Tartaruga di 90 gradi, doveva ripetere tre volte DESTRA 30 e doveva ripeterlo undici volte per ottenere l'effetto di SINISTRA 30. A un osservatore poteva sembrare noioso ottenere degli effetti tanto semplici in un modo cosl complicato; ma Deborah era entusiasta di riuscire a costruire il suo personale microcosmo e a scoprire tutto quello che poteva fare entro le sue rigide limitazioni. Non chiese più conferme per provare. E un giorno, quando l'insegnante si offrì di mostrarle un « modo più semplice » per raggiungere un risultato, lei ascoltò pazientemente e disse: « Non credo che farò così ». Ne venne fuori quando fu pronta, molte settimane dopo, con un nuovo senso di fiducia che esibì non solo in più ambiziosi progetti Tartaruga, ma anche nell'affrontare qualsiasi altra cosa a scuola. Mi piace vedere nell'esperienza di Deborah un piccolo riassunto del processo storico avviato da pensatori come Copernico e Galileo, che ha permesso agli uomini di affrancarsi da superstizioni che nulla avevano a che fare con la fisica. In entrambi i casi, nella storia personale di Deborah e nella storia del pensiero occidentale, il successo di una teoria matematica non ha semplicemente avuto una funzione strumentale: esso è stato un'affermazione del potere delle idee e del potere della mente.