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

52

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?

Barry Brown
fuente
8
COBOL está bien para manipular bases de datos jerárquicas o archivos planos y para bombear datos a grandes informes de solo texto en una impresora gigante de matriz de puntos. Pero la mayoría de los datos hoy en día están en RDBMS y a la mayoría de los gerentes les gustan los informes bonitos. COBOL simplemente no maneja eso tan bien.
pdr
1
@ Steve314: ¡Sí! ¡Aquellos! Excepto que los nuestros eran Line Matrix, y no había tomado café esta mañana cuando escribí eso. - en.wikipedia.org/wiki/Line_matrix_printer
pdr
3
Sin señalar COBOL, si buscas un poco, creo que notarás que muchos idiomas específicos de dominio no son muy populares aquí (por decir lo menos); COBOL, Fortran, VB6, MATLAB ... todos muy buenos idiomas, pero no buenos para enseñar ciencias de la computación y sus abstracciones.
Torre
44
@Rook: ¿todos esos realmente cuentan como idiomas específicos de dominio? Incluso MATLAB, IIRC, todavía es capaz de programación de propósito general. Pensé que DSL se aplicaba principalmente a cosas como yacc, lex, etc., idiomas que solo son realmente capaces de realizar una tarea bastante limitada, lo que lleva al otro nombre común de "pequeños idiomas". Nunca se me ocurrió que COBOL, Fortran o VB podrían llamarse específicos de dominio. Por supuesto, cada uno de ellos tiende a usarse en campos particulares, pero pensé que todavía se los consideraba generalmente idiomas de propósito general.
Steve314
1
@ Steve314 - Sí, bueno, podemos decir que hay dos lados. Uno dice la dom.spec. unos son solo los que mencionó, el otro toma una visión más general y cuenta en el que mencioné también, mientras los mantiene en la categoría de propósito general. Pero prácticamente, donde sea que mencione ingeniería y ciencia. comp. obtendrá Fortran o MATLAB, negocios ... COBOL ... use la terminología que le parezca más lógica. Uso este porque me parece que encaja con la mayoría de las personas. En cualquier caso, reciben una buena cantidad de golpes por alguna razón de la comunidad cs en general.
Torre

Respuestas:

68

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.

Steve314
fuente
55
+1 Por saber realmente de lo que estás hablando. Ojalá pudiera darte otro +1 para JSP. ¿Alguna vez usaste "Delta"? Era un generador de Cobol de tal manera que podía escribir su JSP en el código, en un estilo similar a las definiciones de memoria (01 - 03 - 05) y luego escribir su Cobol en los huecos. Divertido y frustrante como el infierno.
pdr
3
Página de Wikipedia sobre JSP: en.wikipedia.org/wiki/Jackson_Structured_Programming . Cuando lo aprendí, todo se hizo en papel.
Steve314
1
La razón por la cual la clasificación se trató como un problema resuelto fue que lo fue. Desde mi recuerdo, COBOL realmente desaconsejó tener más de uno o dos registros en la memoria a la vez (el registro actual y tal vez el anterior). Se suponía que debía ordenar los archivos de entrada antes de leerlos, o ordenar el archivo de salida después de generarlo, utilizando la utilidad de clasificación que vino con el sistema operativo.
poco
1
Hice COBOL durante un par de años (como referencia, solo tengo 26 años), y puedo aclarar una cosa para usted. Ya no hay necesidad de definir los puntos para cada bucle, ahora se puede inline con PERFORM UNTILa END-PERFORMbloques. Realmente odio saber eso.
AgentConundrum
1
@NealB Le estaba aclarando el punto, ya que admite que su experiencia está desactualizada, incluso para los estándares de COBOL. Entiendo su punto de vista sobre COBOL85, pero hay un montón de código antiguo que se inició antes de que existiera, o fue escrito por personas que tenían la cabeza atrapada en una versión anterior. Realmente no puede asumir que una base de código tiene hasta 85 estándares, pero incluso si lo es, sigue siendo un lenguaje incómodo. Los programadores más viejos se jubilan más rápido de lo que están siendo reemplazados, y muy pocos programadores nuevos quieren trabajar en COBOL. Sé que no me gustaría tocar las cosas otra vez.
AgentConundrum
43

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.

James Anderson
fuente
2
En mi respuesta, digo que COBOL es malo para las estructuras de datos. ¿Es esto una diferencia en lo que significa "estructura de datos"? ¿Quizás las herramientas de diseño de registros son excelentes, pero COBOL sigue siendo el lenguaje incorrecto para árboles binarios, etc.? ¿O tal vez mi experiencia con COBOL era demasiado vieja o limitada? Pregunta clave: ¿COBOL tiene punteros? (Preocupantemente, un rápido Google sugiere que sí, aunque mi viejo libro sugiere que no). Odiaría retractar una respuesta que me valió todos esos encantadores puntos de rep, pero si me equivoco ...
Steve314
3
Hay una desventaja en la aritmética decimal: tienes que decir exactamente cuántos dígitos quieres. Recuerdo haber encontrado errores cuando teníamos muy pocos 9s en la PICcláusula en algún programa dentro de un grupo.
David Thornley
2
Mi impresión (no informada) es que COBOL es particularmente bueno para tratar datos en registros rígidos de tamaño fijo. No tan bueno, tal vez, en las estructuras de datos dinámicos. Corrígeme si estoy equivocado.
Barry Brown
@ Steve314 - Sí, los indicadores llegaron en 1985, pero eran un poco flojos, ya que solo se podían configurar en la sección de enlaces. Las versiones posteriores le permitieron señalar cualquier cosa.
James Anderson
1
@Structures, aunque no está a la altura de los estándares de Python en términos de hashes y árboles, etc. Es tan bueno como C o Java, excepto que no es tan bueno como C ++ más Boost o Java más la biblioteca de colecciones. Una vez más, el hecho de no apreciar el valor de las bibliotecas y funciones estándar ha paralizado el lenguaje a lo largo de su larga vida.
James Anderson
27

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

Danny Staple
fuente
20
Algún día descubrirán una bóveda llena de código escrito por Dijkstra en los idiomas que denunció.
jonsca
77
@jonsca: te sorprenderá lo que harás por dinero.
JeffO
3
Las versiones incompatibles eran IIRC bastante comunes hasta al menos los años 70, e incluso en los 80 había Basic. Dijkstra probablemente estaba haciendo su punto basado en un tema que menciono en mi respuesta: COBOL no es bueno para (o pretende ser bueno para) la codificación de la estructura de datos. Por lo tanto, para un valor particular de "programación de enseñanza" o "enseñanza de informática", COBOL es realmente veneno. Por supuesto, dado que COBOL no está destinado a eso, es un reclamo bastante injusto, pero, de nuevo, IIRC, el contexto fue que algunas personas estaban tratando de enseñar estas cosas usando COBOL.
Steve314
2
Dijkstra <- un hombre que hablaba demasiado ...
Rook
3
@Danny: COBOL fue despreciado mucho antes de que Dijkstra escribiera esa línea en 1975.
John R. Strohm
9

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.

Sean
fuente
Escuché que alguien mencionó la banca de pasada, que es la única razón por la que lo incluí, pero ciertamente tomaré tu palabra por encima de la de otra persona.
jonsca
44
Trabajé durante 20 años en Banca, casi todo en COBOL. Los diferentes bancos han hecho las cosas de diferentes maneras, supongo.
TrueDub
Sé de al menos un importante sistema ERP que tiene (o tenía hasta aproximadamente 2007) una gran cantidad de COBOL.
Alan B
2
No fue IBM quien diseñó COBOL. Los principales instigadores fueron la Marina de los EE. UU. Y UNIVAC.
James Anderson
8
"El objetivo principal de IBM al diseñar COBOL era que" debería permitir que un gerente bancario escriba un programa "". Un objetivo noble, aunque la gran mayoría de los gerentes que conozco ni siquiera pueden escribirme literatura simple para un sitio web, y mucho menos escribir COBOL.
maple_shaft
8

¿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.

jonsca
fuente
1
¿Los idiomas son para los usuarios?
JeffO
16
"Líneas de código" no es una buena medida de lenguaje cruzado. COBOL es notoriamente detallado. Esos 5 mil millones de líneas de código anualmente son probablemente equivalentes a diecisiete expresiones regulares;)
MSalters
3
A veces, COBOL es la herramienta adecuada para el trabajo, muchas veces no lo es. La parte difícil es lograr que las personas reconozcan la diferencia.
TrueDub
1
Muy cierto, @TrueDub. Mi frase sonó un poco ventajosa, pero no estaba destinada a serlo.
jonsca
3
@TrueDub: Si COBOL es la herramienta adecuada para un trabajo, no quiero hacer ese trabajo, siempre que tenga alternativas. Hay trabajos mucho más interesantes por los que me pueden pagar bien.
David Thornley
5

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é?


fuente
4

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.]

S.Lott
fuente
No recuerdo ninguno de esos, ni la represión, o nunca los aprendí. Una búsqueda rápida me dice que ciertamente estoy de acuerdo en que ALTERes malo, pero esta característica rara vez se usa, por lo que no es realmente una razón para odiar a COBOL. Sin REDEFINESembargo, no estoy tan seguro . Compararlo unionme hace pensar un poco más amablemente hacia él, pero tal vez lo que está bien en un lenguaje de bajo nivel de manipulación de bits y manejo de estructura de datos puede no ser una gran idea en el procesamiento de datos.
Steve314
A veces tus respuestas me parecen despectivas, pero esta es simplemente inútil. No sé si estás tratando de ayudar aquí, pero lo estás haciendo mal, o si solo estás hablando contigo mismo. Podría preguntarte qué quieres decir con "maldad pura", pero la belleza de las buenas respuestas anteriores es que no necesito iniciar una conversación para aprender algo.
Eric Wilson
@EricWilson: Gracias por descartar mi respuesta tan a fondo. Eso me ayudó a entender qué más se necesitaba agregar.
S.Lott
1
@Eric: el problema ALTERes que redirige los gotos. Primero, eso significa que estás usando gotos, en sí mismo no creo que sea malo, pero en la mayoría de los idiomas es algo inusual en casos especiales. En segundo lugar, eso significa que los gotos van a otro lugar que no sea donde dicen que irán, y eso es aterrador. No estoy realmente convencido de que este sea un código auto modificable, pero se describe como el que miré, y pensar en ello como modificar objetivos de instrucción de salto en ensamblador explica por qué.
Steve314
@ S.Lott Gracias por sus adiciones (usted también @ Steve314), aprendí algo interesante y revoqué mi voto.
Eric Wilson
3

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.

Ninguna posibilidad
fuente
"falta de soporte para Windows como interfaz" ... ¿qué pasa con netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview
JoelFan
@JoelFan gracias por tu comentario. Tienes razón en que hoy hay mejores herramientas para COBOL, pero creo que todas han llegado demasiado tarde. Mi punto con respecto a la falta de compatibilidad con la interfaz de Windows fue a principios de los 90, donde solo Micro Focus era el único jugador en el mercado.
NoChance
2

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!)

TMN
fuente
1
"Hola Mundo" toma cuantas líneas ?. Análisis / generación de XML: ahora está integrado en el lenguaje. Tal vez deberías actualizar tu base de conocimiento. Esta respuesta pertenece a la era de 1960 de COBOL.
NealB
Interesante. No he tenido que trabajar con COBOL durante casi una década, pero la última vez que lo vi fue escrito tal como lo recordaba, DIVISIÓN DE IDENTIFICACIÓN, SECCIÓN DE ALMACENAMIENTO Y TODO. Supongo que todos esos "comentarios obligatorios" (AUTOR, FECHA-ESCRITA, ORIGEN-ORDENADOR, OBJETO-ORDENADOR) son opcionales ahora. El análisis XML no parece tan impresionante: debe estructurar la división de datos para reflejar la estructura del archivo, no hay procesamiento de estilo SAX o DOM. Es bueno saber que está ahí, sin embargo.
TMN