RACCONTO

I miei precedenti articoli sull’argomento hanno provocato due tipi di reazione.

La prima, quella che mi ha dato qualche soddisfazione, ed ha evitato di farmi sentire un cialtrone (termine usato in altro contesto), è stata di sorpresa e, insieme, riconoscenza, per aver svelato l’esistenza e i rischi di una funzionalità sconosciuta ai più, e in alcuni casi aver spiegato “misteri” in cui alcuni lettori erano incappati. Una nota purtroppo presente in molte risposte, quella di rassegnazione: il computer, ed il web in particolare, non sono tanto visti come preziosi strumenti di lavoro e/o di divertimento, ma come minacce delle quali non possiamo né liberarci né fare a meno. Efficace il paragone con il coltello ben affilato, indispensabile per affettare il pane, ma comunque sempre lì pronto a tagliarti la gola.

La seconda reazione è stata, all’opposto, quella di sorpresa, sì, comunque, ma per aver trattato una “funzionalità veramente comoda come un bug o un inganno per colpa di gente ignorante che non sa usare il browser”, e di aver presentato la cosa come una grande scoperta, mentre pare sia perfettamente descritta nelle istruzioni e nel contratto d’uso del browser (che tutti leggiamo, vero?).

Non ho verificato, non ne ho nessuna voglia, ma credo al fatto sulla parola. Mi secca che questo mio errore, cioè di aver “scoperto” una cosa scritta “a chiare lettere”(?) da qualche parte copra il senso più importante dei miei articoli, e cioè che questa “comoda” funzionalità è estremamente pericolosa, e comunque progettata male, ed andrebbe rivista. E la cosa che mi preoccupa di più è che questo genere di appunti mi sia stato mosso perlopiù da studenti di informatica o ex tali, in pratica i protagonisti dell'informatica presente e futura, quelli che dovranno confezionare gli strumenti che utilizzeremo domani e guidarci nel loro uso, in un mondo presumibilmente ancora più informatizzato di quello di oggi, per cui mi chiedo, con apprensione, che diavolo insegnino adesso nelle nostre università.

Per spiegare bene il concetto, farò un esempio un po'... tecnico. Sarà un “tecnico” molto elementare, che, più che spaventare un profano (che, anzi, spero si diverta un po'), sicuramente annoierà un esperto. Ma necessario per capire quello che intendo dire.

Uno dei primi esercizi che veniva assegnato in un corso di programmazione vecchio stile era: scrivere un programma che divida due numeri e ne visualizzi il risultato.

Il programma, che, per chi non lo sa, è una sequenza di “istruzioni” fornita al computer per svolgere un determinato compito, tipicamente aveva più o meno questo aspetto:

1) Visualizza sullo schermo il messaggio: “Programma per la divisione di un numero a per un numero b”
2) leggi il numero a
3) leggi il numero b
4) assegna al numero c il risultato di a diviso b
5) visualizza il messaggio “a diviso b è uguale a” seguito dal valore di c
6) fine

L'esecuzione dei comandi 2 e 3 consisteva nel consentire all'utente di inserire due numeri, “a” e “b”, mentre il comando 4 effettuava la divisione fra questi e ne assegnava il risultato ad una terza “variabile”, chiamata “c”, usata per visualizzare il risultato.

Il programma presentato sopra funziona: se scrivi 8 quando ti chiede “a”, e 2 quando ti chiede “b”, fornisce correttamente 4 come risultato. E così via, per qualsiasi altra coppia di numeri “a” e “b”.

Per QUASI qualsiasi altra coppia di numeri “a” e “b”!

Perché, se l'utente inserisce 0 come valore di “b”, il programma va in errore e si blocca, giacché non è possibile dividere per zero. E questo è il motivo per cui, se l'esercizio dato avesse fatto parte di un esame, l'autore del programma sarebbe stato bocciato.

Non solo. L'utente potrebbe, al posto di un numero, inserire una lettera dell'alfabeto, o un segno di punteggiatura. Non occorre necessariamente che sia un cretino, potrebbe urtare accidentalmente un tasto sbagliato. E di nuovo il programma andrebbe in errore. Come per zero, è altrettanto impossibile dividere 8 per “ù”.

Serve, quindi, introdurre nel programma dei controlli che verifichino la correttezza dei dati inseriti. Perché un programma non deve mai andare in errore. Beh... non dovrebbe. Nel caso che stiamo esaminando non accadrebbe niente di drammatico, ma se questa fase di inserimento dati fosse all'interno di un programma più complesso, che magari sta lavorando da qualche ora, e con il quale abbiamo già dovuto inserire di volta in volta una montagna di altri dati...

Inoltre, il caso in cui un programma va in crash è quello più fortunato. Immaginate se invece il dato errato non provocasse un fermo anomalo del programma, ma “solo” l'emissione di risultati fasulli, e da noi presi per buoni: se è un videogioco, magari parte qualche Madonna e la cosa finisce lì; se è il progetto di un ponte o di un componente di un satellite... ci scappano morti e si perdono miliardi di euro.

Tutto questo per dire che, quando si realizza un programma, è indispensabile evitare che una cretinata dell'utente possa trasformarsi in una catastrofe. Bisogna controllare che non inserisca una data come 30 febbraio, che l'anno venga inserito a quattro cifre (chi ricorda il famoso bug del duemila?), che un codice immesso appartenga ad un insieme di valori leciti... Certo, se uno scrive 13 marzo anziché 13 maggio, o 1998 anziché 1997, un problema sorge comunque... ma si fa quel che si può. Alcune cose sono controllabili, e vanno controllate. Altre... si spera in un buon lavoro dell'operatore. Ma bisogna prevedere tutte le cretinate che un utente può commettere, ed evitare che facciano danni.

Ora, secondo la corrente di pensiero di alcuni informatici, quelli che hanno contestato i miei articoli, il programma presentato sopra sarebbe un buon programma, perché fa quello che deve fare: dividere due numeri. E se l'utente è così cretino da inserire uno zero per il denominatore, o non legge la dicitura iniziale “Programma per la divisione di un numero a per un numero b” ed inserisce una lettera dell'alfabeto, che non può né dividere, né essere divisa... peggio per lui. Che colpa ne ha quello che ha realizzato il programma?

Forse, questa mancanza di sensibilità dipende anche dal tipo di programmazione studiato. Secondo quella ad oggetti, usata oggi, il programma di sopra, completo di controlli, si potrebbe riscrivere in questo modo:

prova a
{chiedere di inserire a e b;
dividere a per b e mostrare il risultato;}
e se qualcosa non va
{visualizza il messaggio: “Sei un cretino”;}

In questo modo, grazie che uno se ne frega dei problemi che possono insorgere, tanto ci pensa il linguaggio di programmazione! Manco vengono chiamati problemi, bensì “eccezioni”.

Ripeto: non tutto si può controllare, ma ciò che si può si DEVE controllare.

Come ho accennato nel precedente articolo, potrebbe bastare un controllo come quello effettuato dal desktop remoto di Windows per limitare i pericoli della funzionalità di sincronizzazione.

Chi sa cos'è il desktop remoto può saltare questo capoverso. Per i più profani, spiego che si tratta di un programmino fornito con il sistema operativo Windows che consente ad un pc di prendere il controllo di un altro computer (entrambi, ovviamente, devono essere collegati in rete), non importa se sia quello del proprio figlio nella stanza accanto o un computer all'ultimo piano di un grattacielo di New York, come se si fosse seduti davanti a “quel” computer.

Perché questo programma funzioni, è necessario che sul computer “controllato” sia, intanto, abilitata la funzione, e poi che sia impostata una password di accesso, in modo da impedire accessi non autorizzati. Senza questi accorgimenti, chiunque potrebbe entrare tranquillamente nel nostro computer, magari di notte quando è lasciato acceso per scaricare qualcosa e non ci siamo noi davanti, e farci quello che vuole.

Se la sincronizzazione su Chrome fosse regolata allo stesso modo, questa funzionalità sarebbe molto meno pericolosa.

Ma gli ingegneri di Google hanno deciso di rischiare la divisione per zero... anzi, peggio, perché, se l'utente fa il cretino, la funzionalità non si blocca, anzi fa regolarmente ciò che deve fare e che invece non dovrebbe... e le nuove leve dell'informatica italiana plaudono e definiscono cialtronerie le obiezioni mosse.

E il paragone con il coltello bene affilato si dimostra più che azzeccato.

Forse sarebbe necessario stabilire alcune norme, minime, cui i programmi realizzati dovrebbero sottostare. Ma questo significherebbe istituire una specie di censura, e sarebbe antipatico. E l'eventualità che possano mettere mano alla questione i politici mi terrorizza: con le loro riforme hanno già distrutto l'università italiana, non oso pensare a cosa potrebbe accadere se stabilissero anche di regolamentare il mondo dell'informatica. Perché, nello strano mondo in cui viviamo, i politici hanno la prerogativa di decidere e legiferare in campi in cui non capiscono una mazza.

Bisogna (purtroppo? Ai posteri l'ardua sentenza) affidarsi, e confidare, nel buon senso degli operatori, anche quando i segnali sono scoraggianti. E discutere, scontrarsi magari, senza vincoli imposti dall'alto che raramente si sono dimostrati efficaci ed illuminati.

Io, la mia parte, l’ho fatta. Non con lo stile scarno ed essenziale della letteratura tecnica, magari, ma ho dato il mio contributo. Magari sbagliato, magari hanno ragione i guru dell’informatica che hanno massacrato i miei articoli…

Certo, non sarò io a deciderlo.