Porre attenzione agli aspetti problematici

Quando esprimiamo dei concetti, usiamo la categoria che ci sembra “pi`u naturale”: quella che Lakoff [88] chiama “categoria di livello base”. Non diremmo mai “c’`e un mammifero sul tavolo” o “c’`e un soriano sul tavolo” quando il nostro gatto non ci lascia pranzare.

Allo stesso modo, gli studenti nello studio sull’ordinamento di date [38] non si sono soffermati sui tipi di dato o su operazioni di controllo del flusso di esecuzione o su funzioni come l’ordinamento, in quanto le trovavano ovvie o primitive. Cos`ı non `e, e dunque `e necessario, quando si incontrano questi aspetti, porre particolare attenzione durante la loro introduzione, per favorire le migliori concezioni o il superamento di quelle errate.

3.2 Programmazione a portata di mano 69

Alcune fonti di misconcezioni sono intrinseche nel linguaggio, e l’unica cosa che si pu`o fare senza cambiarlo `e evidenziare esplicitamente le differenze tra linguaggio naturale e linguaggio di programmazione. Altre misconcezioni, invece, sono dovute alla mancata comprensione della macchina concettuale o a schemi e modelli mentali errati o assenti: vediamo alcune proposte per affrontarle.

Facilitare la creazione di schemi

Gli studi citati nel Capitolo 2 mettono in evidenza la necessit`a degli stu- denti di formarsi schemi, partendo da quelli pi`u semplici e, gradualmente, passare a schemi pi`u complessi e ad un livello pi`u alto di astrazione. Ritenia- mo quindi importante partire da soluzioni di problemi semplici e ricorrenti (es. “scorrere tutti gli elementi di un array”), dapprima presentati come eser- cizi da risolvere ed esplicitando poi che si tratta di un pattern da utilizzare in seguito quando viene riconosciuto. Uno studio [74] ha testato un linguaggio di programmazione visuale a cui erano state aggiunte delle “meta-istruzioni” per gestire esplicitamente schemi e piani, con la possibilit`a di combinarli, testarli separatamente, raffinarli, ottenendo buoni risultati in un corso introduttivo. Va di contro notato che questo tipo di approccio favorisce uno stile estre- mamente bottom-up, che, secondo gli studi, va in un secondo momento sco- raggiato per favorire un’analisi pi`u astratta e top-down. `E dunque importante non indugiare troppo su questo approccio.

Insegnare a leggere prima di insegnare a scrivere

Cos`ı come ci viene insegnato a leggere nella nostra lingua prima che ci venga insegnato a scrivere, cos`ı dovrebbe essere nella programmazione. A titolo aneddotico: ho visto vari programmatori alle prime armi (sia bam- bini che giovani universitari), bloccati su un bug a loro dire “introvabile”, illuminarsi alla mia richiesta di “spiegarmi cosa fa il programma, riga per riga”.

Nel Capitolo 2 `e stata sottolineata l’importanza di far fare tracing agli studenti da un lato, e la loro scarsa capacit`a e attenzione nei confronti di tale tecnica dall’altro. `E importante prevedere:

• studio di esercizi risolti e commentati (cos`ı da ridurre il carico cognitivo e lasciare spazio all’apprendimento);

• esercizi di completamento, meno noiosi dei precedenti;

• esercizi di debug, come “caccia all’errore”, che necessitino di fare tracing per essere risolti;

• utilizzo dei debugger spesso presenti negli ambienti di sviluppo soft- ware, e poco o per nulla sfruttati dagli studenti.

Chiedere esplicitamente di eseguire mentalmente o di spiegare il funzionamen- to del codice `e anche un buon modo di insegnare agli studenti a ragionare

dal punto di vista del programma, cosa che, come detto, non fanno intui-

tivamente. Risultati concreti si sono visti negli esperimenti sull’efficienza degli algoritmi [100], dove un tracing (persino se errato) portava a notevoli miglioramenti nella comprensione degli stessi.

Fare tracing pu`o aiutare a individuare un errore in una porzione di codice limitata, ma non `e sufficiente come unica attivit`a di debug. Gli studi [127] infatti mostrano come le tecniche per trovare gli errori non siano tra le pi`u intuitive e vadano pertanto insegnate esplicitamente. In particolare:

• “prova a ricompilare” non `e un buon consiglio: il mondo reale in cui viviamo `e aleatorio e ritentare sembra una buona strada, mentre il mondo del computer `e deterministico e dunque questo raramente poter`a a miglioramenti;

• bisogna spiegare esplicitamente che `e necessario disfare ci`o che si `e fatto se il tentativo `e fallito, prima di provare un’altra soluzione, di modo da riportare il sistema a uno stato noto;

3.2 Programmazione a portata di mano 71

• va suggerito esplicitamente di trovare l’errore, prima di correggerlo, insegnando tecniche quali stampe di controllo; anche la comprensio- ne dell’errore `e importante per una corretta correzione (per esempio suggerendo un’analogia col medico che fa esami diagnostici prima di proporre una cura);

• porre l’attenzione sul fatto che le cause di un errore possono essere molte, per esempio sottoponendo gli studenti a esempi ed esercizi con bug causati da fattori diversi.

Esplicitare una macchina concettuale

Come gi`a visto, fare tracing significa “eseguire un modello mentale”. L’im- portanza dei modelli `e evidenziata dalle numerose misconcezioni adducibili a un modello “errato” e ai vantaggi che invece porta conoscerlo esplicitamente. Seguendo i consigli di Ben-Ari [25], si sottolinea l’importanza di insegnare esplicitamente un modello concettuale di una macchina astratta ai novizi, di modo che essi si formino un modello mentale adeguato all’apprendimento della programmazione e in particolare si consiglia di:

• presentare esplicitamente un modello concettuale del computer (es. Macchina di Von Neumann) e di macchina concettuale del linguaggio;

• ritardare gli esercizi di programmazione fino a quando gli studenti non abbiano costruito un modello mentale adatto agli scopi degli esercizi stessi;

• guidare lo studente nel cambiamento dei modelli “sbagliati”.

L’importanza della macchina concettuale `e riconosciuta in letteratura, ma non messa in atto in pratica: per esempio, nei testi introduttivi si parla spesso di Macchina di Von Neumann, ma pochissimi corsi insegnano a comprendere il mondo a runtime di un linguaggio.

Il risultato inatteso dello studio sugli ordinamenti di naturali [128], in cui gli studenti hanno trattato i numeri non come tipo di dato primitivo

ma come sequenze di caratteri, mostra come il loro modello di macchina (gi`a presente, nonostante fossero al primo giorno di corso) sia molto diverso da quello normalmente usato dai linguaggi insegnati. `E perci`o importante guidarli verso un modello in cui i numeri siano oggetti primitivi.

I costruttivisti pi`u estremi, quali Greening, osteggiano l’idea di insegnare esplicitamente la macchina, puntando a un approccio pi`u pratico e immersivo in contesti realistici. Nonostante questo, in letteratura non `e stato trovato nessun supporto a favore di questa ipotesi [134].