Quien no conoce su historia está condenado a repetir sus errores, decía Paul Preston pero esta misma frase de otra forma también la dijo anteriormente Jorge Santayana. Está claro, es importante conocer nuestra historia, ¿Y tú conoces la Historia de los Lenguajes de Programación?
Los lenguajes de programación son una herramienta que comenzó a desarrollarse con la llegada de los primeros computadores en la década de 1940 y no han dejado de evolucionar hasta nuestros días. No obstante, hay historias que se van repitiendo con el paso del tiempo y llegan a ser cíclicas. Te recomiendo le eches un vistazo al libro para obtener tú mismo las conclusiones de cada una de las historias recogidas en él, no obstante, voy a comentar algunas de los errores que más se repiten incluso en nuestros días:
Las máquinas nos quitarán el trabajo
Esto no es nuevo, incluso tampoco es únicamente del sector de la programación. Surgió mucho antes y sigue sucediendo a día de hoy en trabajos donde la automatización desplaza a los trabajadores humanos. Muchos consideran los avances de Codex, Alpha o incluso GPT-3 elementos que desplazarán a programadores, periodistas y escritores ya sean de letras o de código automatizando su papel dentro de las empresas. Sin embargo, no se dan cuenta de que esto lleva pasando desde el inicio.
El computador humano
Antes de la llegada de las computadoras, el trabajo de realizar cálculos complejos o tediosos para obtener unos resultados que emplear en el cálculo de nóminas, contabilidad, balística, astronomía o cualquier otra ciencia que requiriese de cálculos para obtener datos, eran realizados por un ejército de matemáticos a los que se les proporcionaba una plantilla o tarjeta con una serie de cálculos (sí, como en el colegio) y debían resolver esas ecuaciones y escribir el resultado en la casilla inferior de la tarjeta. Estas tarjetas eran recogidas y llevadas a los analistas quienes habían troceado previamente una ecuación mayor en esos cálculos y tenían así su resultado unas horas, días o semanas más tarde.
Se contrataban a cientos y miles de matemáticos con este fin. Para realizar cálculos matemáticos en una hoja durante toda su jornada laboral. Entretenido, ¿no?
Con la llegada de los primeros computadores, estas personas vieron su trabajo peligrar pero realmente no fue así. Al llegar los computadores y tener acceso a una mayor velocidad para completar estas ecuaciones, se entrenó a esos matemáticos para traducir las ecuaciones a código, introducir ese código en las máquinas, provisionar los datos de entrada, obtener los datos de salida y proporcionárselos a los analistas.
Podrías pensar que muchos matemáticos se habían quedado desempleados debido a la reducción de personal necesario, pero realmente no fue así porque al obtener los datos más rápido, lo que sucedió es que se comenzaron a necesitar más analistas y más codificadores y tan solo los matemáticos (bueno, y algunos físicos, químicos y de otras ramas científicas) eran capaces de realizar esos trabajos de forma diligente.
Del codificador al compilador
Como había dicho, muchos matemáticos pasaron de resolver ecuaciones a transformar esas ecuaciones en operaciones simples, transformar los números de decimal a binario e introducir y recoger los datos de las máquinas. Tal y como se menciona en el libro, esto se había convertido en una tarea monacal donde la mayoría de codificadores se pensaba parte de una élite privilegiada que podía hablar con las máquinas y eran indispensables para manejarlas. John Backus lo comentó en una entrevista:
Así como los occidentales despreocupados desarrollaron un orgullo chovinista por su frontera y el conservadurismo correspondiente, muchos programadores de la despreocupada década de 1950 comenzaron a considerarse miembros de un sacerdocio que guardaba habilidades y misterios demasiado complejos para los mortales comunes. [...] El sacerdocio quería y consiguió simples ayudas mecánicas para la monotonía clerical que los agobiaba, pero miraron con hostilidad y burla planes más ambiciosos para hacer que la programación fuera accesible a una población más grande. Para ellos, era obviamente un sueño tonto y arrogante imaginar que cualquier proceso mecánico pudiera realizar las misteriosas hazañas de la invención necesarias para escribir un programa eficiente.
Puedes leer más en el capítulo de Fortran de Historia de los Lenguajes de Programación.
Ciertamente, cuando el compilador se encargó de automatizar la transformación de esas ecuaciones para el procesamiento a través de las máquinas muchos vieron peligrar otra vez su trabajo y, sin embargo, lo que sucedió es que se facilitó el acceso a esas máquinas y universidades y empresas que no habían tenido posibilidad de acceder por la dificultad y entrenamiento necesario (bastante costoso) ahora sí podían hacerlo y no solo eso, la capacidad de las máquina aumentó pudiendo hacerse cargo de otros problemas más complejos.
Como se puede ver en el análisis de la historia es que al principio había pocos analistas. Un trabajo de analista tomaba mucho tiempo porque al diseccionar un problema en muchas y diferentes ecuaciones, hasta obtener el resultado de esas ecuaciones, el analista podía trabajar en otros problemas diferentes en paralelo. Con la aceleración de la toma de resultados, esto ya no era posible. Un analista podía trabajar de forma continua en un problema y podía resolverlo mucho antes y esto a su vez motivaba la asignación de más problemas y más complejos.
Carl Hammer, de la Universidad de Columbia del Laboratorio de Computación Científico T. J. Watson escribió un artículo en el que dijo:
Escribí 20 líneas de código en A-2 para resolver el problema completo. Antes habría tomado meses o incluso años de trabajo hacer lo mismo. [...] Podríamos acelerar la industria, la ciencia, todas las aplicaciones, podríamos aprender más y todo eso con la potencia de esta máquina.
Puedes leerlo en el capítulo de Compiladores del libro.
Tal y como dice Hammer, el gran avance en velocidad les permitió acelerar su trabajo y por ende pudieron destinar más recursos a realizar más tareas menos tediosas.
¡Todos podrán programar!
Esta frase se está repitiendo en nuestros días mucho, pero también lo hizo cuando Grace Hopper desarrolló COBOL. El lenguaje llevaba al lenguaje inglés la realización de las tareas y permitía a cualquier expresar qué quería que la máquina hiciera sin emplear símbolos. Hopper recordaría en una entrevista:
Muchos dijeron de COBOL en los 50s: Pero Grace, ¡todos podrán entonces ser capaces de escribir programas!
No obstante, esto no es nuevo. El lenguaje SQL nació con el mismo fin de hacer más fácil el acceso a las bases de datos a aquellos que no saben nada de programación. Huelga decir que el uso de las bases de datos con SQL nunca se popularizó y aunque Microsoft Access tiene acceso para poder escribir consultas empleando SQL este lenguaje se etiquetó de complejo y es incluso un dolor de cabeza para muchos programadores.
Igualmente, se intentó llevar el lenguaje natural a la programación con Ring, un lenguaje multiparadigma que permite escribir código no solo en orientación a objetos, estructurado o funcional, sino también de forma natural. Sin embargo, la complejidad inherente a saber qué se puede pedir a una máquina para obtener un resultado sigue estando ahí.
Ahora, con Copilot nos dicen que con tan solo escribir comentarios es suficiente para obtener un código ejecutable y un programa funcional o incluso que empleando Codex o Alpha conseguiremos lo mismo. Sin embargo, yo sigo viendo esos intentos llevados a cabo con BASIC o LOGO donde lo único que se ha conseguido perfeccionar es la expresión más flexible del lenguaje a emplear y sin embargo sigue requiriendo de mucho dominio de quien solicita el programa y una revisión del código. Una posible ayuda pero difícil de controlar y que aún necesita evolucionar mucho para poder emplearse en sistemas complejos.
Conclusión
En trabajos en auge como el desarrollo de software donde hay una crisis y carencia de desarrolladores desde los años 50 (de nuevo algo más que puedes consultar en el libro), cualquier ayuda para acelerar el trabajo de estos desarrolladores termina volviéndose en más trabajo a mantener para nuevas áreas de desarrollo. Las más recientes en los últimos años han sido la Inteligencia Artificial, la Ciencia de Datos e incluso el Internet de las Cosas haciendo sistemas cuanto más pequeños y minimalistas mejor para poder cumplir con requisitos de automatización de tareas en el mundo real.
Hay mucho trabajo. Demasiado, ¿te gustaría unirte como desarrollador a paliar las necesidades de profesionales? Echa un vistazo a Erlang y Elixir y, ¿qué opinas?, ¿ha habido mayor demanda en la zona donde vives?, ¿no eres desarrollador/a pero ves cada vez más cursos y formas de entrar en este mundo y te ves tentado/a?, ¿Cómo crees que irá evolucionando todo? ¡Déjanos tu comentario!
