Stampa

Nella didattica dell'informatica, e forse anche in fase di progettazione di semplici programmi batch, si utilizzano ancora, come strumento ideativo, i flow-chart e questo perché sono più semplici della controparte linguistica, lo pseudocodice.

In effetti il layouting di un algoritmo con i flow-chart ha una grande espressività e permette, a colpo d'occhio, di comprendere un programma di anche 10 blocchi, compresi start e end. Invece il codice scritto in linguaggio di programmazione non consente un paragonabile coup d'œil, se non che per la singola riga, e a volte nemmeno quella (pensiamo a quanto può essere complessa una riga "ben scritta" in C).

Oltre i 10-12 blocchi, però, il flow-chart diventa sempre più (qualcuno direbbe esponenzialmente) complesso tanto che leggerlo richiede uno sforzo non indifferente ad un programmatore esperto, figuriamoci ad uno studente.

I flow-chart nascono con la prima programmazione, negli anni '60, assieme a linguaggi di programmazione, oggi diremmo, di basso livello, e sicuramente anche molto "liberi". Liberi soprattutto di usare qualsiasi strumento per raggiungere il fine preposto: risolvere il problema.

Col tempo ci si è accorti che questo approccio fattivo ma sregolato ha portato alla produzione di software poco manutenibile e tantomeno riusabile fino a disconoscere questo modo di programmare ed etichettarlo come "programmazione a spaghetti" riconoscendo nel GOTO il nemico numero uno. È il gran momento del ritorno alle regole, oppure di crearne di nuove: modulartà, programmazione strutturata, top-down, bottom-up sono alcune delle parole magiche, delle panacee che avrebbero risolto ogni difficoltà, assieme all'esilio definitivo del GOTO.

I nuovi linguaggi di programmazione sono sprovvisti del goto (oppure ce l'hanno, ma nessuno lo reclamizza più di tanto, temendo le infamie del pesiero dominante). Invece i flow-chart restano quello che sono: proni come sempre alla programmazione a spaghetti.

In effetti, se ci pensiamo un attimo, i flow-chart rappresentano in modo perfetto sequenze, salti condizionati e incondizionati. Mancano solo i cicli. E questo perché si possono simulare con salti condizionati e incondizionati. È vero, l'esagono rappresenta il ciclo con numero di ripetizioni predefinito (il for, per intendersi), ma è solo una selezione rimasterizzata, e così anche i cicli precondizionati e postcondizionati.

Cicli non cicli (e sì, quello è un salto incondizionato!)

Semplicemente non c'è un modo per rappresentarli con i blocchi dei flow-chart perché sono istruzioni che ne "avvolgono" altre. In Scratch il concetto è reso in modo splendido (peccato solo che i geni del MIT si siano inventati la ripetizione precondizionata che cicla per falso!):

Nei flow-chart potrebbe funzionare in modo analogo se il corpo della ripetizione fosse fatto da una sola istruzione, ma è un limite ovviamente assurdo.

Se quindi intendiamo utilizzare il flow-chart come strumento didattico per far comprendere un algoritmo, dobbiamo limitare il numero di blocchi e limitarci alle strutture di controllo di sequenza e di selezione a una o due vie: oltre abbiamo la perdita di espressività più la difficoltà dovuta ai limiti di un modello che non ha in sé blocchi altrettanto efficienti per i cicli.

Altra cosa è se si pretende da uno studente il flow-chart come produzione creativa per la risoluzione di un problema: non solo lo studente deve pensare a come risolvere il problema, ma nello stesso momento deve pensare come rappresentarlo in blocchi rispettando i necessari vincoli della programmazione strutturata, ancor di più se sono richiesti dei cicli e, ovviamente, tenendo il tutto sotto un certo numero di blocchi, altrimenti la verifica di correttezza potrebbe essere un altro "problema".

La mia opinione è che i flow-chart vanno usati con cautela, che non si possono pretendere da programmatori inesperti come strumento ideativo e che la scrittura in pseudocodice è molto più espressiva e libera ed essendo uno strumento linguistico, in fase ideativa non pone in sé problemi di rappresentazione delle idee e l'unico problema che si ha di fronte è trovare la soluzione del problema, non "scriverla".

Sitografia:

http://stackoverflow.com/questions/26097082/flowcharts-a-way-of-drawing-gotos