Releyendo los agresivos comentarios de un personaje pseudo-anónimo respecto del artículo sobre UML, recordé un excelente manuscrito de Edsger Dijkstra llamado «Respuestas a preguntas de estudiantes de Ingeniería de Software» (EWD 1035).
Para facilitar su difusión (y para tenerlo siempre a mano), decidí traducirlo. ¡Que lo disfrute!
Respuestas a preguntas de estudiantes de Ingeniería de Software
[La reconstrucción aproximada de las preguntas se deja como ejercicio al lector.]
- Los aparatos no son necesariamente una mejora. Véase la sucesión
Pizarrón -> Proyector de transparencias -> Power Point - Y no necesito perder mi tiempo con una computadora sólo porque soy un científico de la computación. [A los investigadores en medicina no se les exige sufrir las enfermedades que investigan.]
- No es el negocio de la ciencia de la computación el promover la «computerización», digamos, desarrollando aplicaciones exigentes para crear un mercado para la próxima generación de hardware. [A los investigadores en medicina no se les pide desarrollar nuevas enfermedades para crear un mercado para nuevos productos farmacéuticos.]
- No es la tarea de la Universidad el ofrecer lo que la sociedad pide, sino lo que la sociedad necesita.
[Las cosas que la sociedad pide son por lo general comprendidas, y no se necesita una universidad para eso. La universidad debe ofrecer lo que nadie más puede proveer.] - Estamos delineados por las herramientas que utilizamos, en particular: los formalismos que usamos definen nuestros hábitos de razonamiento, para mejor o peor, y esto significa que debemos ser muy cuidadosos en la elección de qué aprendemos y enseñamos, ya que desaprender no es posible.
[Hace varios años, si pudiera usar un nuevo asistente, un prerrequisito sería «Sin exposición previa a FORTRAN». En las escuelas de Siberia, la enseñanza del BASIC no estaba permitida.] - Un programador debe ser capaz de demostrar que su programa tiene las propiedades requeridas. Si esto se deja para más adelante, es seguro que no será capaz de cumplir con su obligación: sólo si permite que esta obligación influencie su diseño, existe la esperanza de que pueda cumplirla. Solamente verificar a posteriori le deniega esa sana influencia y por lo tanto es poner el carro delante del caballo, pero es exactamente lo que ocurre en las casas de software donde «programación» y «aseguramiento de la calidad» («quality assurance») son hechos por grupos distintos. [No hace falta decirlo, esas casas entregan productos sin garantía.]
- Las técnicas requeridas para el razonamiento efectivo son bastante formales, pero mientras la programación sea hecha por gente que no las domina, la crisis del software permanecerá entre nosotros y será considerada una enfermedad incurable. Y ya sabe lo que provocan las enfermedades incurables: abren las puertas a curanderos y charlatanes, quienes en este caso toman la forma de gurús de la Ingeniería de Software.
- Algunos de ustedes dudan que las ya mencionadas «técnicas del razonamiento efectivo», agradables como lo son para programas pequeños, sean escalables -cito- «dado el desalentador tamaño y la escarpada complejidad de muchos programas». Bien, serán inútiles si se usan para desenmarañar el lío horrendo producido por un grupo de programadores incompetentes y desorganizados. Su poder se manifiesta en la etapa de construcción, donde (i) tienden a producir textos mucho más cortos de los que se producirían de otra forma y (ii) la longitud de las derivaciones de programas tienden a crecer no mucho más que linealmente con la longitud de los programas derivados. Finalmente, los programas así producidos son infinitamente mejores que la basura usual.
- No debemos olvidar que los programadores viven en un mundo de artefactos, un hecho que los distingue de la mayoría de los demás científicos. El programador no debe preguntar qué tan aplicables son las técnicas de buena programación, debe crear un mundo en el cual son aplicables; esta es la única manera de producir un diseño de alta calidad. A esto debo agregar una cita de EWD898 (1984):
«Las capacidades de las máquinas nos dan lugar en abundancia para hacer un lío. ¡Oportunidades ilimitadas para ensuciar las cosas! Desarrollar la disciplina intelectual austera de mantener las cosas lo suficientemente simple es, en este entorno, un desafío formidable, tanto técnica como educativamente.» - En respuesta a las preguntas de por qué enseñamos cosas inútiles que la industria ignora, los refiero a EWD920 (1985). Permítanme citar un párrafo:
«Volviendo a la pregunta original: ¿puede la ciencia de la computación salvar a la industria de la computación? Mi respuesta es «Si la industria de la computación puede ser salvada, sólo la ciencia de la computación puede hacerlo». Pero puede tomar mucho tiempo antes de que la industria de la computación -en particular, las compañías bien establecidas- compartan esta visión. Casi con seguridad tomará más que el periodo limitado por el cual planifican sus futuros. Mientras tanto, el mundo académico -que tradicionalmente planifica mirando mucho más adelante- no tiene elección. Tiene que refinar y enseñar al máximo de sus habilidades cómo debe ser hecha la computación; si cediera a la presión de propagar las malas prácticas actuales, sería mejor que quebrara.«Pero para destacar cuánta paciencia necesitamos, déjenme darles otra cita antigua (de 1988)
«Muy poca gente reconoce que la alta tecnología tan celebrada actualmente es esencialmente una tecnología matemática.«
(del reporte «2nd David», llamado así en honor al director del comité, Dr. E. E. David Jr.)
- No, me temo que la ciencia de la computación ha sufrido la popularidad de Internet. Ha atraído a una cantidad creciente -¡por no decir abrumadora!- de estudiantes con muy poca inclinación científica, y en la investigación sólo ha consolidado la prevaleciente (y algo vulgar) obsesión con la velocidad y la capacitdad.
- Si, comparto su preocupación: cómo programar bien -aunque un tema enseñable apenas se enseña. La situación es similar en las matemáticas, donde el plan de estudios explícito está confinado a los resultados matemáticos; cómo hacer matemáticas es algo que el estudiante debe absorber por ósmosis, como el hablar. Una razón para preferir argumentos de cálculo mediante la manipulación de símbolos, es que su diseño puede enseñarse mucho mejor el diseño de argumentos verbales/pictóricos. La introducción a gran escala de cursos de tal metodología de cálculo, sin embargo, encontría problemas políticos insalvables.
- En el negocio del software hay empresas para las cuales no está claro que la ciencia pueda ayudarlas. Que la ciencia debería intentarlo tampoco está claro.
Austin, 28 de noviembre de 2000
prof. dr. Edsger W. Dijkstra
Departamento de Ciencias de Computación
Universidad de Texas
Austin, TX 78712 – 1188
USA
Gracias por la traduccion, y como siempre exelente articulo de un exelente cientifico!
Le guste a Dijkstra o no, en la «práctica» del desarrollo de software no es posible efectuar verificaciones matemáticas de todos los programas.
Tampoco coincido con que el programador es un científico. El programador es algo nuevo, no equiparable ni a un ingeniero, ni a un científico. En todo caso, es más parecido a un escritor.