COBOL

       IDENTIFICATION DIVISION.
       PROGRAM-ID.    HOLAMUNDO.
       AUTHOR.        ANONIMO.
       
       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       SOURCE-COMPUTER.   RMCOBOL-85.
       OBJECT-COMPUTER.   RMCOBOL-85.

       INPUT-OUTPUT SECTION.
       FILE-CONTROL.

       DATA DIVISION.
       FILE SECTION.

       WORKING-STORAGE SECTION.     
             
       PROCEDURE DIVISION.
       
           DISPLAY 'Hola mundo'

           GOBACK

           ..

.

En la década de 1970, la adopción del paradigma de programación estructurada se estaba generalizando cada vez más. Edsger Dijkstra, un preeminente informático, escribió una carta al editor de Comunicaciones de la ACM, publicada en 1975 titulada "¿Cómo decimos verdades que podrían doler?", en la que fue crítico con COBOL y varios otros lenguajes contemporáneos; remarcando que "el uso de COBOL paraliza la mente".[3] En una discrepancia publicada a los comentarios de Dijkstra, el científico informático Howard E. Tompkins afirmó que el COBOL no estructurado tendía a ser "escrito por programadores que nunca han tenido el beneficio de COBOL estructurado bien enseñado", argumentando que el problema era principalmente uno de entrenamiento.[4]

Una de las causas del código espagueti fue la declaración GO TO. Los intentos de eliminar GO TOs del código COBOL, sin embargo, resultó en programas intrincados y calidad de código reducida.[5] GO TOs fueron reemplazados en gran parte por las declaraciones i procedimientos PERFORM, que promovió la programación modular[5] y dio fácil acceso a potentes instalaciones de bucle. Sin embargo, PERFORM podría usarse solo con procedimientos para que los cuerpos de los bucles no se ubicaran donde se usaron, lo que dificultaba la comprensión de los programas.[6]

Los programas COBOL eran famosos por ser monolíticos y carecer de modularización.[7] El código COBOL solo podía modularizarse a través de procedimientos, que resultaron ser inadecuados para sistemas grandes. Era imposible restringir el acceso a los datos, lo que significa que un procedimiento podía acceder y modificar cualquier elemento de datos. Además, no había forma de pasar parámetros a un procedimiento, una omisión que Jean Sammet consideró como el mayor error del comité.[8] Otra complicación procedía de la capacidad de PERFORM THRU una secuencia específica de procedimientos. Esto significaba que el control podía saltar y regresar de cualquier procedimiento, creando un flujo de control intrincado y permitiendo que un programador rompiera la regla entrada única, salida única.[9]

Esta situación mejoró a medida que COBOL adoptó más características. COBOL-74 agregó subprogramas, brindando a los programadores la capacidad de controlar los datos a los que podía acceder cada parte del programa. COBOL-85 luego agregó subprogramas anidados, lo que permitió a los programadores ocultar subprogramas.[10] Un mayor control sobre los datos y el código llegó en 2002 cuando se incluyeron la programación orientada a objetos, las funciones definidas por el usuario y los tipos de datos definidos por el usuario.

Sin embargo, gran parte del software COBOL heredado importante utiliza código no estructurado, que se ha vuelto imposible de mantener. Puede ser demasiado arriesgado y costoso modificar incluso una simple sección de código, ya que puede usarse desde lugares desconocidos de formas desconocidas.[11]

COBOL estaba destinado a ser un lenguaje "común" altamente portátil. Sin embargo, para 2001, se habían creado alrededor de 300 dialectos.[12] Una fuente de dialectos era el propio estándar: el estándar de 1974 estaba compuesto por un núcleo obligatorio y once módulos funcionales, cada uno con dos o tres niveles de soporte. Esto permitió 104 976 variantes oficiales.[13]

COBOL-85 no era totalmente compatible con versiones anteriores y su desarrollo fue controvertido. Joseph T. Brophy, el CIO de Travellers Insurance, encabezó un esfuerzo para informar a los usuarios de COBOL sobre los altos costos de reprogramación de implementar el nuevo estándar.[14] Como resultado, el comité ANSI COBOL recibió más de 2200 cartas del público, en su mayoría negativas, que solicitaban al comité que hiciera cambios. Por otro lado, se pensaba que la conversión a COBOL-85 aumentaría la productividad en años futuros, justificando así los costos de conversión.[15]

La sintaxis de COBOL a menudo ha sido criticada por su verbosidad. Los defensores dicen que esto tenía la intención de hacer el código autodocumentado, facilitando el mantenimiento del programa.[17] COBOL también estaba destinado a ser fácil de aprender y usar para los programadores,[18] sin dejar de ser legible para el personal no técnico, como los gerentes.[19][20][21][22] El deseo de legibilidad condujo al uso de elementos estructurales y sintácticos similares al inglés, como sustantivos, verbos, cláusulas, oraciones, secciones y divisiones. Sin embargo, en 1984, los mantenedores de los programas COBOL luchaban por lidiar con el código "incomprensible".[21] y los principales cambios en COBOL-85 estaban allí para ayudar a facilitar el mantenimiento.[23]

Jean Sammet, miembro del comité de corto alcance, señaló que "se hizo un pequeño intento por atender al programador profesional, de hecho, las personas cuyo principal interés es la programación tienden a estar muy descontentas con COBOL", lo que atribuyó a la sintaxis detallada de COBOL.[24]

La comunidad COBOL siempre ha estado aislada de la comunidad informática. Ningún informático académico participó en el diseño de COBOL: todos los miembros del comité procedían del comercio o el gobierno. Los informáticos de la época estaban más interesados en campos como el análisis numérico, la física y la programación de sistemas que en los problemas comerciales de procesamiento de archivos que abordaba el desarrollo de COBOL.[25] Jean Sammet atribuyó la impopularidad de COBOL a una "reacción snob" inicial debido a su falta de elegancia, la falta de científicos informáticos influyentes que participaran en el proceso de diseño y el desdén por el procesamiento de datos comerciales.[26] La especificación COBOL usó una "notación" única, o metalenguaje, para definir su sintaxis en lugar de la nueva forma Backus-Naur que el comité no conocía. Esto resultó en críticas "severas".[27][28][29]

Más tarde, COBOL sufrió una escasez de material que lo cubriera; los libros introductorios tardaron hasta 1963 en aparecer (con Richard D. Irwin publicando un libro de texto universitario sobre COBOL en 1966).[31] Para 1985, había el doble de libros sobre FORTRAN y cuatro veces más sobre BASIC que sobre COBOL en la Biblioteca del Congreso.[32] Los profesores universitarios enseñaban lenguajes y técnicas más modernos y de última generación en lugar de COBOL, que se decía que tenía una naturaleza de "escuela de comercio".[33] Donald Nelson, presidente del comité CODASYL COBOL, dijo en 1984 que "los académicos ... odian COBOL" y que los graduados en informática "tenían 'odio COBOL' en ellos".[34]

A mediados de la década de 1980, también hubo una condescendencia significativa hacia COBOL en la comunidad empresarial por parte de los usuarios de otros lenguajes, por ejemplo FORTRAN o ensamblador, lo que implica que COBOL podría usarse solo para problemas no-desafiantes.[35]

En 2003, COBOL figuraba en el 80% de los planes de estudio de sistemas de información en los Estados Unidos, la misma proporción que C++ y Java.[36] Diez años después, una encuesta realizada por Micro Focus encontró que el 20 % de los académicos universitarios pensaban que COBOL estaba desactualizado o muerto y que el 55 % creía que sus estudiantes pensaban que COBOL estaba desactualizado o muerto. La misma encuesta también encontró que solo el 25 % de los académicos tenían programación COBOL en su plan de estudios, aunque el 60 % pensó que deberían enseñarla.[37]

Se han planteado dudas sobre la competencia del comité de normas. El miembro del comité a corto plazo, Howard Bromberg, dijo que había "poco control" sobre el proceso de desarrollo y que estaba "plagado por la discontinuidad del personal y... la falta de talento".[38] Jean Sammet y Jerome Garfunkel también señalaron que los cambios introducidos en una revisión del estándar se revertirían en la siguiente, debido tanto a los cambios en quién estaba en el comité del estándar como a la evidencia objetiva.[39]

Los estándares COBOL han sufrido repetidamente retrasos: COBOL-85 llegó cinco años más tarde de lo esperado,[40] COBOL 2002 se retrasó cinco años,[41] and COBOL 2014 was six years late.[42][43] Para combatir los retrasos, el comité de estándares permitió la creación de apéndices opcionales que agregarían características más rápidamente que esperando la próxima revisión del estándar. Sin embargo, algunos miembros del comité expresaron su preocupación por las incompatibilidades entre las implementaciones y las frecuentes modificaciones del estándar.[44]

Las estructuras de datos de COBOL influyeron en los lenguajes de programación posteriores. Su estructura de registros y archivos influyó en PL/I y Pascal, y la cláusula REDEFINES fue un predecesor de los registros variantes de Pascal. Las definiciones explícitas de estructuras de archivos precedieron al desarrollo de sistemas de administración de bases de datos y los datos agregados fueron un avance significativo sobre las matrices de Fortran.[32] Las declaraciones de datos de PICTURE se incorporaron a PL/I, con cambios menores.

La facilidad de COBOL con COPY, aunque se considera "primitivo",[45] influyó en el desarrollo de directivas include.[32]

El enfoque en la portabilidad y la estandarización significó que los programas escritos en COBOL pudieran ser portátiles y facilitó la difusión del lenguaje a una amplia variedad de plataformas de hardware y sistemas operativos.[46] Además, la estructura de división bien definida restringe la definición de referencias externas a la División de Entorno, lo que simplifica los cambios de plataforma en particular.[47]