Aparte del software heredado, ¿hay razones para usar COBOL?

COBOL todavía se usa (¿en gran medida?) Para la informática financiera. Es un lenguaje antiguo, y AFAIK la mayoría de los programadores odian, o al menos no les gusta, COBOL. Esto plantea una pregunta: ¿es la única razón por la que COBOL todavía se usa para que el software heredado lo use, o tiene alguna ventaja real sobre otros lenguajes de programación?

Sólo curioso.

Es sobre todo legado ahora. Muchos sistemas comerciales críticos todavía están en COBOL simplemente por el hecho de que son tan grandes e integrados que el costo de la reescritura no parece valer la pena. Escribir un nuevo sistema en COBOL probablemente ya no sea factible, ya que la mayoría de los desarrolladores de COBOL son tan escasos que pueden obtener una cantidad considerable de dinero para la habilidad especializada (similar a un desarrollador de Foxpro ahora). Hay pocas o ninguna razón para mantener una aplicación COBOL, pero desafortunadamente el razonamiento común es cuando la aplicación COBOL ya está en su lugar, es confiable y está estrechamente unida a otros sistemas donde es casi imposible reemplazarla. Ese razonamiento es exactamente la razón por la que debe reemplazarse antes de llegar a una situación en la que el único hardware que ejecuta la aplicación debe construirse a medida a partir de partes de Ebay de los años 80/90.

COBOL todavía se usa (¿en gran medida?) Para la informática financiera.

¿Lo es?

Depende de lo que llames informática financiera. Si llama a todo el código que ejecutan las instituciones financieras, sí, probablemente lo sea. La mayoría tiene reglas comerciales escritas en los años 60 y 70. El riesgo + costo de actualizar sistemas como este a un nuevo entorno no vale la pena. Dudo que haya alguien por ahí escribiendo un nuevo código COBOL. Hoy existen compiladores COBOL que se integran en la pila .NET, por ejemplo. A menudo hay herramientas para integrar y aprovechar las aplicaciones heredadas en las pilas de software modernas, pero esas herramientas a menudo son desconocidas para las personas que no tienen que usarlas, ya que es un mercado muy especializado.

Ahora, si llamas a la informática financiera algo más parecido a un software para finanzas cuantitativas, nunca oí hablar de alguien que usa COBOL. C ++ es mucho más común, junto con algunos lenguajes de nicho como k, un derivado de APL.

COBOL ve principalmente el uso heredado ahora. Su base de usuarios está disminuyendo lentamente debido a la deserción, ya que no se están escribiendo nuevas aplicaciones y las antiguas se eliminan lentamente, pero seguramente.

La mayoría de los sistemas COBOL que podrían reemplazarse rápida y económicamente ya han sido reemplazados. Los que no lo han hecho, continúan siendo cada vez más caros de reparar o reemplazar, pero más baratos y más baratos de mantener en relación con los sistemas más nuevos: funcionan bien con hardware barato y obsoleto y, después de muchos años de servicio, no son ya no muestra ningún error nuevo. La mayoría de los errores se han solucionado o tienen tradiciones de larga data que encajan como soluciones alternativas. El mantenimiento generalmente se ha reducido a uno o dos empleados especializados, quienes, después de trabajar mucho tiempo en el sistema, lo conocen más íntimamente de lo que puede imaginar.

Incluso desde una perspectiva técnica, generalmente hay algunas razones sólidas para mantener los viejos sistemas. Son relativamente estables, en su mayoría han sido reparados por errores y son bien conocidos / entendidos por el usuario final.

Sin embargo, verá que el sistema finalmente se reemplaza. Por lo general, este movimiento proviene del lado comercial de las cosas:

• Los usuarios del sistema actual son reemplazados por usuarios más jóvenes, que no pueden ser convencidos de aprender a usar la interfaz arcaica.
• La compañía no puede encontrar a nadie para contratar para mantener el sistema, con un salario que no es escandaloso en comparación con el salario de otros empleados
• Alguien con un gran presupuesto se avergüenza de descubrir que un sistema central para la compañía se ejecuta en hardware que puede ser reemplazado por un vm en una computadora portátil
• Aparece un nuevo sistema de productos básicos, que es realmente muy barato para comenzar a usar
• La empresa que utiliza los sistemas más antiguos es adquirida, se declara en quiebra o deja de existir.
• Una parte crucial de la nueva funcionalidad que se requiere con urgencia no puede realizarse de manera económica para interactuar con el sistema heredado

Me pregunto qué querías decir con "La mayoría de los programadores". Trabajo en una gran tienda de TI en el mismo piso que los programadores de cobol, los programadores de Java, el programador de .NET (en singular), los programadores de VB de estilo antiguo. No hay odio ni aversión. cobol es un lenguaje como cualquier otro lenguaje de programación: las personas que programan en cobol lo hacen porque es un trabajo para ellos que no es diferente a programar en java o conducir un camión. Contrariamente a la concepción popular en los EE. UU., Se sigue escribiendo mucho cobol, solo que la mayor parte es en India, donde todos los días comienzan a funcionar nuevos programadores de Cobol.

Creo que la razón por la que no se escriben demasiados sistemas netos nuevos en Cobol es porque el tipo de sistemas para los cuales es adecuado (procesamiento de archivos de gran volumen) ya están escritos. Muy pocas grandes corporaciones nuevas se crean en estos días. Y los que lo hacen podrían estar subcontratando cosas como la nómina y los beneficios para las empresas que ejecutan sistemas de cobol heredados.

Una gran parte del código central en PeopleSoft está escrito en COBOL.

Con 20 años de experiencia COBOL, en tres mainframes diferentes, es mi humilde opinión que hay pocos programadores COBOL verdaderos y en su lugar hay programadores IBM, programadores Sperry (Unisys 2200), programadores Burroughs (Unisys MCP) y Tandem (HP NonStop) programadores En una muestra de respeto hacia ellos, también debo mencionar la presencia de programadores HP 3000, programadores BULL y programadores DEC.

COBOL funciona con grandes cajas de hierro, en su mayor parte. Quizás los únicos programadores verdaderos de COBOL, según mis propios estándares, son aquellos que escriben COBOL en una caja de UNIX. Wow, voy a escuchar sobre esto.

Debido a que el hardware es la pieza central, la mayoría de los programadores que escriben COBOL se identifican por el hardware en el que se ejecuta el código que escriben. A lo largo de los años, al escuchar a otros programadores contarme sobre los méritos de Sperry, Burroughs o Tandem, a menudo me he preguntado qué tipo de guerra se produciría si tuviera que reunirlos y colocarlos en una habitación juntos sin poder salir hasta que acordaron una plataforma de hardware para todos los COBOL. No mencioné las otras plataformas porque nunca he trabajado en ellas.

Me he reunido y hablado con muchos programadores de IBM, y se referirán a sí mismos como programadores COBOL. Sin embargo, si uno los involucra en una conversación, rápidamente comienzan a referirse a los procedimientos y herramientas específicos de IBM. Dada la naturaleza centrada en el hardware de COBOL, esto es muy comprensible para todas las plataformas de hardware.

Debido a que COBOL generalmente está vinculado a una pieza de hardware muy costosa, siempre y cuando esa pieza de hardware ejecute los programas COBOL compilados en ella, no hay un fuerte deseo de migrar desde COBOL por el bien de la migración. Sin embargo, con el envejecimiento de la población de programadores de COBOL, la migración es inevitable.

Dado que todas las grandes cajas de hierro que ejecutan COBOL también ejecutarán Java, Java es la ruta natural de migración lejos de COBOL. El código se puede convertir, particularmente ahora en una economía a la baja, por un precio bastante económico. Una vez que no haya COBOL, solo Java, en esa pieza de hardware grande y costosa, alguien más arriba en la organización comenzará a preguntarse si es posible mover el código Java a otra pieza de hardware mucho menos costosa.

Los programadores de IBM, Sperry, Burroughs y Tandem lo saben, por lo que probablemente NUNCA ofrecerán la idea. Sería un sacrilegio para algunos.