La verdad sobre qué tipo de insecto podría haber sido se ha perdido en el folclore, aunque las leyendas dicen que era una polilla aplastada, y como todas las leyendas, parece haber algo de verdad en alguna parte. Según el erudito Fred R. Shapiro , el 9 de septiembre de 1945 (o tal vez 1947), los ingenieros de Harvard estaban trabajando en el Mark II, o Aiken Relay Calculator, que estaba siendo probado por la Marina de los EE.UU. Después de mirar el hardware, encontraron que una polilla caducada había quedado atrapada entre el relé 70 y el pane
|
etiquetas: primeros , errores , informáticos , bugs , shapiro , polilla , edison
Nunca se insistirá lo bastante en la importancia de comprobar la fecha de caducidad de las polillas.
We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).
Fuente: www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html
Tu puedes montar una librería que funciona perfectamente y viene alguien y la usa para algo para lo que no estaba pensado, en esas circunstancias se puede producir un problema pero no es un error de la librería y tampoco tiene porque serlo del programa que la usa sino de la interacción de ambas.
Ejemplo muy famoso: Un servidor se colgaba siempre las noches de luna llena.
Nadie sabía porque, el servidor funcionaba perfectamente todos los días pero las noches de luna llena (exactamente la noche de luna llena, no aproximadamente) se colgaba.
Debugaron el código y encontraron que la fecha la obtenían de un programa externo al que llamaban y este colocaba en cierta posición de memoria el día, el mes, el año y la hora... pero quien había hecho el programa, que no tenía nada que ver (ni conocía) a los que lo habían tomado de la red y lo habían utilizado en el servidor, había querido añadir que, las noches de luna llena, mostrase un "full moon tonight" al lado de la fecha... al llamarlo desde otro programa y dirigir su salida a una posición de memoria funcionaba hasta que las noches de luna llena, al ser la cadena más larga, machacaba código adyacente en memoria y causaba un fallo del sistema.
¿Es un error del primer programa? No... ¿lo es del segundo? tampoco, es un problema de integración de dos programas sin errores, y eso es un bug.
Y una biblioteca cuando la usas acaba formando parte de un programa, ya que se considera como un todo. De hecho la GPL no distingue entre enlace estático o enlace dinámico, si usas una biblioteca, pasa a formar parte de tu programa.
Si el primer programa sí se diseñó para ser usado por terceros ese caso debió estar documentado, error del primero si no fue así, error del segundo si fue así y no atendieron a esa documentación.
Es posible que se pueda encontrar algún ejemplo en el que no sea error de nadie pero este no lo parece.
es.wikipedia.org/wiki/Error_de_software