Basta la logica, per tenerci lontani dagli errori? Filosofia applicata al duro lavoro del programmatore.
Chi fa il programmatore, si sente spesso dire una frase, che all'incirca suona così: “Fai il programmatore, non riesco a capire come tu possa fare errori, dopotutto le tue sono cose logiche” .
Il dettaglio della frase: “cose logiche” mi fa morire.
Cosa vuol dire “cose logiche” ? o anche “roba logica” ? Giusto per fare un po’ di chiarezza, sarebbe meglio ricordare che la logica è una “scienza” umana, nobilissima in verità, ma assolutamente perfettibile e non perfetta. Pensare che “la logica salverà il mondo” o che più banalmente possa rendere una professione scevra di errori o grattacapi è una concezione positivista poco credibile.
Senza fare della filosofia, cosa per cui non sono qualificato, posso provare a spiegarvi qualcosa che non dovrei spiegarvi, e cioè perché, pur facendo uso di squisita logica, i software in generale, e i siti web in particolare non sono esenti da "errore".
1) Le parti interne del nostro software possono essere tutte giuste, ma può essere sbagliato qualcosa in ciò che lo esegue. Cosa voglio dire? Semplicemente che nella programmazione, come nella vita, facciamo molto di mano nostra, ma per altro ci affidiamo ad altri. Chi ha creato la vostra applicazione per cellulare (per esempio) non ha creato il sistema operativo del cellulare. Non può sapere dove si annida il punto in cui per distrazione, stanchezza o idiozia, il programmatore suo fratello ha seminato un errore. Oltre a ciò, chi ha creato la vostra applicazione per cellulare, se non è un egocentrico megalomane masochista completo, non ha riscritto tutto da solo. Avrà scritto molto da solo, ma per altre parti avrà riutilizzato codice scritto da altri, che si è già dimostrato affidabile un miliardo di volte. Arriva sempre la volta in cui non si mostrerà affidabile.
Quello sarà il momento in cui uscirà la nuova versione con i bug corretti.
2) Tutto può essere assolutamente giusto, via codice, ma la fonte dei dati è attendibile? Ovvero, il codice che viene eseguito ha sempre bisogno di dati in ingresso, che deve tra l’altro ricontrollare, ma la creatività umana nel produrre errori è molto complessa, e quindi: siamo sicuri che i dati che ci arrivano siano affidabili, corretti? Molto spesso, l'errore nel proprio codice, viene scatenato da un dato in ingresso, che ci arriva da un altra fonte e che mai e poi mai avrebbe dovuto avere una "forma viziata", perché lo consideravamo senza errori.
3) Dipende da cosa intendiamo per giusto. Per un programmatore un risultato corretto è un insieme coerente di caratteri standard, che abbiano un senso univoco, prevedibile in base all'input dato. Non ha il minimo interesse all'estetica, alla leggibilità del risultato e all'impatto cognitivo su chi lo vedrà.
4) Gli ambienti di sviluppo e i linguaggi di programmazione, sono mutevoli. Nuovi miglioramenti e release vengono sfornate di continuo. Nuovi approcci che permettono di risparmiare tempo, denaro e fatica devono essere sperimentati. Venendo all'esperienza del web, non è strano che dopo aver creato qualcosa con tutti gli ultimi standard più aggiornati del nostro linguaggio di programmazione preferito, ci si ritrovi a dover correre ai ripari, perché il benedetto server su cui girerà il futuro sito ha problemi di compatibilità con le ultime versioni del nostro linguaggio di programmazione, o settaggi e configurazioni strane, in uso dieci anni prima.
5) I programmatori sono dei simpatici burloni, o forse degli idioti, fate voi. Non è impossibile, che qualche sottopagato abile ingegnere frustrato nasconda piccoli trucchetti nel suo codice, per rendere più facili alcuni passaggi, oppure semplicemente per scherzare. Una possibilità su svariati miliardi di ottenere un risultato inaspettato, cosa sarà mai ?
Voglio farvi un esempio molto semplice, per tentare di farvi capire il succo del discorso.
Mettiamo che una web agency abbia creato un CMS proprietario, con supporto multilingua incluso, che permetta al cliente di inserire il suo testo, e nel caso non voglia inserire anche le traduzioni, il sistema pensi da solo a inviare tutto a Google Translate e quindi a tradurre automaticamente quest'ultimo.
Ora, i servizi di traduzione automatica, devono lasciare le cose che non devono essere tradotte in lingua originale, come le mail, per esempio.
mionomeacaso@gmail.com deve rimanere uguale in tutte le lingue del mondo e così è.
Dato per assodato questo funzionamento, siamo tutti tranquilli.
Ora, mettiamo che il cliente di questa web agency scriva un articolo di questo tenore:
“Molto spesso, per dare indicazioni generiche su come riempire i campi di un form, si scrivono frasi del genere: inserisci qui la tua mail (per esempio) mario.rossi@mail.it”
Il cliente salva, e quindi avvia la traduzione automatica. La procedura è testata e funziona.
Qualcosa però non va, il cliente chiama, giustamente divertito e curioso di sapere come mai la sua traduzione non corrisponda del tutto a quello che aveva scritto.
L’ignaro elemento della web agency all'altro capo della cornetta, risponde che la traduzione automatica è buona ma non impeccabile e quindi…
Il cliente risponde rincarando sul fatto che questo lo sa, ma che conviene che venga data un’occhiata alla traduzione inserita
Una volta letta, la traduzione risulta:
"Very often, to give general guidelines on how to fill in fields of a form, you write sentences like this: insert your email (for example) john.doe@mail.it"
Ora, la semplice questione è che invece di ritrovarsi mario.rossi@mail.it, il cliente si è ritrovato john.doe@mail.it.
Non se lo aspettava, perché le mail dovrebbero restare invariate, nel processo di traduzione.
mariorossi@virgilio.it, infatti, sarebbe rimasto il nostro carissimo mario rossi.
Quindi, cosa facciamo ? Google traslate ritiene che se facciamo un esempio sulla mail del comunissimo mario.rossi, con una mail che evidentemente non esiste, conviene tradurlo in john.doe.
Tra l’altro non ci da neanche il conforto di dirci come sarebbe Mario Rossi in spagnolo o francese. Non provateci ci ho già provato io. John vince.
Per Google, sia santificato il suo nome, se faccio un esempio in italiano sulla mail del nome più comune sui nomi comuni, questo diverrà john.
A questo punto si spiega al cliente la filosofia di Google, neanche poi così sbagliata.Il cliente a questo punto dovrà scegliere, inchinarsi a Google e quindi nel caso cambiare la traduzione automatica dopo, oppure esigere che l’italianissimo Mario rimanga così, sempre e comunque, fedele alla sua essenza?
Mettiamo il caso il cliente decida che in realtà preferisci sempre e comunque mantenere mario.rossi@mail.it
Nel caso, il servizio di traduzione automatico, si arricchirà solo per quel cliente specifico di una “pezza” ovvero di un aggiustamento veloce e funzionale, che converte john.doe in mario rossi, se la traduzione deve essere dall’italiano all’inglese. Una semplice “correzione” in volata, che dovrà rimanere specifica per quel prodotto, sempre sperando che sia un prodotto usato solo da quel cliente. Se anche il figlio volesse scrivere saghe intere sulla vita del nostro tanto spesso citato connazionale, precisandone la mail fittizia, ci richiamerà, domandandoci dello strano comportamento, assolutamente non standard.
Non è ancora finita. A seconda dell’ora a cui questa richiesta arriva, tipo le 11.30 di sera di Sabato, nel week end di reperibilità, il programmatore farà la sua. Metterà che joh.doe@mail.it è sempre e comunque mario.rossi@mail.it a prescindere da quale lingua arriva il testo e verso quale lingua va. Così, se capiterà che la procedura automatica debba tradurre un testo dall’inglese all’italiano, john.doe, sia maledetto il suo nome, diventerà mario. Poco male se quella procedura rimarrà solo sul cms di quel cliente specifico.
Se per casso qualche file verrà ripreso da un progetto a un altro, Mario continuerà ad aleggiare come un fantasma, a lungo, sul codice ignaro.
Questa storiella è ovviamente finita, e mi è venuta in mente, mentre stavo facendo un form di contatti multilingua, per un sito su cui sto attualmente lavorando. Ho ovviamente esagerato la questione del tutto di secondaria importanza e che mai potrebbe dare adito a tanti passaggi. Il meccanismo però di una tipologia di errori che possono affliggere un web developer è questa.
Il dettaglio della frase: “cose logiche” mi fa morire.
Cosa vuol dire “cose logiche” ? o anche “roba logica” ? Giusto per fare un po’ di chiarezza, sarebbe meglio ricordare che la logica è una “scienza” umana, nobilissima in verità, ma assolutamente perfettibile e non perfetta. Pensare che “la logica salverà il mondo” o che più banalmente possa rendere una professione scevra di errori o grattacapi è una concezione positivista poco credibile.
Senza fare della filosofia, cosa per cui non sono qualificato, posso provare a spiegarvi qualcosa che non dovrei spiegarvi, e cioè perché, pur facendo uso di squisita logica, i software in generale, e i siti web in particolare non sono esenti da "errore".
1) Le parti interne del nostro software possono essere tutte giuste, ma può essere sbagliato qualcosa in ciò che lo esegue. Cosa voglio dire? Semplicemente che nella programmazione, come nella vita, facciamo molto di mano nostra, ma per altro ci affidiamo ad altri. Chi ha creato la vostra applicazione per cellulare (per esempio) non ha creato il sistema operativo del cellulare. Non può sapere dove si annida il punto in cui per distrazione, stanchezza o idiozia, il programmatore suo fratello ha seminato un errore. Oltre a ciò, chi ha creato la vostra applicazione per cellulare, se non è un egocentrico megalomane masochista completo, non ha riscritto tutto da solo. Avrà scritto molto da solo, ma per altre parti avrà riutilizzato codice scritto da altri, che si è già dimostrato affidabile un miliardo di volte. Arriva sempre la volta in cui non si mostrerà affidabile.
Quello sarà il momento in cui uscirà la nuova versione con i bug corretti.
2) Tutto può essere assolutamente giusto, via codice, ma la fonte dei dati è attendibile? Ovvero, il codice che viene eseguito ha sempre bisogno di dati in ingresso, che deve tra l’altro ricontrollare, ma la creatività umana nel produrre errori è molto complessa, e quindi: siamo sicuri che i dati che ci arrivano siano affidabili, corretti? Molto spesso, l'errore nel proprio codice, viene scatenato da un dato in ingresso, che ci arriva da un altra fonte e che mai e poi mai avrebbe dovuto avere una "forma viziata", perché lo consideravamo senza errori.
3) Dipende da cosa intendiamo per giusto. Per un programmatore un risultato corretto è un insieme coerente di caratteri standard, che abbiano un senso univoco, prevedibile in base all'input dato. Non ha il minimo interesse all'estetica, alla leggibilità del risultato e all'impatto cognitivo su chi lo vedrà.
4) Gli ambienti di sviluppo e i linguaggi di programmazione, sono mutevoli. Nuovi miglioramenti e release vengono sfornate di continuo. Nuovi approcci che permettono di risparmiare tempo, denaro e fatica devono essere sperimentati. Venendo all'esperienza del web, non è strano che dopo aver creato qualcosa con tutti gli ultimi standard più aggiornati del nostro linguaggio di programmazione preferito, ci si ritrovi a dover correre ai ripari, perché il benedetto server su cui girerà il futuro sito ha problemi di compatibilità con le ultime versioni del nostro linguaggio di programmazione, o settaggi e configurazioni strane, in uso dieci anni prima.
5) I programmatori sono dei simpatici burloni, o forse degli idioti, fate voi. Non è impossibile, che qualche sottopagato abile ingegnere frustrato nasconda piccoli trucchetti nel suo codice, per rendere più facili alcuni passaggi, oppure semplicemente per scherzare. Una possibilità su svariati miliardi di ottenere un risultato inaspettato, cosa sarà mai ?
Voglio farvi un esempio molto semplice, per tentare di farvi capire il succo del discorso.
Mettiamo che una web agency abbia creato un CMS proprietario, con supporto multilingua incluso, che permetta al cliente di inserire il suo testo, e nel caso non voglia inserire anche le traduzioni, il sistema pensi da solo a inviare tutto a Google Translate e quindi a tradurre automaticamente quest'ultimo.
Ora, i servizi di traduzione automatica, devono lasciare le cose che non devono essere tradotte in lingua originale, come le mail, per esempio.
mionomeacaso@gmail.com deve rimanere uguale in tutte le lingue del mondo e così è.
Dato per assodato questo funzionamento, siamo tutti tranquilli.
Ora, mettiamo che il cliente di questa web agency scriva un articolo di questo tenore:
“Molto spesso, per dare indicazioni generiche su come riempire i campi di un form, si scrivono frasi del genere: inserisci qui la tua mail (per esempio) mario.rossi@mail.it”
Il cliente salva, e quindi avvia la traduzione automatica. La procedura è testata e funziona.
Qualcosa però non va, il cliente chiama, giustamente divertito e curioso di sapere come mai la sua traduzione non corrisponda del tutto a quello che aveva scritto.
L’ignaro elemento della web agency all'altro capo della cornetta, risponde che la traduzione automatica è buona ma non impeccabile e quindi…
Il cliente risponde rincarando sul fatto che questo lo sa, ma che conviene che venga data un’occhiata alla traduzione inserita
Una volta letta, la traduzione risulta:
"Very often, to give general guidelines on how to fill in fields of a form, you write sentences like this: insert your email (for example) john.doe@mail.it"
Ora, la semplice questione è che invece di ritrovarsi mario.rossi@mail.it, il cliente si è ritrovato john.doe@mail.it.
Non se lo aspettava, perché le mail dovrebbero restare invariate, nel processo di traduzione.
mariorossi@virgilio.it, infatti, sarebbe rimasto il nostro carissimo mario rossi.
Quindi, cosa facciamo ? Google traslate ritiene che se facciamo un esempio sulla mail del comunissimo mario.rossi, con una mail che evidentemente non esiste, conviene tradurlo in john.doe.
Tra l’altro non ci da neanche il conforto di dirci come sarebbe Mario Rossi in spagnolo o francese. Non provateci ci ho già provato io. John vince.
Per Google, sia santificato il suo nome, se faccio un esempio in italiano sulla mail del nome più comune sui nomi comuni, questo diverrà john.
A questo punto si spiega al cliente la filosofia di Google, neanche poi così sbagliata.Il cliente a questo punto dovrà scegliere, inchinarsi a Google e quindi nel caso cambiare la traduzione automatica dopo, oppure esigere che l’italianissimo Mario rimanga così, sempre e comunque, fedele alla sua essenza?
Mettiamo il caso il cliente decida che in realtà preferisci sempre e comunque mantenere mario.rossi@mail.it
Nel caso, il servizio di traduzione automatico, si arricchirà solo per quel cliente specifico di una “pezza” ovvero di un aggiustamento veloce e funzionale, che converte john.doe in mario rossi, se la traduzione deve essere dall’italiano all’inglese. Una semplice “correzione” in volata, che dovrà rimanere specifica per quel prodotto, sempre sperando che sia un prodotto usato solo da quel cliente. Se anche il figlio volesse scrivere saghe intere sulla vita del nostro tanto spesso citato connazionale, precisandone la mail fittizia, ci richiamerà, domandandoci dello strano comportamento, assolutamente non standard.
Non è ancora finita. A seconda dell’ora a cui questa richiesta arriva, tipo le 11.30 di sera di Sabato, nel week end di reperibilità, il programmatore farà la sua. Metterà che joh.doe@mail.it è sempre e comunque mario.rossi@mail.it a prescindere da quale lingua arriva il testo e verso quale lingua va. Così, se capiterà che la procedura automatica debba tradurre un testo dall’inglese all’italiano, john.doe, sia maledetto il suo nome, diventerà mario. Poco male se quella procedura rimarrà solo sul cms di quel cliente specifico.
Se per casso qualche file verrà ripreso da un progetto a un altro, Mario continuerà ad aleggiare come un fantasma, a lungo, sul codice ignaro.
Questa storiella è ovviamente finita, e mi è venuta in mente, mentre stavo facendo un form di contatti multilingua, per un sito su cui sto attualmente lavorando. Ho ovviamente esagerato la questione del tutto di secondaria importanza e che mai potrebbe dare adito a tanti passaggi. Il meccanismo però di una tipologia di errori che possono affliggere un web developer è questa.
By Marco
Commenti
Posta un commento