Políglotas

En la anterior entrada del blog mencionaba lo interesante que resulta –a mi parecer– poseer un perfil profesional en el que, aunque nos hayamos especializado en una determinada materia o tecnología, dominemos un amplio espectro de conocimientos. A lo largo de los años las distintas batallas diarias nos hacen ver cómo hasta lo que menos podríamos imaginarnos nos ayuda a resolver un determinado problema. En muchas ocasiones son, en efecto, estos conocimientos que podríamos denominar periféricos los que nos ayudan a dar con la solución que andamos buscando.

Mientras escribía sobre la especialización y la diversificación recordaba un artículo escrito hace unos años por Paul Graham en su blog, “Beating the Averages”, en el que hacía referencia a “La paradoja de Blub”. Si no la conocéis, os invito a leer el artículo completo de Graham y, de cualquier modo, aquí presento un escueto resumen de la mencionada paradoja.

Supongamos que Blub es un hipotético lenguaje de programación de propósito general que nos permite resolver diversos tipos de problemas y para el que existen, al menos, un lenguaje menos potente que él y otro que lo es más. Imaginemos a un programador de Blub que, por ejemplo, conoce la existencia del ensamblador y del lenguaje Pascal. Para nuestro desarrollador está claro que el ensamblador no es lo suyo (para eso están los compiladores) y, desde la perspectiva de Blub, Pascal no aporta mucho más que una sintaxis desconocida para él y, aunque desconoce a qué corresponde tal o cual función de Blub, intuye que Pascal no le aporta demasiado. También ha visto algo de Java, un lenguaje que, en este caso, es más potente que Blub, pero dado que “piensa en Blub”, no es capaz de apreciar la potencia de Java como lenguaje. Es decir, que si bien nuestro programador es capaz de, mirando “hacia abajo”, darse cuenta de esos lenguajes son inferiores a Blub, su desconocimiento hace que sea incapaz de mirar “hacia arriba” y apreciar las ventajas de otros lenguajes más potentes.

Esta paradoja fue usada por Graham para ilustrar la relación existente entre diversos lenguajes de programación y la completitud de Turing y, en particular, para hacer ver lo difícil que resulta comparar dos de ellos entre sí cuando no se conoce alguno de ellos en profundidad.

Volviendo al tema de la anterior entrada, cuanto más amplio y diverso sea nuestro perfil, mejor preparados estaremos para solucionar los problemas que se nos presenten por delante y más acertadas serán nuestras decisiones sobre qué tecnología o qué herramientas usar para construir la solución pensada. E incluso para elaborarla, por qué no. Quienes dominan varios idiomas y mejoran sus conocimientos filológicos son capaces de inferir el significado de un mensaje emitido en un idioma extraño para ellos si es afín a alguno de los que conocen, e incluso afirmar si uno de ellos ha más evolucionado que el otro desde una raíz común o si deriva de aquel. Con los lenguajes informáticos ocurre otro tanto: aunque la mayoría de ellos permite ofrecer soluciones teóricas a los problemas con que nos encontremos, algunos permitirán ponerlas en práctica de un modo más eficiente, ya sea por la plataforma sobre la que se sustentan o por el enfoque que posee el propio lenguaje.

Lo anterior, que parece de Perogrullo, no debe de serlo tanto cuando a lo largo de los años me he encontrado con gente tan acérrima seguidora de un determinado lenguaje o familia de tecnologías (“Jafa forever”, “Microsoft a muerte”, …) que era incapaz de admitir que montar un CMS para gestionar un blog era más rápido y eficiente usando PHP que Java sobre un Apache Tomcat o que, a largo plazo, un ERP en .NET Framework sería probablemente más fácil de mantener y extender que de hacerlo en Python, por ejemplo. Aunque a priori un desarrollador de Bulb tendrá listo su programa en menos tiempo si lo hace en “su” lenguaje antes que en otro que no domine, a largo plazo sus decisiones y forma de programar estarán supeditadas a aquello que le es familiar, y cuanto más estrecho sea su campo de visión más limitadas estarán sus propuestas.

Lo expuesto, por supuesto, sería extensible a multitud de aspectos de nuestra profesión, y no solamente a la programación. Y, “aunque los experimentos haya que hacerlos con gaseosa”, no es menos cierto que de vez en cuando no está de más ser un poco innovador y abrirse a nuevas experiencias. Además, resulta divertido.

Propongo así ser políglotas tecnológicos.