Hoy he reservado tiempo para leer el discurso de Dijkstra: "The humble programmer" (El programador humilde). Quiero compartir esta breve reflexión porque hay un párrafo que me ha recordado aquello de que para un martillo todo son clavos o ¿cómo nuestras herramientas terminan moldeando nuestros desarrollos?
¿Cuántas veces hemos llevado al límite nuestra recién aprendida herramienta martillo.io? Encajando desarrollos que fácilmente podrían haberse llevado a cabo con técnicas y tecnologías más adecuadas. Podemos hablar incluso del uso de frameworks, arquitecturas y metodologías como martillos; también infraestructuras diseñadas con martillo, ..., y seguro que podemos hablar de más casos similares y en otras profesiones.
Todo esto parte de uno de los argumentos de los seis que lista, para hacer notar que nuestro objetivo no es hacer programas sino construir soluciones que obtengan el comportamiento deseado. Este quinto argumento ha sido la base de esta breve reflexión.
Quien tenga la curiosidad del texto completo al final encontrarás el enlace.
Edsger W. Dijkstra
El programador humilde
(...)
El quinto argumento tiene que ver con la influencia de la herramienta que estamos tratando de usar sobre nuestros propios hábitos de pensamiento. Observo una tradición cultural, que probablemente tiene sus raíces en el Renacimiento, de ignorar esta influencia, considerar la mente humana como el maestro supremo y autónomo de sus artefactos.
Pero si empiezo a analizar los hábitos de pensamiento de mí mismo y de mis semejantes, llego, me guste o no, a una conclusión completamente diferente, a saber: Que las herramientas que estamos tratando de usar y el lenguaje o la notación que estamos usando para expresar o registrar nuestros pensamientos, ¡son los principales factores que determinan lo que podemos pensar o expresar!
El análisis de la influencia que los lenguajes de programación tienen en los hábitos de pensamiento de sus usuarios, y el reconocimiento de que, por ahora, la capacidad intelectual es, con mucho, nuestro recurso más escaso, juntos nos dan una nueva colección de criterios para comparar los méritos relativos de los distintos lenguajes de programación. El programador competente es plenamente consciente del tamaño estrictamente limitado de su propio cráneo; por lo tanto, aborda la tarea de programación con total humildad y, entre otras cosas, huye de los trucos ingeniosos como de la peste.
En el caso de un lenguaje de programación conversacional bien conocido, me han dicho desde varios lados que tan pronto como una comunidad de programación está equipada con un terminal para él, ocurre un fenómeno específico que incluso tiene un nombre bien establecido: se llama "las frases de una sola línea". Toma una de dos formas diferentes: un programador coloca un programa de una línea en el escritorio de otro y con orgullo dice lo que hace y agrega la pregunta "¿Puedes codificar esto con menos símbolos?", ¡Como si tuviera alguna relevancia conceptual! - o simplemente preguntar "¡Adivina qué hace!". De esta observación debemos concluir que este lenguaje como herramienta es una invitación abierta a trucos ingeniosos, y aunque exactamente esta pudiera ser la exposición pública de algunos de los recursos disponibles de aquellos a quienes les gusta mostrar cuán inteligentes son, lo siento, pero debo considerar esto como una de las cosas más condenatorias que se pueden decir sobre un lenguaje de programación.
Otra lección que deberíamos haber aprendido del pasado reciente es que el desarrollo de lenguajes de programación “más ricos” o “más poderosos” fue un error en el sentido de que estas monstruosidades barrocas, estos conglomerados de idiosincrasias, son realmente inmanejables, tanto mecánica como mentalmente. Veo un gran futuro para lenguajes de programación muy sistemáticos y muy modestos. Cuando digo "modesto", quiero decir que, por ejemplo, no solo la "cláusula for" de ALGOL 60, sino incluso el "bucle DO" de FORTRAN podrían verse expulsados por ser demasiado barrocos.
He realizado un pequeño experimento de programación con voluntarios realmente experimentados, pero algo bastante inesperado apareció. Ninguno de mis voluntarios encontró la solución obvia y más elegante. Tras un análisis más detallado, esto resultó tener una fuente común: su noción de repetición estaba tan estrechamente relacionada con la idea de una variable controlada asociada que se fuera incrementando, que se bloquearon mentalmente sin poder ver lo obvio. Sus soluciones fueron menos eficientes, innecesariamente difíciles de entender, y les llevó mucho tiempo encontrarlas. Fue una experiencia reveladora pero también impactante para mí.
Finalmente, en un aspecto, uno espera que los lenguajes de programación del mañana difieran mucho de lo que estamos acostumbrados hasta ahora: y en un grado mucho mayor que hasta ahora, deberían invitarnos a reflexionar en la estructura de lo que escribimos, en todas las abstracciones necesarias para enfrentar conceptualmente la complejidad de lo que estamos diseñando.
Hasta aquí en cuanto a la mayor adecuación de nuestras herramientas futuras, ha sido la base del quinto argumento.
Como comentario adicional, me gustaría insertar una advertencia para aquellos que identifican la dificultad de la tarea de programación con la lucha contra las deficiencias de nuestras herramientas actuales, porque podrían concluir que, una vez que nuestras herramientas sean mucho más adecuadas, la programación ya no ser un problema. La programación seguirá siendo muy difícil, porque una vez que nos hayamos liberado de la circunstancia engorrosa actual, nos encontraremos libres para abordar los problemas que ahora están más allá de nuestra capacidad de programación.
(...)
Créditos
ACM Turing Lecture 1972
(EWD340) The Humble Programmer by Edsger W. Dijkstra
https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
Fuente traducción: http://nummolt.blogspot.com/2019/08/el-programador-humilde.html