La Ley de Wirth, la «Ley de Moore inversa» del software
22 mayo, 2014Para la mayoría de usuarios, lo más importante en un ordenador es «que sea rápido». No hace tanto, los ordenadores se anunciaban casi exclusivamente a golpe de megahercio. Y lo último que suele escuchar un ordenador antes de irse al cementerio digital es «va muy lento, hay que cambiarlo».
Pero la realidad es que el software también juega un papel muy importante en el rendimiento de un ordenador. Niklaus Wirth, padre de lenguajes de programación como Pascal o Modula, se lamentaba en 1995 (en un artículo titulado «A Plea for Leaner Software«) de dos tendencias que apreciaba en los productos de software:
– El software se expande para ocupar todo el espacio disponible.
– El software se ralentiza a mayor velocidad de lo que se acelera el hardware.
La segunda de estas afirmaciones resultaba un contrapunto simpático a la Ley de Moore, que observó en 1965 que el número de transistores en un circuito integrado se dobla aproximadamente cada 24 meses. Quizás por eso, la segunda afirmación fue bautizada popularmente como «Ley de Wirth«.
Casi 20 años después, lo acertado de estas observaciones resulta evidente para cualquiera. Cuando pasas de instalar un sistema operativo en diskettes, a hacerlo en CD y luego en DVD… empiezas a sospechar que algo está pasando. También sería un curioso experimento coger a un usuario de 1994 y enseñarle el tiempo que tarda en arrancar un ordenador actual: ahora está acabando de instalar un parche que se instaló ayer, ahora está cargando mi configuración, ahora ya está todo pero todavía no puedo ni mover el ratón, … Después de esto, intentar explicarle que nuestros ordenadores actuales son mucho más potentes que el suyo… bueno, sería complicado como poco.
Y es una pena, porque a la vez que los ordenadores se hacen más potentes… cada vez usamos dispositivos más y más pequeños. Un teléfono tiene una fracción de la potencia de un equipo de sobremesa, y los dispositivos wearable (¿computadoras corporales o vestibles? que alguién se invente un término mejor, por favor) tienen menor potencia todavía. No iría mal que el software supiera sacar partido a recursos de cálculo, memoria y energía muy limitados.
Dada esta diferencia de tendencias tan importante, no falta quién afirma que el desarrollo de software tiene mucho que aprender del desarrollo de hardware. En la misma línea, también hay quién dice que los desarrolladores tienen mucho que aprender de los arquitectos… y no lo dice una persona cualquiera, sino Leslie Lamport, ACM Turing Award de 2014. Pero claro, los arquitectos no trabajan en las mismas condiciones que los desarrolladores. De verdad que no. Y lo mismo puede aplicarse a los médicos y otros profesionales.
En un tono más serio y meditado, Edsger W. Dijkstra (sí, ése Dijkstra) hizo una reflexión sobre por qué desarrollar software es complicado, con el título «Why is software so expensive? An explanation to the hardware designer. Recomiendo encarecidamente su lectura*, aunque para los impacientes me quedo con esta perla:
«algunos programadores no saben cuán dañiña es la complejidad, ni cuánta complejidad puede llegar a evitarse si te preocupas por ello»
Y ahora disculpen, Doctores Lamport, Wirth y Dijkstra. Les dejo que tengo que descargar unos 2 Gb de parches del sistema operativo…
* Así como del resto de sus escritos, porque todavía siguen vigentes. Al parecer, hay verdades que no tienen fecha de caducidad.
** La persona de la foto es Niklaus Wirth, enhorabuena a l@s que habéis acertado. L@s que no, me hacéis un «HelloWorld» en Pascal y una lista doblemente encadenada en Modula-2 como deberes.
Hola a todos.
«Conocí» al buen doctor Wirth y su «Algoritmos+estructuras de datos=Programas» en el año 89, cuando comencé esa uni que ahora me obceco en terminar. Por cierto, la traducción al castellano de aquella época tenía algunos errorcillos… cosas que pasan.
El caso es que con él aprendí algorítmica y programación estructurada… y a pensar no sólo en cómo hacer las cosas, sino en cómo las cosas podían hacerse mejor, más pequeñas y/o rápidas, según el caso. Eso me marcó, y aún hoy, cuando escribo un código, lo voy optimizando mientras lo escribo, no después, y cuando lo termino no suelo volver sobre él para optimizarlo. Manías de cada uno… ¿Seré un artesano? Una vez conseguí hacer un spooler de impresora programable para MS-DOS en sólo 980 bytes. Tardé una semana, pero quedó impecable y no volví a modificarlo nunca.
Ahora veo a los nuevos programadores y tengo que insistirles en que se preocupen por hacer las cosas optimizadas, que no vale con que funcionen. Pero claro, eso implica conocer a fondo el lenguaje, la arquitectura, el run time/framework, la base de datos y mil cosas más de las que hacían falta antes para hacer más o menos lo mismo (según el caso). Y también implica tener el hábito compulsivo de simplificar…
Esto me llama la atención y me hace pensar que la complejidad es un monstruo que, simplemente, se retroalimenta y crece como la hiedra a poco que te descuides.
Creo que una de las causas es que la informática, como negocio, busca beneficios cuanto más rápido, mejor… y eso está en contraposición a hacer las cosas con el debido detenimiento, cuidado y atención. De esto se deriva que en la mayoría de los proyectos, con hacer que las cosas funcionen (más o menos), ya se tiene suficiente.
Leonardo da Vinci dijo algo así «como que la simplicidad era la máxima perfección». Yo suelo decir: «Simplifica, idiota». Visto que el software tiende a complicarse «por causas naturales», dedicar tiempo a pensar en simplificar los diseños, arquitecturas y desarrollos es la única solución. Aunque, por supuesto, es más cara porque requiere tiempo, tiempo para pensar.
Saludos.
Miguel Ángel Bueno Sánchez
mbuenos@uoc.edu
Muchas gracias por compartir tu experiencia, Miguel Ángel. Y totalmente de acuerdo con tus opiniones sobre la simplicidad.
Un saludo,
Robert