Programar no es sólo hacer matemáticas
Cada cierto tiempo se oyen voces críticas sobre la falta de rigor con la que trabajan la mayoría de los programadores. La falta de métodos formales de verificación y benchmarking produce muchos programas lentos y nada fiables. Pero ¿es la programación sólo una extensión de las matemáticas por otros medios?
por Sergio Montoro Ten, 30 enero 08
El pasado 9 de diciembre Robert Scoble tuvo la en apariencia inocente ocurrencia de preguntar en su blog porqué el software de gestión no puede ser igual de sexy que el de consumo Más de cien comentarios y acusaciones de que no entiende el software empresarial como la de Michael Krigsman pusieron de manifiesto que con la pregunta Scoble tocó hueso.
En defensa de Robert salió el reputado Nicholas Carr, diciendo que es Krigsman quien no entiende nada de software y que creando una falsa dicotomía entre el software de consumo y el software de gestión lo único que se consigue es dar a los fabricante de éste último la excusa perfecta para seguir creando aplicaciones difíciles y desagradables.
El flame war continuó con otra andanda de Krigsman argumentando que Carr vive en un mundo de fantasía donde es posible emplear tiempo en dotar a las aplicaciones empresariales de pijadas totalmente innecesarias antes que atender a los requisitos funcionales básicos, las prioridades del negocio, el soporte de aplicaciones legacy y las limitaciones tecnológicas de la infraestructura.
Pero el clímax de esta historia lo he alcanzado leyendo una referencia en el blog de Agustín González-Quel al artículo Where Are the Software Engineers of Tomorrow? de Robert B.K. Dewar y Edmond Schonberg. En el cual los papás de ADA despotrican abiertamente contra el uso de Java para fines pedagógicos en las universidades, argumentando que el uso de Java es nocivo porque en vez de incentivar la reducción de la complejidad formal de procesos a un pequeño conjunto de operaciones primitivas, lo que Java fomenta es la resolución de problemas cual fontanero en ferretería tirando de todo lo que pilla en lo cajones a modo de frameworks y librerías que acaban convirtiendo al estudiante en un ignorante total del coste computacional de lo que está haciendo y de nociones imprescindibles para la programación como son los punteros.
Es verdad que entre los programadores más jóvenes hay una excesiva tendencia a abusar de las librerías. Cogen unos mágicos tags de Java y convierten una JSP que antaño era fácilmente legible y rápida en un amasijo de abreviaturas crípticas que tiran contra lentísimos servlets que hay que recompilar cada vez que quieres tocar algo. O se pillan Castor (o lo que sea) y unas DTDs y te dejan varios cientos de clases basura pregeneradas para leer un archivo XML de 10 líneas. Es decir, a veces matan moscas a cañonazos simplemente porque lo que tienen a mano para combatir insectos es un cañón.
Pero no es menos cierto que Java ha supuesto un gran salto cualitativo hacia adelante en la programación. Quien ha programado con punteros se acuerda de que en los 80 y 90 estábamos hartos de ellos y de las pérdidas de memoria que siempre acaban provocando. Y fue por eso que acabamos quitándolos en los lenguajes modernos. Hubo un tiempo en el que se cuestionaba la eficiencia y la viabilidad de usar recolectores de basura como el de la máquina virtual de Java, cuya utilidad y eficacia ahora ya nadie se atreve a poner en duda. Cuando no teníamos esas librerías ballena de Java, nos dedicábamos a escribirlas ¿Alguien se acuerda de ACE o de Rogue Wave para C++?
Por supuesto que hay muchas cosas muy mejorables en Java. Pero para mi Java ha sido un avance y no un retroceso.
Sobre si el software empresarial tiene que funcionar bien y no necesariamente ser bonito opino que: nadie puede ser buen programador si ignora la reacción emocional que sus programas causan en los usuarios. Escribimos programas para que alguien los use (o los sufra). Bueno, si, algunos escriben módulos de control para satélites, pero no me refiero a ese tipo de software, sino al típico software de gestión que debe necesariamente interactuar con humanos.
Los que reclaman más métodos formales y algebraicos y menos giliflauteces, deben entender que la programación no es simplemente una variante de las matemáticas, porque en el momento en que entra el juego el factor humano, la idoneidad del programa realizado deja de ser rigurosamente medible.
En un mundo utópico los programas son bellas estructuras matemáticas y el arte de programar consiste en emplear el intelecto para reducir la complejidad, abstraer y sintetizar.
Pero en el mundo real las cosas están pensadas para ser simples, porque si fueran complejas no podríamos manejarlas en el día a día. Las herramientas están pensadas para que le des al botón de crear formulario, pegues unos cuantos controles visuales dentro, escribas un poco de código para procesar los eventos y a las seis te vayas a tu casa a jugar con tus hijos sin tener ni la menor idea de lo que es un puntero.
Y los usuarios no sólo quieren que el software funcione, quieren que mole y que les divierta. Porque ¿quién dijo que el daño económico que causa un bug es peor que el daño psicológico que causa no poder poner la foto de tu perro como fondo de pantalla?
Por último, haré una afirmación aún más radical, lo que diferencia a un programador bueno de uno sobresaliente no es su capacidad para buscar soluciones lógicas, sino su capacidad para buscar soluciones ilógicas. Me explico: cuando tiene delante un problema que tiene pies y cabeza, cualquier ingeniero cualificado puede atacarlo aplicando alguna determinada metodología y, con el paso del tiempo, tarde o temprano lo acabará resolviendo. Pero, de vez en cuando, se presentan problemas totalmente desconcertantes y aparentemente sin sentido. Puede, por ejemplo, que el ordenador haya sido infectado por un virus sibilino. Entonces es posible perder horas persiguiendo un bug fantasma hasta que alguien llega y dice ¡hey si no es el programa lo que funciona mal entonces debe ser otra cosa! y con dicha hipótesis ad-hoc completamente infundada dispara un proceso de pensamiento lateral de búsqueda de soluciones en las que no se había pensado. Algo así como cuando alguien dijo ¡hey, y si deterioramos la calidad de la imagen? Y entonces se inventó JPEG (sin menosprecio de su fundamento en la teoría de información) o cuando Steve Jobs se pregunto ¡hey, porqué todas las letras de la pantalla tienen que ser de ancho fijo? Los programadores comunes pierden horas buscando una explicación aparente razonable a un problema que les trae muertos. Los programadores de élite huelen el problema y buscan un atajo, es casi como si diagnosticaran el error con la punta de su nariz antes que con el cerebro.