Infraestructuras digitales

Este artículo fue publicado en el Blog de Bogodev el día 18 de Mayo de 2013. Vínculo

Me inicié en la programación hace ya muchos años. El Integer Basic en un Apple II y el Microsoft Basic del MS-DOS 3 en un Tandy 1000 fueron mis primeros pasos en lo que llamamos desarrollo. Luego otros lenguajes me acompañarían, y mirando hacia atrás, los lenguajes de programación han cambiado bastante; unos permanecen en el debate y otros han sido relegados, superados o solamente olvidados.

Creo que siempre lo he considerado un hobbie. Siempre me ha parecido divertido tratar de resolver problemas a través de instrucciones que escribo en una pantalla para que luego sean ejecutadas por el ordenador. E igual, a veces es reconfortante sentirse estúpido después de pasar varias noches buscando un error en el mismo renglón para darse cuenta de que el problema era la falta de un signo en el anterior.

Aunque no me convertí en un programador de los que sólo usan VI y son capaces de aprenderse y reproducir las miles de combinaciones de teclas (cual si estuvieran tratando de usar el modo Dios de DOOM o de lograr ganar todas sus armas – sí, creo que ya estoy algo viejo si no lo han notado) para lograr que el programa cumpliera la orden de guardar un archivo, de compilar, de revisar la sintaxis o de cualquier otra orden; aprendí que para programar a veces era necesario leer y buscar información sobre esas funciones que servían para el cometido esperado. Y me di cuenta que muchas veces debía gastar mucho tiempo en resolver problemas la primera vez y que en adelante podría ser fácil si se era capaz de aprender de esas primeras respuestas correctas.

Con el paso del tiempo, para que fuera más eficiente el uso del lenguaje de programacion, puesto que muchos de los problemas basicos vendrian ya resueltos, empezaron a surgir diferentes infraestructuras digitales (o frameworks – no sé quién propuso esa traducción en Wikipedia, aunque no me disgusta) para cada uno de los lenguajes que iban existiendo. La idea de no tener que resolver temas complejos en el desarrollo, sino trabajar más en los requerimientos ha sido difundida y alabada por muchos. Resolver más problemas de forma que de fondo, podría decir.

Ya llegado a este punto el desarrollador no se enfrenta a un lenguaje completo. ¿Aprende a solucionar todos sus problemas? Quizás a resolverlos con las ayudas, pero no sin ellas. Y me refiero a ese «programador» que es capaz de enfrentar el lenguaje sin complementos, de entenderlo y decidir por sí mismo si java es o no es, si php podría haber sido, si ruby es el “cielo”, si python funciona, si perl fue menospreciado.

Pero cuando faltan esas ayudas: ¿qué? No se abarca ni se conoce al lenguaje, pues ya las herramientas han solucionado muchos problemas y no es necesario estudiar ni leer para terminar un proyecto. Los frameworks simplifican la vida pero no deben ser el punto final: Raphael JS es una biblioteca de trabajo de gráficos bastante interesante, igual que Paper.js. Cada una con sus puntos fuertes, sus diferencias, sus ventajas y desventajas, y la capacidad de no necesitar conocer toda la documentación sobre svg y sobre canvas en el html5 para hacer gráficos y dibujos. Pero no es eficiencia llegar a depender de alguna de ellas dos para pintar un simple circulo en pantalla y añadir unos 20 o 30 Kilobytes mas a la carga total de la pagina a mostrar.

Y no soy purista o algo así, he de aceptar que gracias a todas esas infraestrutcturas digitales cada vez el mundo de la programación es más amplio y con más posibilidades, pero debo pensar que no debe ser la última mirada a darle a un lenguaje sin darnos cuenta que podemos sacar mucho mas de todo lo que el creador del mismo nos ofrece.