¿Es posible construir software que no falle?

FERNANDO OREJAS

Todos los días, miles de usuarios de ordenadores sufren fallos de software: programas que se cierran inesperadamente, que dejan el sistema bloqueado o, simplemente, que producen resultados erróneos. Sin embargo, pese a las molestias que nos ocasionan, tendemos a considerarlo un mal inevitable. Imaginemos que esto ocurriera con las lavadoras: que cada 4 o 5 días nuestra lavadora se parara en mitad de un lavado y que algunas veces nos dejara la ropa inservible. Seguramente, nadie se resignaría y habría quejas y demandas. Probablemente, la empresa responsable tendría que pagar indemnizaciones. En este contexto, nos podemos preguntar: ¿Qué hace que el software falle y las lavadoras no?  ¿Es realmente imposible desarrollar software que no tenga fallos?

Un problema básico de los sistemas software es su carácter discreto,  que hace que modificaciones muy pequeñas puedan provocar cambios radicales de comportamiento. Por el contrario, en las ingenierías clásicas los productos suelen tener carácter continuo, con lo que pequeñas alteraciones sólo provocan pequeños cambios de comportamiento. Por ejemplo, una mínima modificación en la tasa de entrada de combustible a un motor sólo provocará un mínimo cambio en su funcionamiento, como puede ser una pequeña variación en el número de revoluciones. Sin embargo, pequeñas modificaciones en un programa pueden tener efectos catastróficos. Por ejemplo, substituir en un programa una suma por una resta (lo que representa una modificación de un carácter entre los muchos miles que puede tener el programa) puede cambiar completamente su comportamiento. Por pequeños errores de este tipo, en 1962 se perdió el Mariner 1, la primera sonda espacial enviada a Venus, y en 1996 se perdió el cohete europeo Ariane 5. En el primer caso, las pérdidas se estimaron en 15 millones de Euros y, en el segundo,  en 400 millones de Euros. El carácter discreto del software ocasiona que las técnicas matemáticas que se utilizan tradicionalmente en ingeniería sean relativamente poco útiles en el diseño de software. En particular, la mayor parte de técnicas que permiten estudiar el software están basadas en la llamada matemática discreta y, especialmente, en la lógica matemática, cuyo estudio es mucho menos frecuente.

Si observamos el proceso de construcción del software, podemos entender cómo se generan los fallos. Simplificando, podemos considerar dos fases, la primera de las cuales es la fase de especificación o modelado. En ella se define, entre otras cosas, qué es lo que ha de hacer un sistema, qué situaciones ha de ser capaz de resolver o cómo ha de interactuar con su entorno. Si, como a menudo ocurre,  no se presta suficiente atención a esta fase, el software tendrá fallos relacionados con situaciones no previstas o con cálculos mal definidos. Un ejemplo clásico de fallo por un modelado insuficiente ocurrió en 1983 y pudo haber ocasionado el comienzo de la tercera guerra mundial: el sistema de alerta de la Unión Soviética detectó que Estados Unidos había lanzado un ataque con 5 misiles. Afortunadamente, el oficial al mando no puso en marcha un ataque de respuesta, ya que consideró que era muy raro que, si los americanos les estaban atacando, lo hicieran con sólo 5 misiles. El motivo del fallo fue que no se había previsto que el reflejo del sol en las nubes, en determinadas circunstancias, podía producir una señal de radar similar a la de un ataque de misiles.

La segunda fase del proceso de construcción del software es la de programación, que es cuando los programas realmente se crean. En esta fase se cometerá un buen número de errores, típicamente debidos a una comprensión inadecuada de lo que se quiere implementar. Para detectarlos y corregirlos, es necesario estudiar el software en detalle. La técnica usada habitualmente en la industria es la prueba (testing), consistente en la ejecución del programa con diversos juegos de prueba que intentan simular todas las posibles situaciones por las que ha de pasar ese software. Lamentablemente, como dijo E.W. Dijkstra (premio Turing en 1972), "la prueba puede demostrar la presencia de errores en un programa, pero no su ausencia". El problema es que siempre puede haber situaciones no cubiertas por los juegos de pruebas utilizados. La alternativa es la verificación de programas, es decir la demostración lógica de que un programa hace lo que dice su especificación. Normalmente, la verificación se realiza utilizando herramientas software que pueden automatizar buena parte del proceso de demostración.

En los primeros años de la informática, los errores de software se consideraban un problema irrelevante. Lo que preocupaba eran los fallos del hardware. Los programas que se construían eran relativamente sencillos, por lo que los errores o no se producían o se corregían fácilmente. Por eso, resulta sorprendente que, también en este ámbito, Turing fuera un pionero: en un trabajo poco conocido de 1949, Turing argumenta la necesidad de demostrar que los programas son correctos y presenta algunas técnicas para conseguirlo. Estas técnicas serían (re)descubiertas por los investigadores que introdujeron la verificación de programas casi 20 años después.

A mediados-finales de los años 60, investigadores y especialistas empiezan a ser  conscientes de lo preocupante que es la mala calidad del software que se construye. Como consecuencia, se comienza a investigar sobre cómo se puede garantizar que el software no falle y, en particular, sobre la verificación de programas. Desde entonces, un buen número de investigadores ha sido galardonado con el premio Turing por sus contribuciones en este área: E.W. Dijkstra (1972), R. Floyd (1978), C.A.R. Hoare (1980), R. Milner (1991), A. Pnueli (1996) y E. Clarke, E. Allen Emerson y J. Sifakis (2007).

En estos momentos, después de toda la investigación realizada, se puede decir que es posible desarrollar software tan fiable como cualquier otro producto de ingeniería. Un buen ejemplo, puede ser el software de la línea 14 del metro de París, la línea pionera en estar completamente automatizada. En ella, los trenes carecen de conductor y son guiados por un sistema software. Dicho sistema fue especificado completamente, utilizando un método llamado B. En total se necesitaron 110.000 líneas de especificación, que fueron verificadas en detalle utilizando distintas herramientas. El sistema final, obtenido por traducción (automática) de esa especificación y formado por 86.000 instrucciones escritas en el lenguaje de programación Ada, fue puesto en funcionamiento en 1998. En 2007 (no tengo datos posteriores) todavía no se había detectado ningún fallo de software.

Las técnicas que garantizan la ausencia de fallos no se utilizan en el software normal, sino sólo en sistemas de software crítico, de los que puede depender la vida de personas. Los motivos que alegan las empresas de software son, básicamente, dos. Por una parte, argumentan que hacer software sin fallos es caro. Esto se debe a que los fallos no les cuestan nada. En 1993, la empresa de hardware Intel sacó al mercado un nuevo procesador Pentium que contenía un error en la división: producía resultados erróneos, aunque sólo se detectaban en cálculos que necesitaban mucha precisión. Este error le costó a Intel unos 400 millones de euros, además de una pérdida de imagen difícil de cuantificar. Desde entonces, Intel es una de las empresas que más invierte en investigación sobre verificación. Seguramente, las empresas de software cambiarían su política si sus fallos se penalizaran de una forma similar. El segundo motivo alegado es la dificultad para encontrar informáticos con la formación adecuada en el uso de estas técnicas. Lamentablemente, en España, la última reforma de planes de estudios en Ingeniería Informática ha ido en la dirección contraria: en la mayor parte de Escuelas y Facultades de Informática las materias fundamentales en las que se basa la especificación y la verificación de programas han dejado de ser obligatorias, pasando a tener una presencia marginal.

 

Fernando Orejas es catedrático de la Universitat Politècnica de Catalunya.

Comments

[Publicado por: Clotet]

Interesante artículo. Lo hemos usado en clase de Introducción a la Computación para que los estudiantes reflexionaran sobre los fallos en el software.

[Publicado por: JAP]

Hola Fernando,

Muchas gracias por esas referencias. Ya tengo el de Morris & Jones, y puedo ver (que no imprimir) el documento de Turing.

Saludos,

Joan A. Pastor (JAP)

[Publicado por: FOrejas]

JAP, la referencia es:

A.M.Turing: “Checking a Large Routine.” In Report of a Conference on High Speed Automatic Calculating Machines, Univ. Math. Lab., Cambridge (1949), pp. 67-69.

Se puede obtener en las páginas web donde están todos los artículos de Turing. Yo conocí ese artículo, hace ya un buen número de años, a través de este otro:

F.L. Morris and C.B. Jones: "An Early Program Proof by Alan Turing", Annals of the History of Computing 6, 2 (!984), pp. 139-143.
Fernando

[Publicado por: JAP]

Fernando, comentas en tu artículo que "...en un trabajo poco conocido de 1949, Turing argumenta la necesidad de demostrar que los programas son correctos y presenta algunas técnicas para conseguirlo".

¿Podrías indicar la referencia de dicho artículo, por favor?

Gracias por adelantado.

[Publicado por: Antonio]

Susurro: ¿Cuál es tu filosofía en cuanto a la relación del uso de informática y el desempleo en personal de calificaciones mínimas? ¿Debería ser prohibido en España el uso de ordenadores en tiempos de alto desempleo? ¿O mejor renuncias?

[Publicado por: Antonio]

Susurro:

No es Blue Deep, sino Deep Blue. Y tampoco es perfecto como programa. Que gane una vez o un millón no implica que no exista una posición que resuelva de una forma no optima. En otras palabras, un programa no es perfecto porque gane 10 partidas.

El resto de tus alegatos no tienen nada que ver con la realidad. No todos los programadores se dedican a escribir "contabilidades" ad hoc. Debería ser contra la ley hacer eso. Un programador, o un equipo pequeño de programadores nunca podrán escribir mejor código que los especialistas que tienen un producto con 10 o 15 años de desarrollo.

Hay procesos de tiempo real que ni te puedes imaginar. Si el problema es de sincronía mientras se lineariza una cascara de 250 dimensiones mientras el motor vectorial encuentra un número mágico y acumula errores y no puede satisfacer el epsilón... Bueno, que quede que no sabes de lo que hablas, mejor renuncia.

[Publicado por: Susurro]

Por mi parte, sospecho que Antonio da por obvio que todos los equipos de trabajo son tan mal armados como improvisados, poco consustanciados, subjetivos e inestables como de los que él parece formar parte.
Cuando se tienen objetivos claros, en algo que se domina y se arma un equipo profesional idóneo, que los comparte y está bien gestionado, no tiene por qué haber mayores dificultades para lograr alcanzar los objetivos propuestos.
El problema surge de plantear objetivos ambiguos ignorando detalles colaterales que pueden malograrlos o plantear serios inconvenientes y severas modificaciones. Junto con coordinadores (líderes) que no tienen verdadero manejo de posibilidades y situaciones (profesionales y personales) con sensata flexibilidad respecto de tiempos de tareas, posibles demoras y pequeñas problemáticas que surgen constantemente; o demasiado presionado y obligado por el lado económico y de tiempos por los que financian y apuran insensatamente. Esto último, es lo que hace que la mayoría, como bien afirmó, terminen las cosas chapuceramente tragándose, junto con el orgullo profesional (y tal vez dignidad), a la sensatez de hacer las cosas bien o renunciar.

P.D.: Respecto a la imperfección de los robots, le sugiero que juegue al ajedrez con la Blue Deep ¡A ver si es más perfecto que esa programación robótica! (Sobre todo qué humano falla, o se equivoca, menos que la misma).

[Publicado por: Antonio]

Los programas los hacen humanos y por tanto están sometidos a los posibles fallos de humanos, pero si se aplican métodos de prueba suficientes y organizados (ya existentes), pueden obtenerse programas robustos a prueba de fallos. Pero, en ultimo extremo apliquemos la cuarta ley de la robótica: "Un robot llegará a ser, como máximo, tan imperfecto como un ser humano".

[Publicado por: Antonio]

Me sospecho que Susurro nunca a estado cerca, y menos dentro, de un equipo de desarrollo. Mucha crítica, pero poco entendimiento.

[Publicado por: FOrejas]

Ignacio, ¡cuanto tiempo!. Gracias por tu comentario. Afortunadamente, ahora hay muchas más técnicas y herramientas para especificar y verificar sistemas (algunas sobre Redes de Petri). Es decir que hoy día habríais tenido más fácil hacer lo que hicisteis hace más de 20 años.

[Publicado por: FOrejas]

Susurro, gracias por tus aportaciones, pero varias cosas:
- Lo que dices sobre lo inadecuado de comparar entre software y otros productos de ingeniería, es cierto. Pero no exactamente por lo que dices. El diseño de un puente, una lavadora o una casa es una actividad tan intelectual como el diseño de un programa. La diferencia está, como dice el artículo, en el carácter continúo o discreto de su funcionamiento.

- Yo no me atrevería a decir sobre Microsoft lo que tú dices. Microsoft, efectivamente, adquirió mala fama hace años. Sin embargo ahora, como señala Jordi Cortadella, invierte mucho en investigación para mejorar la calidad del software.
Por otra parte, MacOS también comete fallos con demasiada frecuencia (de Linux no puedo decir nada por que no lo uso).

- Estoy de acuerdo con los motivos que das sobre por qué se cometen errores. Aunque creo que hay más. Por ejemplo, el puro azar: si al escribir el programa se nos va un dedo y apretamos una tecla equivocada, aparecerá un error. En este caso, muy probablemente el error lo detecte el compilador, pero posiblemente no. De todas formas, la cuestión es que los errores hay que detectarlos y corregirlos.

[Publicado por: FOrejas]

Antonio: si se destinara más tiempo a pruebas, se encontrarían más errores, pero eso no garantizaría que todavía no quedaran. Con respecto de las analogías utilizadas, efectivamente, a un ingeniero de caminos no creo que se le suelan pedir muchos cambios sobre el diseño inicial, pero a un arquitecto sí se le piden. La diferencia básica entre un puente y un chalet y un sistema software es que, como se indica en el artículo, un pequeño error en el diseño de un puente o de un chalet probablemente no se noten. En cambio, el error en el software probablemente se notará. En cuanto a Windows, o cualquier otro sistema operativo, si estuviera bien diseñado, debería de estar protegido contra las aplicaciones que se le instalen.

[Publicado por: Ignacio López]

Fernando, veo que la situación tecnológica del pais a combiado poco, desde que nos conocimos. Tu tratabas de "educar" a tus alumnos y a nuestros programadores, con las especificación y verificación, usando Tipos Abstractos de Datos o sus variantes; yo y el resto del equipo de Felix Vidondo, tratabamos de convencer a nuestros programadores de los Centros de Investigación de la multinacional ITT y de sus ingenierias, con las especificación y verificación de programas concurrentes y distribuidos, usando Redes de Petri (Galileo). Yo no soy un teórico y tengo muchas lineas de código, en casi todos los lenguajes de programación, y opino lo mismo que tu. Para los que te critican les recomiendo que lean el articulo: Experiences in the use of Galileo to design Telecommunication Systems, escrito por mi y por M. Carmen Pelaez (responsable del desarrollo de una de las primeras centrales telefónicas de Radio Movil) y publicado en Advances in Petri Nets 1988. Lectures Notes in Computer Science. Springer-Verlag. Las conclusiones en resumen fueron que estas técnicas permitieron quitar los errores de diseño, mejorar la simplicidad y acortar el tiempo de desarrollo del producto.

Un abrazo

[Publicado por: Jordi Cortadella]

Empiezo a encontrar intresante el debate surgido en este blog sobre los errores en software.

Creo que Fernando se proponía dos cosas: divulgar y concienciar. La Informática ha sufrido una transformación trepidante en las últimas
décadas fruto del aumento exponencial de la capacidad de cálculo y de memoria. De ello tienen la culpa principalmente los físicos del estado sólido que han conseguido seguir el ritmo de la ley de Moore y nos han "regalado" Mflops y Mbytes, creando una "burbuja de cálculo" que pronto entrará en crisis: a la ley de Moore ya le quedan poquitos años.

En este periodo, el desarrollo de las grandes aplicaciones de software se ha realizado frecuentemente con prisas y sin rigor. Hoy en día, la existencia de errores en el software es considerado como normal y asumible. En la mayoría de ciencias e ingenierías, los errores son considerados como inaceptables y catastróficos.

Sin embargo, este rigor se ha mantenido en el diseño del hardware. Actualmente, la verificación formal es una práctica común en la mayoría de empresas que diseñan circuitos nanoelectrónicos (esos circuitos que tenemos en nuestros teléfonos, coches, TVs, marcapasos, audífonos, tarjetas de crédito, relojes, ..., ah, y una pequeña minoría también está en los ordenadores). Hace 20 años, esas empresas no sabían lo que era la verificación formal.

He observado una cierta tendencia a distinguir entre académicos e industriales en este blog. No comparto esta distinción. No es casualidad que empresas de tal calibre como Intel y Microsoft estén contratando a prestigiosos "académicos" para trabajar en temas de verificación formal. Un ejemplo es el de C.A.R. Hoare (premio Turing 1980) trabajando en Microsoft.

Con Fernando, creo que comparto la esperanza de que está práctica también llegue algún día a los diseñadores de software y éstos lleguen a concienciarse de que de sus productos pueden depender vidas humanas, catástrofes ecológicas o la gestión de recursos energéticos críticos. Si bien utilizar verificación formal es difícil y utópico en muchas ocasiones, una metodología apropiada en el diseño de los programas y en los tests de pruebas ayuda a construir software mucho mas fiable.

Sin embargo, esta esperanza contrasta con las tendencias que venimos observando en los planes de estudio de Informática, en los que varias de las disciplinas relacionadas con el rigor y el razonamiento algorítmico, frecuentemente cercanas a las Matemáticas y que intentan inculcar la "esencia" de la Informática, han sido progresivamente relegadas e incluso eliminadas. Cuando nos demos cuenta de este grave error, será difícil recuperar tanto tiempo perdido.

Como ejemplo, los estudiantes egresados de algunas de la Facultades de Informáticas supuestamente "mejores" de nuestro país no sabrán quién es Turing ni cuáles fueron sus aportaciones fundamentales a la Informática. Y estoy de acuerdo con la conclusión de algunos blogeros: Así nos va!

[Publicado por: Susurro]

FOrejas: La comparación con ingenieros de caminos y puentes, me parece inapropiada. Lo material no es comparable a lo intelectual, porque es como hardware y software. Cuando se toma examen a los alumnos ¿se les pide que demuestren físicamente las teorías aprendidas, sometiéndolas a rigurosas y bien variadas pruebas de calidad? ¿O basta con que "funcionen" los conceptos básicos solicitados para obtener el "aprobado"?
Comparto el ejemplo de los fallos del Windows ¿cuántos ignoran que los de Microsoft son legendarios por chapuceros, descuidados y hasta precipitados? ¿por qué se han ganado tanta mala fama? (Claro que, mientras tanto, hicieron gigantesca fortuna inmoral y se convirtieron en dominantes del mercado, gracias a tantos "periodistas" y "críticos especializados" mercenarios o demasiado condescendientes, que facilitaron que continuaran abusando del mercado).
En lo personal, soy un convencido que, en las fallas de programas, hay varios factores que se concatenan algunos entre sí:
1.- Impericia de parte del equipo (pobre formación, insuficiente experiencia práctica).
2.- Atontamiento, saturación intelectual. Son tantas y tantas líneas de texto, que se embotan y el inconsciente comienza a sentir rechazo por revisar detalles. Lo que no se detectó en las dos o tres primeras releídas, esa persona ya no lo detectará más. Precisamente por automatización de lectura y rechazo del inconsciente a mirar como si fuera la primera y muy atenta leída. Detalle que RARO que alguien lo tenga en cuenta o no lo menosprecie.
3a.- Pésimas condiciones de trabajo, así sea por mal clima anímico, o detalles que molesten a una adecuada concentración.
3b.- Apurar la finalización, porque se agota presupuesto o hay expectativa de mercado como fecha de vencimiento. Tal detalle agobia psicológicamente y tienden a ser chapuceros. Total... después se hará un parche.
4.- Menosprecio de las consecuencias de un producto con detalles erróneos. (el "Total... después se hace un parche o nueva versión"). Por dos razones: a) Excusa de lo complejo que es hacerlo y que cualquiera comete "pequeños fallos". b) Sirve de excelente excusa (caso de Microsoft, Adobe, Corel y otras más durante años) para hacer nuevas versiones "mejores y más completas" que, por supuesto, SE COBRARÁN COMO NUEVOS PRODUCTOS. Trampa de casi todas las grandes empresas de software, que desgastaron terriblemente a los clientes usuarios, ganándose pésima reputación.
5.- Orgullo profesional relajado y permisivo. La mentalización más bien inconsciente (por harto común y generalizada), enquistada socialmente, de que "es normal" que los productos de software comiencen con fallas y haya que parchar y parchar hasta con nuevas versiones. ¿Para qué existen los testeadores y las Betas? Si después de una Beta distribuida masivamente el producto continúa con detalles... el proceso falló por irresponsabilidad de alguna o varias partes.
Esto último, se suma al hábito de sostener el pacto impuesto por las muy grandes corporaciones, de fabricar productos con obligada renovación pasado cierto plazo, denunciado varias veces y pongo enlace a una página con video documental de RTVE bien explícito:
http://www.rtve.es/television/documentales/comprar-tirar-comprar/directo/

[Publicado por: Antonio]

El problema real de los fallos de Software es el poco tiempo que se destina a pruebas. Es más cuando se hace a medida el cliente pide continuos cambios sobre algo que todavía no está estable. Siguiendo la analogía del puente y las lavadoras, por un lado en la fabricación del puente no se piden cambios todas las semanas o incluso días que afectan a todo el puente desde su inicio hasta su finalización, por otro a las lavadoras no se le instalan accesorios como a windows que muchas veces son los que provocan los fallos. Me gustaría ver esas lavadoras que no fallan encendidas sin parar durante meses.

[Publicado por: Sergio]

Si lo hago yo si, yo nunca me eqiboco

[Publicado por: FOrejas]

Una pequeña respuesta a Sergio: windows, por poner un ejemplo, es un producto tan vendido como las lavadoras y, sin embargo, falla con demasiada periodicidad. En sentido contrario, los ingenieros de caminos, cuando construyen un puente, lo hacen a medida. Sin embargo, los puentes no se suelen caer

[Publicado por: FOrejas]

Desde los setenta, cuando comenzó a hablarse de la necesidad de usar métodos y técnicas que garantizaran que el software es correcto, es corriente que profesionales de la disciplina critiquen estas tesis como alejadas de la realidad y propias de gente que no sabe lo que es hacer software. Imagino que eso se debe a que se sienten atacados, a que sienten que se les dice que no son buenos profesionales. Sin embargo, no hay en este artículo ningún ánimo de crítica a dichos profesionales. Diseñadores de software hay buenos, malos y regulares (incluso hay incompetentes sin ninguna formación, por eso de que parece que cualquiera puede programar). Y todos cometen errores, porque es imposible construir un software de una cierta entidad sin que haya fallos. La cuestión es que si se usan métodos y herramientas adecuadas, se cometerán menos errores y estos serán detectados y podrán ser corregidos.

Los buenos profesionales ya usan métodos que minimizan la aparición de errores. Son métodos que no tienen nada que ver con la verificación, sino simplemente con la forma en que se diseña y organiza un sistema software. Se ha de señalar que, a menudo, cuando aparecieron estos métodos, fueron criticados por profesionales.

Los profesionales, como no puede ser de otra manera, hacen lo que les pide la empresa en que trabajan. Y las empresas, salvo algunas que hacen software crítico, no consideran necesario (más bien al contrario) introducir el uso de técnicas de verificación, o de otro tipo, que hagan el software fiable. Por eso, en este artículo, sí hay una cierta crítica a las empresas. Si a las empresas les saliera caro hacer productos que en otros ámbitos serían considerados defectuosos, la situación ya habría cambiado, o estaría en vías de cambio. Porque, es un hecho que se puede hacer software sin fallos, como muestra el ejemplo del metro de París o que, si consulta en internet, es difícil encontrar desastres ocasionados por errores de software desde finales de los 90.

[Publicado por: Sergio]

En general, el artículo me ha parecido correcto. Algunos puntos críticos:

A diferencia de la ingeniería tradicional, que responde por lo general a un paradigma de producción en masa (ej. lavadoras), el software es algo que suele desarrollarse a medida para cada cliente. Este es un aspecto fundamental que justifica lo extremadamente difícil (y caro) que es desarrollar software sin errores y que he echado en falta en el artículo.

Siguiendo con la analogía de las lavadoras, imaginémonos por un instante que cada usuario pidiera una lavadora con unas características concretas (ej. cuatros botones, dos bombos y una pantalla digital en la parte trasera). Esto encarecería de forma significativa el producto y, sin duda, aumentaría el número de errores.

Por último, no creo que la verificación formal sea infalible pues depende de una especificación formal de los requisitos realizada por seres humanos y que, por tanto, podría contener errores. En otras palabras, que el software desarrollado implemente correctamente los requisitos no significa que el programa haga lo que el cliente espera del mismo.

[Publicado por: David]

No se a que viene sacar esta confrontación entre académicos y profesionales del software. El País, no va dirigido a ninguno de estos dos colectivos en particular, y esta entrada del blog tampoco.

Personalmente, encuentro interesante el contenido, simplemente es una reflexión sobre si se pueden hacer programas sin errores.

[Publicado por: Macario Polo Usaola]

LA MÁQUINA CICLADA
Le ponía nervioso pensar que había máquinas de Turing aceptadoras de lenguajes –que son unos dispositivos que realmente no existen pero que están ahí, como los números irracionales, que tienen infinitos decimales, o los complejos, que tienen parte imaginaria– que se habían ciclado porque no reconocen como perteneciente al lenguaje la palabra a la que habían sido aplicadas.
Él, en un examen de “Teoría de Autómatas”, construyó cierta máquina que se le pedía en un problema y que debía reconocer las palabras generables por una cierta expresión. Un rato antes transformó en determinista un autómata finito que en el enunciado no lo era, demostró en un pispás que el lenguaje anbn es no regular si n tiende a infinito y planteó, para una gramática independiente del contexto, un elegante reconocedor no recursivo con sólo dos símbolos de lectura adelantada. Pero se detuvo más de una hora a pocos centímetros del folio pensando, diseñando y dibujando versiones diferentes de la máquina de Turing del ejercicio cuatro.
Aplicó por fin con éxito el producto de sus arduos esfuerzos a media docena de palabras de muestra, y entonces entregó al profesor su examen con el convencimiento de que todo en él era perfecto. Salió por tanto creyendo que su máquina procesaba, aceptaba y paraba, y con esta satisfacción y entre risas y chistes pagó a sus compañeros la ronda que le correspondió por turno; pero horas más tarde, tumbado boca arriba en la cama de su piso de estudiante, repasó mentalmente el examen y halló un contraejemplo que obligaba a la máquina a moverse sin parar, una vez a la derecha, una vez a la izquierda.
Cuando esta noche se ha acostado ha vuelto a escuchar, como todas las noches desde hace cinco años, el virtual quejido de la cabeza de lectura de su máquina, que sigue aún en marcha, dale que te pego, pasando sin fin por encima de la misma letra.
FIN

[Publicado por: Juan Manuel]

Una aclaración: Juan Manuel y Juanma somos individuos homónimos pero diferentes.

[Publicado por: Susurro]

Si bien no me pareció buen comienzo la fallida comparación de programas con lavadoras, tampoco estoy de acuerdo con quien MAL CONFUNDIÓ "fases" con "etapas".
Juanma o Juan Manuel: ¿Te habría quedado más claro si en lugar de "fases" hubiera expresado algo así como "hacer un programa tiene dos aspectos básicos a considerar: La parte previa, de planteo en detalle de qué se quiere hacer y, luego, la de ponerse a hacerlo."?
Porque tú estás TAN ESQUEMATIZADO que ya no admites otras posibles acepciones o usos a ciertos términos como "fases"; "etapas"; etc.
Te falta mucha COMPRENSIÓN DE LECTURA ajena a lo que sea "programación".
Respecto al artículo en sí, a mi me parece muy válido en general, aunque se nota que quien lo escribió NO ESTÁ MUY ACOSTUMBRADO a explicar las cosas a los legos en esta área, pero lo considero como un intento bastante bien logrado.
¿Qué podría haber mejorado?
Definir mejor la clase de lector a la cual se dirigió. Porque resulta "ni" en cuanto a alumnos o entendidos en programación, respecto a legos. Es decir: De a momentos es general, como para legos absolutos y, de a momentos, da detalles para técnicos, como las "pesadas" alusiones a investigadores premiados con el Turing en diferentes años que ¿a cuántos, o a quiénes importa dentro del tema desarrollado? Eso en el artículo queda más como "relleno" que hace más pesado seguir la hilación.

[Publicado por: Juan Manuel]

Conozco a Fernando personalmente y es uno de los mejores profesores que he tenido y me merece el más grande de mis respetos.

Ello no es óbice para que opine que muchas veces la distancia entre la "informática de investigacioón que permite llegar a ser catedrático" y "la informática real del día a día y que permite que empresas reales creen valor" sea demasiado grande.

Solamente hay que mirar la fichas, hechas por catedráticos mayormente, de la ingeniería en informática para darse cuenta de lo que conocen (algunos) de la informática actual.