Me sorprendí cuando un antiguo programador de COBOL del IRS al ser preguntado por qué no usaban en el trabajo otro lenguaje como Java él respondía que Java no calcula bien. En realidad ningún lenguaje actual calcula bien, ¿Qué hace a COBOL un lenguaje diferente?
En realidad este problema de la numeración lo abarcaremos más adelante, porque escribiendo Historia de los Lenguajes de Programación llegué a 1959 y topé con un hecho curioso. Dos lenguajes fueron comenzados y elaborados sobre las mismas fechas por ACM: ALGOL y COBOL.
Actualizado (5 de marzo de 2022): ya está disponible el libro Historia de los lenguajes de Programación: Años 1940-1959 donde se habla de COBOL y otros lenguajes. ¡No pierdas la oportunidad de aprender más de la historia de los lenguajes de programación!
El primero fue ALGOL, este lenguaje fue una forma de unificar el lenguaje de programación utilizado para los documentos de investigación. ACM colaboró con GAMM y mientras esta última estaba encantada con el desarrollo hecho puesto que en Europa se empleaba la computación sobre todo en entornos académicos, para los componentes de ACM y usuarios de computadoras de Estados Unidos no resultó tan ideal:
El mercado demandaba la implementación funcional de un buen lenguaje y no la promesa académica de un lenguaje mejor. ¿Sabes de qué lenguaje estaban hablando? https://t.co/Y3EqLAUoEq
— Altenwald (@altenwald) June 25, 2021
En Estados Unidos se requería un lenguaje que cubriese las necesidades de las empresas usuarias de los sistemas de computación. ALGOL no era una buena opción porque había sido diseñado con un enfoque más cercano a los científicos y matemáticos que a los hombres de negocios. Hopper decía:
Yo había sido profesora de matemáticas. En aquél tiempo encontré un cierto número de estudiantes que no podían aprender matemáticas. Entonces me impuse el trabajo de hacer fáciles nuestros computadores para la gente de negocios. Encontré que no era cuestión de si podían o no aprender matemáticas, sino más bien si ellos querían o no. Ellos decían: 'Quita esos símbolos, no sé lo que significan y no tengo tiempo para aprender símbolos'. Sugiero a aquellos que desean que las personas procesen datos a través de símbolos matemáticos que intenten enseñar esos símbolos a vice-presidentes, coroneles o almirantes. Te aseguro que yo lo intenté.
Hopper trabajó en FLOW-MATIC con el enfoque de emplear el idioma inglés en lugar de los símbolos matemáticos e intentar dar un lenguaje de negocios óptimo. No obstante todo estaba muy diluido y cada empresa terminaba empleando otros lenguajes. Por ejemplo, FORTRAN era propiedad de IBM y no estaba disponible para todos los computadores de todos los fabricantes.
A mediados de los años 1950 el título de programador se empleaba y muchos eran especialistas en computadores específicos o lenguajes específicos. Era difícil encontrar programadores y mucho más programadores para una computadora y lenguaje concretos. Esto sumado a la dificultad de aprender ciertos lenguajes.
Uno de los mayores problemas señalados por Charles Phillips, Director de Investigación de Sistemas de Datos del Departamento de Defensa de los Estados Unidos era el coste de adaptar software de una computadora a otra. Suponía más de la mitad del coste de la adquisición de una computadora. Por ello, Hopper formó un comité para elaborar un lenguaje de negocio común (common business language).
Se creó entonces una Conferencia sobre Lenguajes de Sistemas de Datos o CODASYL en 1959 para trabajar en la creación de un lenguaje. Los requisitos establecidos por los asistentes en mayo de 1959 fueron:
- Emplear inglés simple para programar.
- Más fácil de usar incluso si eso significaba menor potencia.
- Abierto a cambios y modificaciones.
- Orientado al problema e independiente de la máquina.
- Incrementar la base de usuarios a aquellos que pueden especificar problemas para ser resueltos por los computadores.
- No limitado o viciado por los problemas de los compiladores actuales.
Hopper tuvo que enfrentar algunos detractores que perseguían obtener un lenguaje óptimo tanto a nivel de ejecución como uso de memoria así como el empleo de fórmulas matemáticas en lugar de palabras en inglés. Tanto es así que IBM y otras compañías, inicialmente se negaron a implementar este lenguaje. Sin embargo, como el Departamento de Defensa exigía la implementación del lenguaje para cada máquina que comprase. Incluso IBM tuvo finalmente que implementarlo.
La destreza de Hopper no fue tan solo a nivel de desarrollo, creando lenguajes y compiladores desde el primer A-0 en 1951 hasta COBOL en 1959, sino mucho más importante, su destreza como vendedora. Como figura conectora y referente en tecnología que llevo no solo a contar con el apoyo del Departamento de Defensa para que el comité de COBOL fuese una realidad, sino de otras compañías donde trabajaban antiguos subordinados/as o compañeros/as de Hopper.
En los años 1970 más del 80% del código escrito empleaba COBOL. Pero, ¿por qué se emplea este lenguaje y no otro?
En realidad, esta revisión a la historia de CODASYL nos da la respuesta. La labor de Hopper fue tan increíble y fructífera que en la década de 1970 consiguió tener un alto porcentaje de código escrito en COBOL y este código era mantenido por programadores contratados por las empresas donde los computadores eran adquiridos. Con el paso del tiempo este software fue modificándose brevemente para aceptar las nuevas versiones de COBOL que cambiaban muy pocos aspectos manteniendo su forma original y permitiendo a estos programas creados hace décadas seguir funcionando igualmente bien.
Actualmente, la base de código aún escrita en COBOL es enorme. Son miles de millones de líneas de código y tan solo existen dos posibilidades para mantener este código.
Convertirlo a otro lenguaje
Si se convierte a otro lenguaje, ese otro lenguaje debe tener las mismas o mejores características e implementaciones similares. Esto es muy importante porque la simple reescritura de una ecuación con valores decimales ya sabemos que no daría los mismos resultados por contar con un sistema de coma fija frente a la implementación predominante hoy en día en la mayoría de lenguajes de coma flotante.
Además, el equipo al cargo de la reescritura debe poder mantener el código actual y saber cómo leerlo correctamente para trasladarlo al nuevo lenguaje. Se estima el periodo de coexistencia de estos dos lenguajes (COBOL y el lenguaje seleccionado para su traducción) durante mucho tiempo. Hemos dicho que son miles de millones de líneas de código.
Por otro lado, surge también el miedo de seleccionar otro lenguaje, comenzar el proceso de traducción y descubrir que ese otro lenguaje puede quedar antiguo, desfasado o sin soporte mucho antes de conseguir terminar el trabajo. Por lo que podría ser una tarea interminable. Lo que nos lleva a la segunda opción.
Mantener COBOL y actualizarlo
Ante la posibilidad de mantener COBOL y actualizarlo para cumplir con las necesidades actuales manteniendo una compatibilidad hacia atrás temporal lo hace perfecto por varios motivos.
El primero es la eliminación de la urgencia de traducir todo el código a un nuevo y completamente diferente lenguaje. Compatibilizado con la formación de nuevos profesionales que pueden encontrar cada vez más cursos de COBOL en diversas plataformas online como Platzi.
El segundo es la disminución del gasto en mantener ese código. Si el lenguaje vuelve a actualizarse y comienza un ciclo de mantenimiento y actualización, esto permite a una empresa invertir de forma paulatina en mantenimiento adaptativo y en un tiempo específico alcanzar un nivel aceptable para volver a ser compatible con cualquier tipo de máquina actual donde pueda desplegarse y ejecutar el código escrito.
Teniendo presente que el mantenimiento adaptativo queda implícito incluso seleccionando uno de los lenguajes más consolidados ya que actualmente cada lenguaje activo tiene la "manía" de emitir cambios y nuevas versiones con una frecuencia de entre 6 y 24 meses, es implícita la necesidad de mantener en continuo cambio el código.
Conclusiones
Hemos visto que la popularidad de COBOL llegó en la década de los 1970 y gracias al trabajo realizado es un lenguaje que quedará con nosotros mucho tiempo. Incluso me atrevería a decir que gracias a la acogida de la opción de formar a nuevos programadores en este lenguaje y mantener el lenguaje en sí, es muy posible que vuelva de nuevo a oírse incluso mucho más.
¿Y tú? ¿Te planteas echarle un vistazo? ¿Quieres saber algo más de algún otro lenguaje octogenario? ¿Crees que deberíamos implementar COBOL sobre BEAM? ¡Déjanos tu comentario!
