Cari autori, stiamo riscontrando problemi con l'invio delle email dal sito. Al momento sono quindi sospesi gli invii email delle notifiche di commenti e testi. Nel caso non riceviate l'email di conferma di iscrizione, potete scrivere a staff@alidicarta.it per la conferma manuale.




Ultimi pubblicati  |  Ultimi modificati  | Cerca un testo | Archivio degli autori  | Ricevi il feed dei testi di Alidicarta.it  Feed Rss dei testiRegistrati come autore!

Il twitter degli autori

Caricamento twitter... (reload in caso di blocco)
Fai il login per twittare
mostra/nascondi twitter degli autori


Il caso Chrome: ultimo atto
Scritto da Pest Writer
Categoria: Opinione
Scritto il 02/04/2015, Pubblicato il 02/04/2015, Ultima modifica il 02/04/2015
Codice testo: 242015121254 | Letto 1735 volte

Attendere caricamento dei dati...(reload in caso di blocco)

Torna alla prima pagina 1/3 Pagina seguente


Torno, e spero che questa volta sia davvero l’ultima, sull’argomento Google Chrome. È un tema che ormai mi ha seccato (e se ha seccato me, figuriamoci voi!), e deluso, per le risposte che ho ricevuto. Ma, proprio per queste, ho qualche riflessione che non mi va di tenere solo per me.

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?

Torna alla prima pagina 1/3 Pagina seguente



Menu

Home Page
Iscriviti come autore
Scrivi il tuo testo
Forum
Cerca


Pubblicità

Su di noi

Strumenti

Help

© 2001-2018 - Layout, grafica e contenuti sono protetti da diritto d'autore
Vietata la riproduzione - PI:02102630205 Hosting www.dominiando.it