El lenguaje COBOL (acrónimo de COmmon Business-Oriented Language, Lenguaje Común Orientado a Negocios) fue creado en el año 1959 con el objetivo de crear un lenguaje de programación universal que pudiera ser usado en cualquier ordenador y que estuviera orientado principalmente a los negocios, es decir, a la llamada informática de gestión. COBOL se utiliza principalmente en sistemas comerciales, financieros y administrativos para empresas y gobiernos. COBOL todavía se usa ampliamente en aplicaciones implementadas en ordenadores centrales, como trabajos de lote y procesamiento de transacciones a gran escala. Sin embargo, debido a su popularidad decreciente y al retiro de los programadores COBOL experimentados, los programas se están migrando a nuevas plataformas, reescribiéndolos en lenguajes modernos o reemplazándolos con paquetes de software.[4] La mayor parte de la programación en COBOL ahora es puramente para mantener las aplicaciones existentes; sin embargo, muchas instituciones financieras grandes todavía estaban desarrollando nuevos sistemas en COBOL hasta 2006.[5]
COBOL (Common Business-Oriented Language) | ||
---|---|---|
Organización Internacional de Normalización, CODASYL e Instituto Nacional Estadounidense de Estándares | ||
Información general | ||
Extensiones comunes | cbl, cob y cpy | |
Paradigma | orientado a objetos[1] [2], imperativo, programación por procedimientos | |
Apareció en | 1959[3] | |
Influido por | FLOW-MATIC | |
El 8 de abril de 1959, Mary K. Hawes, una programadora que trabajaba para Burroughs Corporation, organizó una reunión de representantes de academia, usuarios de ordenadores y fabricantes en la Universidad de Pensilvania para organizar una reunión formal sobre lenguages comunes de negocios. Algunos de los representantes incluyeron a Grace Hopper (inventora del lenguaje de proceso basado en el inglés FLOW-MATIC), Jean Sammet y Saul Gorn.[6]
En la creación de este lenguaje participó la comisión CODASYL, compuesta por fabricantes de ordenadores, usuarios y el Departamento de Defensa de Estados Unidos en mayo de 1959. La definición del lenguaje se completó en poco más de seis meses, siendo aprobada por la comisión en enero de 1960. El lenguaje COBOL fue diseñado inspirándose en el lenguaje Flow-Matic de la oficial Grace Hopper y el IBM COMTRAN de Bob Bemer, ya que ambos formaron parte de la comisión.
Gracias a la ayuda de los usuarios COBOL evolucionó rápidamente y fue revisado de 1961 a 1965 para añadirle nuevas funcionalidades. En 1968 salió la primera versión ANSI del lenguaje, siendo revisada posteriormente en 1974 (COBOL ANS-74), 1985 (COBOL ANS-85, ampliado en 1989 con funciones matemáticas, finalizando el estándar actual más usado, conocido como COBOL-ANSI), y en 2002 (COBOL ANS-2002).
El último estándar es el COBOL 2014 que entre otras, incluye una nueva característica que permite gestión dinámica de la memoria (OCCURS DYNAMIC).
Existe una versión IBM Enterprise Cobol, actualizada regularmente y lanzada en 1991, usada en sistemas Host (Mainframe) bajo z/OS.
Para Windows y Linux, hay varios compiladores e IDE-s que existen desde hace tiempo y se siguen modernizando.
También actualmente existen:
PICTURE
se pueden definir campos estructurados. Lo que permite definir números con los que se evita errores de redondeo en los cálculos que se producen al convertir los números a binario y que son inaceptables en temas comerciales, COBOL puede emplear y emplea por defecto números en base diez.Pese a esto, a comienzos de los ochenta se fue quedando anticuado respecto a los nuevos paradigmas de programación y a los lenguajes que los implementaban. En la revisión de 1985 se solucionó, incorporando a COBOL variables locales, recursividad, reserva de memoria dinámica y programación estructurada.
En la revisión de 2002 se le añadió orientación a objetos, aunque desde la revisión de 1974 se podía crear un entorno de trabajo similar a la orientación a objetos, y un método de generación de pantallas gráficas estandarizado.
Antes de la inclusión de las nuevas características en el estándar oficial, muchos fabricantes de compiladores las añadían de forma no estándar. En la actualidad este proceso se está viendo con la integración de COBOL con Internet. Existen varios compiladores que permiten emplear COBOL como lenguaje de scripting y de servicio web. También existen compiladores que permiten generar código COBOL para la plataforma .NET y EJB.
La estructura de un Programa en Cobol se compone de 4 Divisiones.
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
..
.
Pese a que muchas personas creen que el lenguaje COBOL está en desuso, la realidad es que casi todos los sistemas que requieren gran capacidad de procesamiento por lotes (Batch), tanto las entidades bancarias como otras grandes empresas con sistemas mainframes utilizan COBOL. Esto permite garantizar la compatibilidad de los sistemas antiguos con los más modernos, así como tener la seguridad de que el lenguaje es perfectamente estable y probado. Según un informe de Gartner Group de 2005, el 75% de los datos generados por negocios son procesados por programas creados en COBOL, y en otro informe de 1997 estima que el 80% de los 300.000 millones de líneas de código existentes están creados en COBOL, escribiéndose 5000 millones de líneas nuevas de COBOL cada año. Con todo eso, hoy por hoy, la programación en COBOL es uno de los negocios más rentables del mundo de la informática. En el resto de aplicaciones el COBOL ha caído en desuso, reemplazado por lenguajes más modernos o versátiles.
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».[7] 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.[8]
Una de las causas del código espagueti fue la declaración GO TO
. Los intentos de eliminar GO TO
s del código COBOL, sin embargo, resultó en programas intrincados y calidad de código reducida.[9] GO TO
s fueron reemplazados en gran parte por las declaraciones y procedimientos PERFORM
, que promovió la programación modular [9] 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.[10]
Los programas COBOL eran famosos por ser monolíticos y carecer de modularización.[11] 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é.[12]
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.[13]
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.[14] 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.[15]
COBOL estaba destinado a ser un lenguaje «común» altamente portátil. Sin embargo, para 2001, se habían creado alrededor de 300 dialectos.[16] 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.[17]
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.[18] 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.[19]
Un lenguaje débil, verboso y fofo que utilizan los codificadores para hacer cosas aburridas y sin sentido en mainframes de dinosaurios. [...] Su mismo nombre rara vez se pronuncia sin expresiones rituales de disgusto u horror.
—The Jargon File 4.4.8.[20]
|
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.[21] COBOL también estaba destinado a ser fácil de aprender y usar para los programadores,[22] sin dejar de ser legible para el personal no técnico, como los gerentes.[23][24][25][26] 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».[25] y los principales cambios en COBOL-85 estaban allí para ayudar a facilitar el mantenimiento.[27]
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.[28]
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.[29] 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.[30] 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».[31][32][33]
El mundo académico tiende a considerar COBOL como prolijo, torpe y poco elegante, y trata de ignorarlo, aunque probablemente haya más programas y programadores COBOL en el mundo que FORTRAN, ALGOL y PL/I combinados. En su mayor parte, solo las escuelas con un objetivo vocacional inmediato brindan instrucción en COBOL.
—Richard Conway and David Gries, 1973[34]
|
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).[35] 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.[36] 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».[37] 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».[38]
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.[39]
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.[40] 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.[41]
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».[42] 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.[43]
Los estándares COBOL han sufrido repetidamente retrasos: COBOL-85 llegó cinco años más tarde de lo esperado,[44] COBOL 2002 se retrasó cinco años,[45] y COBOL 2014 se retrasó 6 años[46][47] 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.[48]
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.[36] Las declaraciones de datos de PICTURE
se incorporaron a PL/I, con cambios menores.
La facilidad de COBOL con COPY
, aunque se considera «primitivo»,[49] influyó en el desarrollo de directivas include.[36]
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.[50] 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.[51]
Migración de Cobol MainFrame