[Discusión] Object-Oriented COBOL: ¿sirve o no?

** ¿Es Object-Oriented COBOL una contradicción en sí misma o el futuro olvidado de la programación empresarial? ¿Por qué un lenguaje diseñado para la simplicidad y la estructura lineal intentó adaptarse a la orientación a objetos, y qué tan viable es hoy en día frente a lenguajes modernos como Java o C#?

[Kuk]

@MatthewBaw, es un tema interesante. Yo personalmente creo que no tiene sentido ninguno en cuando a la programación Cobol tradicional. Es decir, nadie va a reemplazar el código procedural existente de Cobol por el de OO Cobol.

Sin embargo, me parece un aporte interesante en varios aspectos:

Se pueden definir clases con fucncionamiento que requiere orientación a objetos (o facilita las cosas) y usarla en programas tradicionales (procedurales) mediante REPOSITORY e INVOKE. Por poner un ejemplo muy básico, como en OO una gran novedad y ventaja es el método new que permite instanciar tantos objetos (clones de clases) como quieras (limitados por la memoria, claramente), se podría usar en lugar de tablas internas sin tener que indicar el máximo.

Otra cosa interesante es que se puede interactuar con otros lenguajes. No he investigado mucho el tema, pero existe hasta Cobol for JVM (de Micro Focus), que genera directamente bytecode de JVM. En caso de Fujitsu PowerCOBOL, que trabaja con GUI de manera nativa, con un dialecto OO de Cobol, es una maravilla, aunque lo han discontinuado y han apostado por Cobol .NET, pero en .NET es el mismo principio.


A mi me parece interesante pero de momento no demasiado maduro. Le falta un buen GUI para qu las Empresas se interesen más. El entorno más completo es, sin duda, el de Micro Focus. Tiene su propio servidor que permite exponer código Cobol tradicional como Web Service (SOAP/Rest). En entornos más antiguos como NetExpress también se incorporaba un sistema GUI pero creo que era solo para Windows.

Hoy en día GUI como tal se está muriendo, todo se migra más hacía la Web.
Las empresas usan multitud de capas, para GUI, Web (a parte del core del negocio).

Hace años diría que si hubiera un entorno, con su servidor web, y con GUI, permitiendo eliminar otros productos y lenguajes añadidos por capas, y al mismo tiempo hubiera bajado los gastos, las empresas se interesarían más por ello.

Hoy puedo decir que existe, es Micro Focus Visual COBOL / Dev HUB. Pero es el único, y es caro.


IMHO, falta de madurez, demasiados dialectos incompatibles entre sí, actualmente monopolio de Micro Focus siendo el único producto completo, precios... Pero no lo llamaría sinsentido, si la cosa se enfoca bien, yo creo que tiene cierto futuro, pero para cosas más específicas y más modernas, no para reescribir lo existente.

[Yuri]

Olá @MatthewBaw

Minha experiência em POO é em Java.
POO tem conceitos muito legais, é diferente do jeito que programo em Cobol.
Não consigo separar POO de Java, na minha cabeça fica uma bagunça tentar imaginar as duas coisas COBOL + POO.
Também acho que qualquer implementação POO não feita em Java é um monstro de Frankenstein, veja por exemplo a diferença no código PHP tradicional e o PHP POO (que sintaxe horrível).

É muito caro programar em POO em Cobol, pois se paga pelo compilador (salvo GnuCobol que não sei se implementa POO).
Não vejo sentido usar POO com Cobol, da mesma forma que não vejo sentido usar Cobol sem base de dados nativa.
Cobol se paga para usar base nativa (o que nenhuma outra linguagem faz com a mesma simplicidade, segurança e eficiência).

Saludos!

[Eslopes]

Hola,

Durante bastante tiempo estuve realizando estudios y ejemplos de implementaciones de patrones de diseño en Cobol (OO Cobol). Pensé que más gente se interesaría por esta tecnología, pero al final acabé perdiendo el interés, ya que nunca hubo realmente entusiasmo por parte de otros desarrolladores para adoptar la programación orientada a objetos.

Finalmente llegué a la conclusión de que la verdadera motivación de la industria para añadir OO al Cobol era encapsular código legado y permitir una comunicación más moderna entre aplicaciones Java/.Net y las que corren en entornos mainframe.

¿Qué desalentó la adopción de OO Cobol? La sintaxis tiene una verbosidad que pondría celoso hasta a Java. La falta de inferencia de tipos hace todo aún más tedioso, pues todas las variables deben ser definidas previamente en la Working Storage antes de ser referenciadas. Últimamente ha habido discusiones sobre el uso de GenAI para el mantenimiento de código legado. Pobre IA, pero hay procesos de negocio en abundancia que necesitan que alguien (o algo) los mantenga funcionando.

¡Saludos!

[Kuk]

@Eslopes, muy interesante tu feedback y por tus aportes, que en su día recuperé y publiqué en el foro (cuando eliminaste tu web "100coolthings"): Object-Oriented COBOL - Cobol Foro

Yo creo que otro punto que ha influido es que OO Cobol llegó demasiado tarde.
La modernización de aplicaciones Cobol, sobre todo añadiendo funcionalidades Web, llegó en los años 2000. La gente tuvo que buscar soluciones, y las encontró mediante otros lenguajes de programación y tecnologías sobreponiéndolas como capas sobre el Core realizado en Cobol.
El estándar OO COBOL,el ISO-2002 por lo que entiendo nunca fue implementado al 100% (muchos dialectos y diferencias de sintaxis entre compiladores). Además el monopolio sobre grandes empresas lo tenía IBM que, hasta que yo sé, implementó extensiones OO más tarde que Micro Focus. Luego ambos, IBM y MF, dejaron el OO CObol nativo orientándose hacía código gestionado (Managed Code) como Java y .NET que para mi no tiene mucho sentido la verdad. El permitir interoperatividad sí que es interesante, pero generar en salida algo nuevo, con sintaxis nueva y reglas de juego nuevos, simplemente dejando alguna que otra palabra reservada... no sé yo, a m no me convence. O era más partidario de OO Cobol puro, conservando las ventajas de Cobol y produciendo binarios nativos.

Total que al final, cuando OO Cobol se estandarizó de verdad, que es más bien el estándar ISO-2014, la gran mayoría (si no todos) ya habían conseguido lo que querían sin tocar el código Cobol... Y si no hay necesidad, nadie, de manera masiva, se involucra en el asunto.

Cobol en su gran mayoría de casos se ha quedado a nivel puramente Core del negocio, y yo creo que ya es definitivo. Me parecen interesantes efectivamente las opciones que ofrece OO Cobol para poder intercalar Cobol con Java u otras tecnologías, pero no más allá que eso.

[Eslopes]

Para mí, el gran villano de toda esta historia es el comité ISO encargado de mantener el estándar del COBOL (antes esta responsabilidad estaba en manos del ANSI). Durante décadas, este grupo bloqueó sistemáticamente las innovaciones que habrían sido necesarias para mantener el lenguaje atractivo para nuevas generaciones de programadores. La programación orientada a objetos (OO) se discutía ya desde principios de los años ochenta. Recuerdo haber leído que, en una de las reuniones sobre el futuro del estándar, el equipo de Realia propuso seriamente implementar OO ya en 1989, argumentando que con un COBOL más potente, verdaderamente orientado a objetos, incluso podrían desarrollarse videojuegos de gran complejidad. La respuesta fue una mezcla de escepticismo y burla.

Los fabricantes y miembros del comité ni siquiera lograron consensuar mejoras básicas que ya en esa época resultaban evidentes, como la creación de una biblioteca estándar de clases para el lenguaje, algo que lenguajes como Java, .NET o Python ofrecen desde su concepción. Con una librería así, no tendríamos que reinventar la rueda en cada proyecto: habría componentes reutilizables para manejo de cadenas, estructuras de datos, interfaces gráficas, comunicación con bases de datos y mucho más. Sin embargo, nadie quiso colaborar. La sensación era que cualquier contribución a un código común sería interpretada como una ayuda gratuita a la competencia, y esa mentalidad cerrada terminó frenando cualquier intento serio de modernización.

Hoy, COBOL sobrevive como un paciente en estado terminal, sostenido apenas por sistemas heredados en entornos donde su presencia todavía es tolerada por necesidad. Decir que programas en COBOL fuera de estos ambientes de gran porte es, en cierto modo, como declarar que padeces lepra o alguna enfermedad contagiosa: genera sorpresa, incomodidad y hasta cierto prejuicio.

¿Y qué ha quedado en pie? Fujitsu mantiene NetCOBOL (y la versión PowerCOBOL) principalmente para cumplir contratos existentes con clientes que dependen de esas plataformas. Micro Focus ha sido adquirida —por enésima vez— por una compañía que jamás tuvo vínculo alguno con COBOL y cuyo interés real en el lenguaje es, como mínimo, discutible. Otros fabricantes históricos como Liant, Realia, Ryan-McFarland, Acusoft, PerCOBOL, RM/COBOL, Wang COBOL, DEC/VAX COBOL, HP COBOL, IBM VisualAge COBOL y varias implementaciones universitarias fueron absorbidos, descontinuados o simplemente desaparecieron del mapa. De vez en cuando surgen iniciativas aisladas, como Veryant, que generan código Java equivalente al código COBOL y luego producen un binario en bytecode. Es una estrategia curiosa e ingeniosa, pero condenada a extinguirse, porque ¿quién va a mantener un código puente que en el futuro nadie sabrá —o querrá— tocar?

Incluso lenguajes derivados o dialetos con fuerte arraigo en ciertas plataformas han ido cayendo: versiones específicas para mainframes propietarios, ediciones adaptadas para minicomputadores y compiladores especializados para sistemas bancarios o de telecomunicaciones han terminado en el olvido. La desaparición de sus fabricantes o el cierre de los sistemas para los que fueron creados los dejó sin espacio en el mundo moderno.

Es importante recordar que COBOL estuvo presente en prácticamente todas las plataformas de relevancia de los últimos 40 años. Desde microcomputadoras de 8 bits como CP/M, Commodore 64, MSX y Apple II, pasando por máquinas de 16 bits como IBM PC/XT, PC/AT y Amiga, estaciones de trabajo Unix como Sun, HP-UX y AIX, minicomputadores como VAX/VMS, AS/400 y HP3000, hasta mainframes IBM zSeries, Unisys ClearPath y Burroughs. En cada una de estas plataformas existió al menos un compilador COBOL, adaptado a sus características, lo que demuestra la ubicuidad y flexibilidad del lenguaje, aunque esta diversidad también contribuyó a su fragmentación.

Dicho todo esto, no me sorprendería que, dentro de 75 años, todavía haya quien esté debatiendo sobre cómo clonar antiguos programadores COBOL a partir de su ADN, con la esperanza de corregir el famoso bug del año 2100. Quizás para entonces, el propio COBOL sea visto más como un fósil de museo que como una herramienta viva, pero aún así seguirá teniendo esa aura de “lenguaje inmortal” que nunca termina de desaparecer.

[Kuk]

❞ La sensación era que cualquier contribución a un código común sería interpretada como una ayuda gratuita a la competencia

Este punto se me escapaba y sin embargo es muy importante. Claro, como los negocios son de raíz competencia, nadie quería regalar nada.

❞ Decir que programas en COBOL fuera de estos ambientes de gran porte es, en cierto modo, como declarar que padeces lepra o alguna enfermedad contagiosa: genera sorpresa, incomodidad y hasta cierto prejuicio.

Lo confirmo, lo llevo viendo desde hace años. Par ami esto no quiere decir que Cobol va a desaparecer en los nichos que se ha ganado, como banca y demás (al menos por ahora), pero lo que dices es verdad.

❞ PerCOBOL, Wang COBOL, DEC/VAX COBOL

de estos ni había oído nunca nada...

❞ Incluso lenguajes derivados o dialetos con fuerte arraigo en ciertas plataformas han ido cayendo: versiones específicas para mainframes propietarios, ediciones adaptadas para minicomputadores y compiladores especializados para sistemas bancarios o de telecomunicaciones han terminado en el olvido.

La banca, el estado y similares monstruos usa IBM Enterprise Cobol bajo Mainframe, algunos se mudan al mundo Open, sobre IBM AIX para mantener cultura y garantía IBM, normalmente con Micro Focus. Y los más atrevidos a Red Hat, y los "sin cabeza" a GnuCOBOL.


Por cierto!!! GCC v15 ahora contiene un nuevo compilador, el GCOBOL que es un compilador nativo/verdadero de Cobol (no confundir con GnuCOBOL que es un traductor al lenguaje C que luego se compila):

• COBOL Language Frontend Merged For GCC 15 Compiler - Phoronix
• GCOBOL(1) (gcc cobol compiler)
• Dinosaurs: GCC 15 Now Supports COBOL! | Fermin Gutierrez | 34 comments

[Eslopes]

No conocía el gCOBOL. Parece interesante. Voy a ver si puedo contactar a los creadores para entender cómo interconectar gCOBOL con Python. Quién sabe, quizá reactive aquel proyecto con Generative AI

[Kuk]

@Eslopes, por lo que entiendo, gCobol formando parte de gcc, es compatible con todo lo de gcc. Así que, aparte de GUI y demás, debe ser compatible con este tipo de cosas: GitHub - davidmalcolm/gcc-python-plugin: GCC plugin that embeds CPython inside the compiler