Come (non) funziona un programma

Vi è mai capitato di incontrare dei perfetti idioti che si credono dei portenti di intelligenza? Sicuramente sì… Si tratta di un tema molto generale: noi esseri umani siamo capaci di essere obiettivi su noi stessi e sulla nostra intelligenza? La risposta giusta è: no.

(fonte)

Così si esprime il prof. Puglisi parlando dell'”effetto Dunning/Kruger“, quell'”effetto per cui se sei stupido e/o scarso su un certo tema non sai neanche di esserlo“. Si tratta di un principio non facilmente eludibile in nessun campo del sapere (nemmeno nella teologia) né del fare (nemmeno nella pastorale).

Perciò sono stati inventati i programmi, che, come recita la Treccani, sono enunciazioni particolareggiate “di ciò che si vuole fare, d’una linea di condotta da seguire, degli obiettivi a cui si mira e dei mezzi con sui s’intende raggiungerli“:

programma s. m. [dal lat. tardo programma –mătis, gr. πρόγραμμα -ματος, der. di προγράϕω, propr. «scrivere prima»] (pl. –i). – 1. Enunciazione particolareggiata, verbale o scritta, di ciò che si vuole fare, d’una linea di condotta da seguire, degli obiettivi a cui si mira e dei mezzi con cui s’intende raggiungerli; discorso, scritto, manifesto in cui si espongono le intenzioni, i fini, o si illustrano i principî, le ragioni, i limiti di un’opera o di un complesso di opere, e sim.: p. di lavoro; p. di ricostruzione; p. dei festeggiamenti; il p. d’una cerimonia; p. per un’azione comune; seguire un p.; attenersi al p. fissato (per p. di ricerca, in relazione con la ricerca scientifica, v. ricerca, n. 1 b). Più genericam., ciò che si propone, o che ci si propone di fare: hai qualche p. per domenica?; che p. hai fatto per la serata?; e ora, che cos’hai in p. di fare?; non faccio mai programmi per l’avvenire; non ho nessun p., non ho deciso di fare nessuna cosa determinata, sono quindi completamente disponibile; mettere in programma, prevedere, preordinare: bisognerà mettere in p. una riunione; hanno già messo in p. di partire all’inizio del mese. Essere un p., essere tutto un p., nel linguaggio colloquiale, essere particolarmente indicativo di ciò che accadrà o di come si svolgeranno i fatti, avere in sé indizî tali da lasciar presumere gli avvenimenti futuri (il suo atteggiamento è tutto un p.; mi ha fatto un discorso ch’era tutto un programma).

(fonte)

Ora qui noi ci chiederemo perché un programma (1) non funziona oppure (2) sembra aver funzionato ma no, non funziona (sempre 1). Le ragioni per cui un programma non funziona o, se pure sembra aver funzionato, non funziona lo stesso sono principalmente tre:

1. esecutore stupido
2. assenza di dati
3. errore di progettazione

Se nessuno dice all’esecutore stupido qual è la sequenza di istruzioni (programma) da eseguire per compiere una determinata azione allora si può dire che l’esecutore non sa compiere quell’azione. Quindi se sul foglio di lavoro (la memoria) dell’esecutore non vi è alcun programma, scritto nella lingua dell’esecutore, l’esecutore non è in grado di fare nulla …. E’ TOTALMENTE FERMO !!!!

Cominciamo dall’esecutore stupido. È il caso più comune, assimilabile a quello di un programma informatico: “Se nessuno dice all’esecutore stupido qual è la sequenza di istruzioni (programma) da eseguire per compiere una determinata azione allora si può dire che l’esecutore non sa compiere quell’azione“. Ci sono comunità umane piene di esecutori stupidi, i quali sono tutt’altro che innocui. Perché se nessuno dice loro cosa devono fare, almeno stanno totalmente fermi; ma se qualcuno dà loro un’istruzione sbagliata essi la eseguono senza riflettere, nuocendo potenzialmente a se stessi e agli altri.

In caso di verifica sarà facile, per chi avrebbe dovuto dare un’istruzione e non l’ha data o per chi ha dato un’istruzione sbagliata, gettare la responsabilità del fallimento sull’esecutore stupido. Il quale, a causa dell’effetto Dunning/Kruger sopra richiamato, non solo non è in grado di percepire la propria stupidità ma sarà indotto a ritenersi effettivamente responsabile del fallimento.

Un programma può essere visto come un manipolatore di dati: a fronte di dati in ingresso che descrivono il problema producono dati in uscita come risultato del problema. INPUT (dati) OUTPUT(dati) PROCESSO (istruzioni) Le operazioni sui dati sono le istruzioni. I dati sono gli oggetti su cui vengono eseguite le istruzioni. Tutti i linguaggi di programmazione prevedono un insieme di dati e istruzioni che il programmatore può utilizzare nella realizzazione dei propri programmi.

Tuttavia quello dell’esecutore stupido non è il problema principale. A volte esistono anche esecutori non stupidi; a tutti gli esecutori possono essere persino fornite le istruzioni, ma in assenza di dati in ingresso. E ciò che è peggio, il programma può aver già fissato i risultati attesi in uscita.

Così gli esecutori si trovano in una situazione di conflitto con l’autore del programma: hanno ricevuto le istruzioni però si trovano sprovvisti di dati sui quali applicarle e tuttavia è necessario che producano alcuni effetti. Raramente gli esecutori osservano la mancanza dei dati e se ne lamentano. Qualcuno è costretto ad ammettere di non aver eseguito il programma. Ma di solito, pur di non entrare in conflitto con l’autore del programma, gli esecutori, stupidi o non stupidi, inventano. Inventano quello che l’autore del programma si attende come risultato del programma stesso. Gli esecutori stupidi lo fanno un po’ più convinti che sia la realtà, perché per il solito effetto Dunning/Kruger, non si rendono conto che stanno producendo risultati in uscita senza che vi siano dati in ingresso.

Se qualcuno pensasse che l’assenza di dati in ingresso e l’invenzione dei risultati in uscita sia la cosa peggiore si sbaglierebbe di grosso. C’è una terza ragione per cui un programma non funziona: l’errore di progettazione. Recentemente IKEA ha ritirato dal mercato il tavolo allungabile GLIVARP-bianco smerigliato per il rischio di caduta dell’asse prolunga (fonte). La nota azienda svedese si era accorta che il prodotto aveva alcuni problemi (non invidio il destino del progettista). Immagino che alcuni clienti, prima di protestare, si fossero chiesti inizialmente se non avessero loro commesso qualche errore nel montaggio del prodotto. È piuttosto comune, se uno non fa l’ingegnere di professione, pensare di aver sbagliato qualcosa con i mobili IKEA. Evidentemente, però, le ripetute lamentele dei clienti hanno allarmato l’azienda, che ha ammesso l’errore di progettazione e ha promesso di restituire i soldi a fronte della riconsegna del tavolo anche in assenza di scontrino.

Ma cosa accade se in un programma che riguarda esseri umani e magari i loro valori spirituali (religiosi, politici, sociali…) si trovano errori di progettazione? È altrettanto facile accorgersene? Per il deplorevole effetto Dunning/Kruger no assoluto, in caso di soggetti scarsi sul tema. Ma no ancora di più se l’errore è sistemico, cioè riguarda non solo le istruzioni e il processo del programma, ma anche gli strumenti di valutazione (starati) e l’assenza di un soggetto esterno (al quale telefonare per la revisione e la valutazione).

In altre parole, chi esegue (ma anche chi produce) il programma contenente errori di progettazione è totalmente convinto di aver fatto la cosa giusta e di trovarsi in presenza dei risultati sperati anche se contraddittori o dannosi (o, in assenza dei risultati sperati, è convinto che la colpa sia del malocchio, degli spiriti cattivi, di Soros, dei rettiliani, dei mercati, delle scie kimike, dell’asteroide…), soprattutto se per il combinato disposto dell’effetto Dunning/Kruger e dell’errore sistemico le sue convinzioni sono rafforzate da valutazioni inattendibili senza nessun controllo esterno.

E quando pure in ambito ecclesiale sulla porta dell’appartamento del Papa si trova scritto “vietato lamentarsi” (fonte), allora si può comprendere quanto sia dura la vita degli stessi programmi pastorali.