¿Por qué el desprecio por COBOL? [cerrado]

Cuando la gente menciona COBOL, generalmente se encuentra con un resoplido o un gemido. No sé mucho sobre COBOL, pero he visto algunos programas escritos en él. Puedo ver que es prolijo, y para ojos no iniciados como los míos, ininteligible. Pero, en realidad, ¿no son todos los lenguajes de programación completos galimatías para un laico?

Entiendo que funciona, funciona bien y todavía se usa ampliamente en las industrias para las que fue diseñado. ¿No son esas las características de un buen lenguaje? ¿Qué tiene de malo COBOL?

COBOL fue uno de los primeros idiomas que aprendí: si ignora innumerables versiones de Basic, tres o cuatro idiomas ensambladores y una variante de Forth, fue en mis primeros cinco y aprendí simultáneamente con Pascal. IOW, estoy respondiendo desde mi experiencia personal usando el lenguaje.

EDITAR Debo decir que la experiencia antigua . Nunca utilicé el idioma después de finales de los 80, aunque compré un libro nuevo (para reemplazar el viejo que tiré con disgusto) para tener algo a lo que referirme para que mis historias de horror no se distorsionaran demasiado. Pero no tengo idea de cómo ha evolucionado el idioma al menos en los últimos 20 años.

Obviamente, para muchas personas, es solo esa visión de "lo viejo es malo" lo que jonsca ya ha descrito, y también mucho más una actitud de pasatiempo de tercera mano. Pero hay problemas reales subyacentes a eso.

Ser demasiado prolijo es un problema real: hay demasiado desorden en la forma de entender el código. Este es, con mucho, el mayor problema. Las personas que se ven en el MOVE, ADDy MULTIPLYdeclaraciones etc en terror tienen una visión ligeramente exagerada de esto, cierto - la COMPUTEdeclaración se acerca más a las asignaciones en otros idiomas. Pero todavía hay mucho desorden en todas esas divisiones y secciones. Una de las primeras cosas que aprendí en COBOL fue comenzar siempre copiando un SKELETON.COB estándar de una página de tamaño A4.

COBOL hace tener algunas características interesantes, pero esas características (por ejemplo, la PICcosa) tienden a ser lo que es ahora más parte de los DBMS más que el lenguaje de programación, y que me parece que por lo general ser una mejor manera de separar dichas responsabilidades. Además, algunas bibliotecas en otros lenguajes usan algo comparable a PIC(por ejemplo, printf y scanf en la biblioteca estándar de C). Podría decirse que lo mejor se ha mantenido, pero lo peor cayó.

Además, para cada característica agradable, había al menos una intolerable. Por ejemplo, no importa cuán trivial sea un bucle, debe mover el cuerpo a un procedimiento separado. Las PERFORM ... UNTIL ...declaraciones y similares son declaraciones únicas, no estructuras de bloque. En cierto sentido, COBOL fue una muestra de la programación estructurada antes de la invención de la programación estructurada - no era una GO TO, pero de uso se desanimó (al menos cuando yo COBOL), pero bucle en particular, simplemente no fue manejado tan bien.

De hecho, el lenguaje que usé después de COBOL que más me lo recordó fue ... dBase. Como en Ashton-Tate dBase III +. En estos días, es más probable que las personas recuerden todos los clones ahora muertos o moribundos (Clipper, FoxPro, etc.) que dieron lugar al nombre genérico xBase, y todavía hay un descendiente vivo en xHarbour. El punto es que estos eran lenguajes de bases de datos, pero nada como SQL.

Incluso entonces, donde cada programa COBOL que opera en una base de datos particular necesita incluir una copia de la especificación de esa base de datos (y las copias podrían terminar siendo inconsistentes), ese no es realmente el caso en xBase donde la base de datos conoce su propia estructura.

Teniendo eso en cuenta, entonces, COBOL no es tan terrible si lo acepta por lo que es. Pero lo que no es es un lenguaje para escribir estructuras de datos. Es por eso que COBOL sufrió mucho en los tiempos de las guerras santas C vs. Pascal: ambas partes podrían estar de acuerdo en que COBOL no fue bueno para reinventar el árbol binario nuevamente.

Ah, y una cosa que nunca olvidaré es cómo mi primer libro de texto de COBOL no describió el SORTcomando, diciendo que estaba fuera del alcance del libro, aparentemente, o el autor no pudo hacer frente a la idea de ordenar, o consideraba que era más de lo que las pequeñas mentes de los estudiantes de COBOL podían hacer frente [ver edición al final]. Ese tipo de cosas hizo muy difícil tomar COBOL en serio.

Un aspecto extraño de esto fue la Programación Estructurada de Jackson, que también me vi obligado a aprender aproximadamente al mismo tiempo, y específicamente para usar con COBOL. Parte de esto fue dibujar un diagrama de estructura para la entrada, luego un diagrama de estructura para la salida, luego dibujar el diagrama de estructura intermedia para el código. Claramente se esperaba que la clasificación fuera un problema ya resuelto: no se podría derivar un algoritmo de clasificación de esta manera. Por lo tanto, era extraño que el libro de texto recomendado dijera que todo el concepto de clasificación estaba más allá de mi pequeña mente, mientras que al mismo tiempo se me enseñó algo así como una docena de algoritmos de clasificación diferentes y cómo implementarlos en Pascal.

Los problemas que JSP puede manejar son probablemente una buena guía para las cosas que COBOL puede hacer relativamente bien. Pero incluso entonces, eso no significa necesariamente que JSP o COBOL sean buenas maneras de manejar esos problemas.

EDITAR el 30 de julio de 2014

Acabo de recibir un impulso de reputación, recordándome que está aquí. Como sucede, debido a la recolección de libros antiguos alimentados por la nostalgia, ahora puedo corregir un punto WRT el SORTcomando.

El libro que usé originalmente como texto recomendado cuando aprendí COBOL fue "Programación metódica en COBOL" de Ray Welland. Esto no cubre COBOL 85 (aunque hubo una edición posterior "Programación metódica en COBOL-85" que todavía nunca he visto).

los comentarios a continuación indican que "se suponía que debía ordenar los archivos de entrada antes de leerlos, u ordenar el archivo de salida después de generarlo, utilizando la utilidad de clasificación que viene con el sistema operativo". De mi respuesta a eso, me perdí el punto "vino con el sistema operativo". Kindall estaba sugiriendo algo similar a la filosofía de Unix AFAICT, con COBOL utilizado para los bits para los que es bueno, utilidades del sistema operativo como una utilidad de clasificación utilizada para otras cosas, y presumiblemente usando un lenguaje de lote / scripting / shell para pegar los bits. Esto tiene mucho más sentido en un mundo antiguo donde el software interactivo era raro o inexistente, por lo que estaría enviando lotes de trabajo (de ahí el "lenguaje por lotes") de todos modos.

Lo siguiente se cita de la página 165-166 de "Programación metódica en COBOL" ...

El uso de archivos seriales ordenados implica que es necesario tener un medio para ordenar los registros dentro de un archivo en un orden específico por clave. La mayoría de los sistemas informáticos más grandes tienen una utilidad de clasificación que clasificará un archivo dada la posición, el tipo y el tamaño de cada uno de los elementos de datos que forman la clave.

También hay una instalación para clasificar registros desde un programa COBOL, pero esto está fuera del alcance de este libro por dos razones:

(a) la interfaz con el sistema operativo es a menudo bastante compleja y varía de un sistema a otro,

(b) el módulo de clasificación es una parte opcional de ANS '74 COBOL y no puede implementarse en sistemas COBOL para computadoras más pequeñas.

Por lo tanto, se supondrá que existen facilidades para clasificar los archivos en un orden específico y se considerará el problema de actualizar dichos archivos.

En resumen, un poco correcto es: la suposición era que, por lo general, la clasificación se realizaría fuera de COBOL. Incluso puede haber una justificación real para excluir la clasificación de un lenguaje de programación alrededor de 1974 para computadoras pequeñas.

Lo que dije anteriormente fue básicamente lo que obtienes después de unos 20 años de no poder verificar los hechos debido a tirar el libro.

Sin embargo, aún debo señalar que estudié formalmente COBOL de este libro recomendado que cubría el estándar de 1974 (no el estándar de 1985) en 1988 y 1989. La tercera edición de "COBOL para estudiantes" (Parkin, Yorke, Barnes) - la primera edición que cubre COBOL 85 no se publicó hasta 1990. No estoy seguro, pero creo que la edición COBOL 85 de "Programación Metodológica" no se publicó hasta 1994.

Pero eso no necesariamente representa al mundo COBOL arrastrando los pies, bueno, no tanto de todos modos. La adopción de nuevos estándares lleva tiempo para cualquier idioma, incluso ahora.

Después de haber pasado la mayor parte de hoy escribiendo algo de COBOL, creo que puedo dar algunos aportes actuales.

Primero las cosas MALAS: -

• No hay llamadas de función. Modern COBOL tiene algunas funciones integradas, pero es un trabajo de ingeniería serio para escribir el suyo.
• Sin tipo de comprobación en llamadas de subrutina. Puede pasar (o no pasar) cualquier cosa en una llamada de subrutina, la subrutina llamada asumirá alegremente que tiene los parámetros correctos y no hay forma de detectar parámetros faltantes o inválidos.
• No hay bibliotecas Ninguno cero cero. No hay bibliotecas estándar, no hay bibliotecas de fácil acceso ampliamente utilizadas. Terminas codificando tareas comunes una y otra vez.
• Todo se implementa como una palabra clave. Debido a que los autores del lenguaje no tienen el concepto de una biblioteca, cada nueva característica termina siendo implementada con nuevas palabras clave, por ejemplo, PARSE y RENDER para soporte XML.

Los malentendidos, es decir, esas críticas comúnmente dirigidas contra el querido lenguaje antiguo que son inválidas o irrelevantes.

• Verbosidad. ¡Entonces escribes algunos caracteres extra! No es un problema grave. En muchos casos, COBOL es menos detallado que decir Java.

• "ARCHIVOS DE COBOL" Usted ve que este término se usa mucho. No existe tal cosa, solo COBOL puede manejar casi cualquier formato de archivo y casi cualquier organización de archivos.

• No multihilo. En los entornos en los que COBOL prospera, los subprocesos múltiples generalmente se dejan en contenedores de aplicaciones como CICS o IMS, que son buenos en él, en lugar de los programadores que tienden a ser malos.

Y lo bueno: algunos aspectos de COBOL son superiores a otros idiomas:

• Estructuras de datos. COBOL tiene una sintaxis concisa y flexible para definir estructuras de datos complejas y tipos de datos extraños.
• Aritmética decimal. Tiene soporte nativo para aritmética decimal, es decir, aritmética tal como la entienden los contadores, con un redondeo adecuado, etc.
• Moviéndose con los tiempos. Algunos aspectos de COBOL son sorprendentemente modernos. Soporte XML integrado, soporte para programación OO, la capacidad de usar clases Java, etc.
• Integración con DB2, CICS, etc. Esto solo se aplica a COBOL de mainframe de IBM (pero esa es, con mucho, la mayor parte de COBOL aún en ejecución), pero la integración con DB2, CICS y otros entornos de mainframe hace que sea más fácil codificar cosas como la base de datos respaldada servicios web que en cualquier otro entorno.
• Manejo de pantalla. El manejo de pantalla estándar implementado en AS / 400 y MicroFocus Cobol es excelente.
• Actuación. Durante muchos años, los compiladores COBOL han estado produciendo ejecutables de muy alto rendimiento. Solo el nativo C y el ensamblador nativo vencieron a COBOL en un mainframe de IBM.

Así que, en general, lo está haciendo bastante bien para algo que fue creado por un comité en la década de 1950. Si una aplicación existente se implementa en COBOL y hace el trabajo, no hay razón para volver a escribirla. Sin embargo, a menos que haya una buena razón, no veo ninguna justificación para que nuevos proyectos usen COBOL.

Esto probablemente se deba a Djikstra. Djikstra declaró que "El uso de COBOL paraliza la mente; por lo tanto, su enseñanza debe considerarse como un delito penal". Cobol fue visto como ingenuo, desestructurado y detallado. Con la capacidad de autoalterar el código (una práctica desaconsejada incluso entre los programadores de cobol), se consideró bastante difícil de depurar o seguir.

Luego está la cuestión de la gran incompatibilidad entre versiones también.

Sugeriría leer la sección de crítica y defensa en Wikipedia para el idioma: http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

Es la edad y la verbosidad son típicamente las cosas que hacen que la gente gime al respecto.

Me parece recordar que el objetivo principal de IBM al diseñar COBOL era que "debería permitir que un gerente bancario escriba un programa". Este objetivo obviamente tuvo un profundo efecto en la forma en que se diseñó el lenguaje, y ahora evolucionó.

Aparentemente hay más COBOL en la naturaleza que cualquier otro idioma. Sin embargo, después de trabajar en TI durante casi 20 años (15 en banca), nunca me he encontrado con un solo sistema implementado en él.

¿Qué tiene de malo COBOL?

Nada.

Creo que la gente tiene una idea preconcebida de que lo viejo es malo, "lo más nuevo es lo mejor". Todavía está en uso, y estoy seguro de que habrá suficiente trabajo de mantenimiento en el código durante otro medio siglo.

En 1997, Gartner Group informó que el 80% de los negocios del mundo funcionaban con COBOL con más de 200 mil millones de líneas de código en existencia y con un estimado de 5 mil millones de líneas de código nuevo anualmente. (a través de wikipedia )

En la codificación, uno siempre debe seleccionar la mejor herramienta para el trabajo, y con ciertas industrias que están casadas con cierto hardware, el lenguaje es óptimo. Nunca he trabajado en la banca, donde había escuchado que era popular, pero la respuesta de Sean indica que este no es el caso.

Si hay un problema con el código heredado que parece viejo, siempre que pueda colocar una interfaz de usuario o una interfaz web frente a él, la mayoría de los usuarios ni siquiera notarán la diferencia.

A la gente no le gusta COBOL porque tiene una aplicación limitada. Fue diseñado para negocios, finanzas y sistemas administrativos para empresas y gobiernos.

¿Qué tienen todos estos en común? Datos. Montones y montones de datos.

¿Adivina quién fue diseñado para procesar datos y tener muchos archivos para el desayuno? ¿Puedes decir COmmon Business-Oriented Language? ?

Hace 50 años, COBOL era lo mejor para las grandes organizaciones con muchos datos para administrar. Hoy en día hay mejores formas de administrar un gran volumen de datos, por lo que COBOL ya no es relevante. ¿O es eso?

Consideremos los gobiernos. ¿Qué datos necesita rastrear un gobierno? Identificaciones de personas, certificados de nacimiento, registros médicos, impuestos (oh ... sí ... impuestos), etc. Y deben mantener estas informaciones indefinidamente, hoy y hace 50 años también.

Las personas también mencionaron a los bancos en algunas de las respuestas y, de hecho, los bancos son grandes usuarios de COBOL. ¿Por qué? porque a diferencia de otros tipos de empresas, los bancos suelen tener un historial. Algunos existen desde hace cientos de años ( como este, por ejemplo ).

Eso significa que algunos datos de 50 años aún deben estar aquí con nosotros, hoy, 7 de octubre de 2011. Ahora tenemos SQL Server y C # u Oracle y Java, pero hace 50 años había COBOL y archivos.

A medida que pasó el tiempo, los datos de los gobiernos y los bancos se hicieron cada vez más grandes y fue cada vez más costoso migrar los sistemas. Lo que significa que deben permanecer en COBOL y mantenerse y evolucionar constantemente a medida que evoluciona el negocio. Algunos bancos están migrando lentamente, mientras que otros simplemente pegan una bonita interfaz Web2.0 frente al mainframe (c # y Java son los más utilizados). ¿Puedes decir código heredado?(COBOL va de la mano con el código heredado (extremo), algo que fue tocado por muchas personas durante décadas de existencia, otra cosa que a los programadores no nos gusta: D).

Y ahora tienes un nicho de actividad. COBOL ahora tiene una aplicación limitada y su experiencia se ve afectada .

Y las personas que ingresan a COBOL eventualmente descubren que usted hace lo mismo una y otra vez, año tras año tras año y para cuando se despiertan ya no son competitivas en el mercado porque la gente ahora quiere PHP, Java, C # , REST, jQuery y solo los bancos buscan personas COBOL.

En este punto, la demanda es menor que la oferta y aquellos que no hacen el corte deben pasar a otra cosa. Y deben comenzar como juniors ya que COBOL realmente paraliza la mente (créanlo que no Copiar-Pegar es el estilo principal de desarrollo en COBOL y representa gran su gran productividad) y ahora maldicen el día en que recogieron COBOL y no lo hicieron ' No pierdas ninguna ocasión para contar sus historias de horror al respecto :). Pero podría contar esas historias sobre cualquier antiguo lenguaje de pedo que ya no se demanda en estos días, pero usted es la desafortunada persona atrapada en él. O bien...

PS y COBOL es malo por todas las otras razones mencionadas por los demás :)

PS2 In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.De Verdad? ¿Y cómo midió el día eso? ¿Fueron a hacer todas las compañías en la palabra y les preguntaron cuántas líneas de COBOL tienen o qué?

Dos características

• La declaración ALTER es pura maldad. Aunque raramente se usa en aplicaciones COBOL más modernas, se usaba mucho en los "viejos tiempos" porque era más eficiente que la estructura equivalente "IF-GOTO". Cuando las computadoras solo tenían 32K de RAM, cada instrucción importaba. Modificó una declaración GOTO para tener un destino diferente.

  Esto hizo que algunos códigos fueran opacos porque el código mismo tenía estado.

• La cláusula REDEFINES en una estructura de datos (como unionen C) es un problema perpetuo. El término "unión libre", es decir, estructuras de datos superpuestas sin un discriminador, es una forma de resumir el problema. Dos alias REDEFINIDOS no pueden ser trivialmente distinguidos por los datos; solo una lectura extensa de la lógica del programa podría determinar el significado de las dos interpretaciones alternativas de los bytes.

  Esto hizo que muchas estructuras de datos fueran opacas porque los datos no pueden entenderse sin el código.

La legibilidad de la sintaxis similar al inglés fue derrotada por estas dos construcciones.

[Los moderadores me han advertido que las respuestas cortas desprecian su pregunta importante e interesante. Si considera que esto es despectivo, puede solicitar detalles. O márquelo para que los moderadores puedan eliminarlo.]

He programado en COBOL durante varios años buenos. Su sintaxis es simple en comparación con los idiomas actuales y no necesita mucha teoría para aprender a ponerse en marcha. COBOL funcionó muy bien con el CICS de IBM (un sistema de gestión de transacciones en línea) y el programador debe hacer anotaciones en el código para escalar el número de usuarios de la aplicación de 1 a varios miles. CICS proporcionó una GUI basada en caracteres que funcionaba con una pantalla como unidad de visualización (sin ventanas). Puede mostrar gráficos utilizando (GDDM de IBM) en el mainframe. COBOL puede comunicarse con archivos indexados (VSAM e ISAM), así como con DB2 (relacional basado en SQL) y también con IMS. COBOL / CICS es un entorno muy robusto y puede aprenderlo en pocas semanas. Eso significa que se enfoca en el negocio, no en la tecnología, por lo que trabaja 7 de las 8 horas en la codificación, no en el aprendizaje de MVM, JavaScript y similares.

El problema con COBOL es el mal marketing que conduce a la falta de interés de terceros para desarrollar herramientas y entornos de programación para ello. Además, su falta de soporte para la interfaz similar a Windows hizo que su popularidad disminuyera después de 1993. El costo del mainframe llevó a los clientes a buscar alternativas y compiladores para COBOL disponible en UNIX y DOS. El lenguaje C atrajo gran parte de la luz, ya que podía ser más portátil y tenía acceso directo a las funciones del sistema operativo, algo de lo que COBOL tenía muy poco.

Lenguajes como VB, DBase, FoxPro y Clipper tenían mejores formas de acceder a 'bases de datos' en la PC que el COBOL comparable en DOS, por lo que COBOL perdió. CICS no se hizo barato en DOS o UNIX durante mucho tiempo, por lo que su valor no estaba presente en estos entornos.

Hoy, COBOL es compatible con .NET, pero supongo que ha perdido la batalla en todas las plataformas, excepto en el mainframe (y posiblemente AS / 400) donde todavía está allí debido a la gran cantidad de aplicaciones de misión crítica que dependen completamente de eso.

Heh, fui a la universidad a principios de los 80, y la gente despreciaba a COBOL incluso en aquel entonces. Creo que el mayor problema es su verbosidad: un simple "¡Hola, mundo!" en COBOL es probable que tenga más de cincuenta líneas, el 95% de las cuales son repetitivas. Simplemente no es un lenguaje muy elegante o atractivo. También fue diseñado para manejar los problemas de ayer, y realmente no se presta a los paradigmas de desarrollo desarrollados después de aproximadamente 1970. Es un lenguaje de generación de informes bastante bueno, siempre que sus informes sean columnas interminables de números con encabezados y pies de página. Si desea pegarse en un gráfico o un logotipo en algún lugar, olvídelo. Creo que sigue siendo el lenguaje más rápido para las tareas de tipo "procesamiento de datos" (tome un archivo de formato fijo con transacciones de 5M en cajeros automáticos y realice un ajuste de saldo simple para cada una), pero, ¿cuántos desarrolladores hacen ese tipo de cosas más? Y muchos sistemas usan XML o JSON hoy en día, odiaría pensar en tratar de analizar algo así con COBOL (en realidad, ¡odiaría pensar en analizar en general en COBOL!)