Hai mai pensato al fastidio che causa qualcosa che non va come previsto?
Indipendentemente dal motivo, lo abbiamo sperimentato tutti almeno una volta nella vita. Eh sì, quando qualcosa va storto ne siamo infastiditi, comprensibilmente. Ed è proprio al verbo infastidire, in inglese to bug, a cui sembra risalire il percorso linguistico del nostro bug informatico, quell’errore che rovina la nostra esperienza, da utenti e che ci costringe a rifare un sacco di lavoro, da sviluppatori software.
Esiste anche un celebre aneddoto che, dal verbo to bug, ci porta a bug, il sostantivo che definisce un insetto e che anche nel gergo italiano – nelle sue accezioni di baco e bug – è deputato a definire errori nel funzionamento di un software.
La nostra anomalia non calcolata e che genera un comportamento inatteso o errato è fastidiosa come l’insetto che si trovò sulla strada la matematica e informatica Grace Hopper, quando nel secondo Dopo Guerra trovò una falena morta a inceppare uno dei primissimi calcolatori della storia, il “Mark II”. Si dice che la Hopper attaccò poi l’insetto sul suo diario e scrisse «1545. Relay #70 Panel F (moth) in relay. First actual case of bug being found».
Eppure due secoli fa, la parola era già comparsa. Edison (sì, quel Signor Thomas Edison), in un’epoca in cui la tecnologia era decisamente di altro genere, utilizza il termine bug per connotare piccoli guasti nelle invenzioni. E qui, il cacciatore di bug è il riparatore.
Ci sono errori ed errori, insetti ed insetti insomma.
Ci sono errori di sintassi, come le parole o i simboli scritti erroneamente nel codice, che sono decisamente più leggeri (i vecchi errori blu, nda), e come i nostri refusi ci sono software che ci aiutano a individuarli automaticamente in modo rapido.
Tuttavia, a preoccuparci di più sono gli errori di runtime, che causano bug perché sono conflitti tra software, memorie o permessi, per cui la correzione non è sul codice, ma sulla soluzione del conflitto.
Non finisce qui: nel parco bug tosti abbiamo anche gli errori di logica, dove l’errore è annidato in uno degli incroci di funzioni presenti nel software e richiede conoscenza, competenza e molta attenzione.
Prevenire è meglio che curare
Ci rifacciamo a un noto slogan pubblicitario, non solo per testare l’era dei nostri 25 lettori, ma anche per raccontare il nostro modo di lavorare con attenzione e focalizzazione. È una bella sfida, è la nostra sfida quando progettiamo e scriviamo software. E come in ogni sfida, si apre il momento della challenge o della pura e semplice curiosità: se sei un programmatore o una programmatrice, qual è il bug con cui hai avuto a che fare e che ancora ti ricordi bene e ti ricorderai per un pezzo?
Scrivilo nel primo commento o inviacelo via email ;-)
Hai mai pensato al fastidio che causa qualcosa che non va come previsto?
Indipendentemente dal motivo, lo abbiamo sperimentato tutti almeno una volta nella vita. Eh sì, quando qualcosa va storto ne siamo infastiditi, comprensibilmente. Ed è proprio al verbo infastidire, in inglese to bug, a cui sembra risalire il percorso linguistico del nostro bug informatico, quell’errore che rovina la nostra esperienza, da utenti e che ci costringe a rifare un sacco di lavoro, da sviluppatori software.
Esiste anche un celebre aneddoto che, dal verbo to bug, ci porta a bug, il sostantivo che definisce un insetto e che anche nel gergo italiano – nelle sue accezioni di baco e bug – è deputato a definire errori nel funzionamento di un software.
La nostra anomalia non calcolata e che genera un comportamento inatteso o errato è fastidiosa come l’insetto che si trovò sulla strada la matematica e informatica Grace Hopper, quando nel secondo Dopo Guerra trovò una falena morta a inceppare uno dei primissimi calcolatori della storia, il “Mark II”. Si dice che la Hopper attaccò poi l’insetto sul suo diario e scrisse «1545. Relay #70 Panel F (moth) in relay. First actual case of bug being found».
Eppure due secoli fa, la parola era già comparsa. Edison (sì, quel Signor Thomas Edison), in un’epoca in cui la tecnologia era decisamente di altro genere, utilizza il termine bug per connotare piccoli guasti nelle invenzioni. E qui, il cacciatore di bug è il riparatore.
Ci sono errori ed errori, insetti ed insetti insomma.
Ci sono errori di sintassi, come le parole o i simboli scritti erroneamente nel codice, che sono decisamente più leggeri (i vecchi errori blu, nda), e come i nostri refusi ci sono software che ci aiutano a individuarli automaticamente in modo rapido.
Tuttavia, a preoccuparci di più sono gli errori di runtime, che causano bug perché sono conflitti tra software, memorie o permessi, per cui la correzione non è sul codice, ma sulla soluzione del conflitto.
Non finisce qui: nel parco bug tosti abbiamo anche gli errori di logica, dove l’errore è annidato in uno degli incroci di funzioni presenti nel software e richiede conoscenza, competenza e molta attenzione.
Prevenire è meglio che curare
Ci rifacciamo a un noto slogan pubblicitario, non solo per testare l’era dei nostri 25 lettori, ma anche per raccontare il nostro modo di lavorare con attenzione e focalizzazione. È una bella sfida, è la nostra sfida quando progettiamo e scriviamo software. E come in ogni sfida, si apre il momento della challenge o della pura e semplice curiosità: se sei un programmatore o una programmatrice, qual è il bug con cui hai avuto a che fare e che ancora ti ricordi bene e ti ricorderai per un pezzo?
Scrivilo nel primo commento o inviacelo via email ;-)
