Historia de la Tecnología: El lenguaje COBOL

En 1958, muchos profesionales de la industria estaban de acuerdo en que era necesario buscar una normalización que permitiese trabajar con un único lenguaje en cualquier computador así que, gracias a la formación de un consorcio entre varias empresas de la industria de los computadores y el Departamento de Defensa de Estados Unidos, se convocó el CODASYL para buscar un lenguaje de programación que pudiera ser un estándar en el ámbito de la gestión, así fue como nació el lenguaje de programación COBOL...

[#4 Robus]

IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION

... tiempos...

[#14 chachechichochu]

el que dice que COBOL es feo, en su vida a visto PL/1.

[#17 KimDeal]

#3 ¿el horror? depende cómo hayas "crecido" como informático! Yo me formé con Cobol y Pl/1 y para Java ( y en general toda la P.O.O.) era el horror... Ahora ya me he acostumbrado y me gusta Java, pero joder, que difícil que es entrar en ese lenguaje cuando vienes de Cobol...

#14 lo dices en serio? Pl/1 es más legible, por lo menos no tiene lo de MOVE 1 TO X para hacer un simple X=1...

#11 ¿feo? que va... esas pantallas negras que apenas cansan la vista, esa sencillez, sin multiples ventanas, ni marcos, ni interminables librerías de objetos... Solo tu pantalla negra y tus lineas de código!

[#19 Tensk]

#17 COBOL es el horror, lo veas por donde lo veas .

Ahora un poco más en serio. Aunque no es determinante, el habitual "hello world" te dice bastante de un lenguaje, y en COBOL, del que no recuerdo más que detalles porque no piqué más código del necesario y hace más de una década, eso de tener que declarar cuatro secciones, que los caracteres fuesen puestos así y asá... quita, quita, era un horror. Hasta FORTRAN, que es algo así como lo más parecido que tiene a un pariente, era mucho más productivo, aunque sus objetivos fuesen muy diferentes.

Yo en su momento empecé, como muchos, con BASIC, haciendo cositas muy... básicas , pero fue con lo que me inicié. Luego, a pesar de que el aburrido (por no decir otra cosa) de Dijkstra pensase lo contrario, aprendí Pascal (en diferentes "sabores") muy rápidamente. A C le vi, y veo, su enorme poder, pero más que el "puedes hacer todo" es un "tienes que hacerte tú todo", y acabé muy asqueado de "segmentation faults" . Java? todo lo potente y multiplataforma que quieras, innegable todo lo bueno como también todo lo malo que tiene. También programé lo justito para unas prácticas y ya. Me gustó más lo poco que pude saborear de OCaml. Incluso el poco ensamblador (MIPS) que codifiqué era mucho más atractivo que COBOL, y no estoy exagerando en esto.

He "toqueteado" una buena cantidad de lenguajes, nada serio, desde ActionScript (sí, eso, qué pasa? ) a PHP, pero si me tengo que quedar con uno, lo tengo clarísimo: Python. No es que ya haya vuelto a ser considerado el mejor lenguaje del año, es que a pesar de ciertos "paradigmas" y cosas que nunca acabé de entender muy bien por qué las hacía como las hacía, es un lenguaje con el que me enamoré a primera vista. Con él es tan fácil, sino más, aprender a programar como con Pascal (o TurboPascal para ser exactos), pero igual de potente y multiplataforma como Java.

Ahora, me encanta programar aunque apenas tiro ninguna línea de código porque mi vida laboral no va por esos derroteros, pero si tuviera que hacerlo, buscaría algo en Python, sin duda, y si no ya vería qué es lo que tiene más salida... php? hummm... ya, que java también, pero trataría de evitarlo .

[#22 sgaviglia]

#19 Procesa unos millones de records en Basic o Java, y luego con la misma máquina hazlo en COBOL y verás por qué las grandes empresas todavía lo utilizan

[#25 dreierfahrer]

#22 Eso es una chorrada... que es el doble de rapido que java? me compro DOS maquinas, es mas barato que hacerlo en COBOL...

Ademas, si fuera por eso se usaria C...

[#27 D303]

#25 No lo dice por que sea el doble de rápido que Java, te lo dice por que no existen gestores de bases de datos capaz de manejar tantos registros sin perder velocidad día a día, sin tener que rehacer los indices, y por supuesto por que una consulta hecha en un cajero en Valencia no la afecte a la velocidad en el apunte que se hace por oficina en Pontevedra al mismo tiempo.

[#29 Rohel]

aqui otro de los "Dinosaurios" que seguimos pensando en Cobol jajaja

#25 me encantaría que vieses por ti mismo el rendimiento de un ZServer y luego discutimos que dos maquinas vas a usar para igualarlo
Es asombroso (cuando te conceden maquina) ver como mantiene threads a lo loco

[#69 Tensk]

#22 Eh, que yo no digo que no tenga su nicho, y soy el primero en decir que si algo funciona y no necesitas mejorarlo, para qué cambiarlo. Pero a día de hoy no sería mi primera opción COBOL para... nada?

[#24 dreierfahrer]

#19 http://xkcd.com/353/

No hase falta disir mas... Yo soy un hooligang de python tambien.

[#23 sgaviglia]

#17 COMPUTE Y=((A+B)*C)/D.
Bueno... podría seguir todavía pero..

[#41 juanparati]

#14 o RPG (Report Program Generator)

[#1 Desactivado]

Antigua Hay antiguos por aquí?

[#5 amstrad]

#1 #2 Os equivocáis muy mucho. COBOL sigue vivo, más vivo que nunca. En los mainframes de IBM, por ejemplo (otra galaxia), funcionando junto a CICS o DB2. Si habéis visto una terminal cualquiera de una administración, es muy posible que COBOL estuviera detrás. De hecho es un buen campo profesional para trabajar ya que la mayoría de los que lo conocen son veteranos y es necesario gente que conozca el lenguaje.

El programa que paga vuestras nóminas y cruza millones de registros (si tenéis la bendita suerte de tener nómina) es probable que esté escrito en COBOL.

[#8 Radix2]

#5 "la mayoría de los que lo conocen son veteranos" cuidadito con a quien llamas veterano que como te pille vas a ver

Ahora en serio, en mi empresa el grupo de cobol, unos 50, no se si llegaremos a los 25 años de media y solo debe haber uno que pase de los 40 y por los pelos

[#13 Bedel_roolmo]

#8 ¿Y está tan bien pagado como se dice?

[#77 Radix2]

#13 NO

Al final es un lenguaje sencillo al que cualquiera puede adaptarse, por ello es muy facil formar equipo de programación y tirar los precios. con el tiempo cuando pasas a tener un conocimiento mas funcional si puede estar bien pagado pero tampoco para tirar cohetes, y de entrar con el sueldo mínimo de convenio o en practicas por menos no te liba nadie

[#18 KimDeal]

#5 y el que saca vuestra pasta de la mayoría de los cajeros del mundo

[#45 vaiano]

#18 Hace cosa de 1 año en un cajero de lacaixa se dejaron fuera la barra de tareas de un windows 98 (no quiero pensar que fuera windows me por la semejanza grafica)

[#46 TheMaster]

#45 suele ser un Windows CE, básicamente una aplicación interfaz que al final acaba conectándose, pasando por diversas pasarelas de pago (redes), a un HOST CICS, IMS... del banco o caja hasta llegar a una aplicación COBOL.

[#48 amstrad]

#45 Una cosa es el sistema de un cajero (lo que se use para interactuar con el usuario) y otra el sistema que haya por detrás con el que tenga que hablar.

[#20 Desactivado]

#5 tampoco te columpies, quien procesa millones de datos lo ace es un sgbd

[#78 Radix2]

#20 No te creas, yo trabajo en cobol y los procesos mas pesados se realizan todos contra ficheros minimizando el acceso a tablas para mejorar el rendimiento y después se cargan los resultados en la base de datos si es necesario. Muchas veces solo se carga lo imprescindible para informar al cliente y el meollo se queda para siempre en cintas.

[#28 Furiano.46]

#5 Ya he puesto representa. Eso es presente, es decir, hoy en dia.

#26 He leído mi comentario cuatro o cinco veces y aún no veo donde pone que COBOL está muerto. Hace muchos años se utilizó muchísimo, y hoy en dia se sigue utilizando muchísimo también. Y bueno, deberías de dejar de valorar lo que saben o lo que no saben los informáticos. En la universidad, hoy, aún hay asignaturas de COBOL y en las empresas piden gente que dominé COBOL. A ver si respetamos los comentarios de los demás y dejamos de ir de sobradillos.

[#44 TheMaster]

#c-5" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1468425/order/5">#5 añado que también muchos programas HOST con los que pagamos con tarjeta están programados en ellos; además de CICS de IBM, más potentes que el son IMS o MQ Series que de igual modo gobiernan los programas COBOL que citas junto con diferentes tipos de base de datos como DB2.
De todos modos COBOL está vivo, pero como funcionan tan bien nadie los toca salvo por mantenimiento y por eso se necesita gente, auqnue hoy día lo que se hace es interconectar aplicaciones y recubrir funcionalidades programando estas interconexiones en Java, C#, C++ mayormente.

[#50 Desactivado]

#44

Si y no.

Hay mucho COBOL todavía: efectivamente.
Funcionan: efectivamente.
Van a serguir funcionando muchos años: efectivamente.
Funcionan bien: NO.

Cualquiera que haya trabajado en un entorno COBOL/CISC/DB2 te podrá contar la cantidad de restricciones que hay como limitación de tiempo de CPU (como se te vaya una transacción te la cortan ... la transacción, se entiendo) prohibido el SQL dinámico, limitaciones a las tablas, .... Le pongo yo esas restricciones a un sistema UNIX y no lo tiro ni quitándole la corriente.

Luego te encuentras con que los famosos 99.999% de uso son más falsos que el caballo del malo. La mayoría de las aplicaciones COBOL se paran todos los días para labores de mantenimiento (como hacer copias de seguridad) Eso si, fuera de esas labores, no se caen.

¿y por qué seguimos con el COBOL? la cosa es sencilla. Cuando se empezaron a informatizar las empresas IBM era la única que se atrevía con proyectos de ese tamaño y era la única que podía manejar esos volúmenes de información e impuso su tecnología: COBOL, primero ficheros indexados (VSAM), luego base de datos DB/2, su sistema transaccional CISC .... y básicamente, sigue siendo lo mismo con evoluciones. Esos sistemas se han quedado incrustados en las grandes empresas y todos los demás dependen de ellos (la interdenpendencia entre aplicaciones) el quitar el COBOL implica tal coste y riesgo que se prefiere seguir con él.

Como ejemplo, cierto sistema de averías ha estado funcionado unos 40 años en una gran empresa de TELCO. Estaba montado en COBOL y ensamblador, ni siquiera usaba BD sino indexados (se ha conseguido apagar hace poco, tras un proceso que ha durado años y ha dolido lo que no hay en los escritos) la parte de ensamblador tenía una explicación oficial (para mejorar prestaciones) y otra oficiosa (se habían perdido los fuentes y hubo que parchear el efecto 2000 a pelo sobre el ejecutable)

Vamos, que si el COBOL sigue no es por sus bondades sino porque no hay manera de quitarlo.

[#53 TheMaster]

#50 si estoy de acuerdo contigo, pero no está el horno para invertir ahora, está costando horrores migrar y quitar líneas en X25, y más que por las bondades de IP es sobretodo porque en X25 el tráfico y el tener esas líneas tiene un buen coste a pesar de sus pros respecto a IP.
Sobre CICS sí, yo soy uno de esos y es un coñazo tener que tirar conexiones en cuanto envías y recibes un mensaje a tiempo echando leches, con el coste que tiene reestablecer conexiones y no poder finalizar antes si sólo tienes que enviar y recibir un par de mensajes. Pero es más barato que MQ o el IMS que comento que también tienen sus inconvenientes y años pero te solventan eso, y te englobal todo tipo de aplicaciones, ya sea en COBOL y te ayudan con conectores como JAva.

[#74 Desactivado]

#53

No es solo que no estén los tiempos para invertir ... sino que se ha invertido mucha pasta en el pasado, cuando no había problemas de dinero y no hubo forma. En las grandes empresas y administraciones públicas los sistemas son auténticas marañas que casi te cuesta más recursos el saber quien tira de quien que el hacer el sistema nuevo.

Conozco sistemas que se han hecho nuevos ... y han mantenido el viejo operativo porque resulta que un director tenía un tamagotchi montado sobre el sistema y no le salía de los cojones cambiarlo al nuevo (o el nuevo no le servía ... viva la adaptación al cambio) Tu mira hasta que punto han llegado las cosas (no solo con COBOL) que hemos tirado sistema UNIX (sin borrarlos, no sea que pasara algo raro) y a la semana han aparecido encendidos de nuevo ... sin que nadie supiera quien había mandado arrancarlos (y los operadores no hacían nada sin que les mandaran) o al menos, el gerente responsable, no se atrevía a investigar (si, aunque parezca mentira, eso pasa) lo más gracioso es que hemos tenido un sistema en producción como tres años sin actualizar (vamos, que la información que enviaba no servía de nada) y lo seguían consultando. Se lo decían al gerente encargado de explotación y te decía ... como el director xxx lo usa ...

Algún día tengo que escribir un libro. A veces Dilbert se queda corto.

[#75 chachechichochu]

#74 El problema que se presenta con COBOL es el siguiente, funcionar funciona y realmente lo hace muy bien. No existe otra tecnología que lo supere en su tarea. ¿Entonces, porque se debería cambiar? ¿Tendría sentido invertir dinero para seguir haciendo lo mismo?

[#76 Desactivado]

#75

Porque los cambios son carísimos, se tarda meses en implementarlos y son muy poco flexibles.

Todas las capas que se pone por encima (recubrimientos en C++, Java, SOA) se hacen para intentar paliar esta falta de flexibilidad.

Y eso de que funciona bien ... con esas restricciones que meten funciona bien y es estable hasta un Windows Vista con el Panda instalado.

[#49 Desactivado]

#5 Pues con mi nómina el señor COBOL se equivoca todos los meses.

[#79 Radix2]

#49 los programas no se equivocan, somos los que los hacemos... pero no se lo digas a mi jefe eh

[#6 Desactivado]

IDENTIFICATION DIVISION.
PROGRAM-ID. IRRELEVANTE.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.
MAIN SECTION.
DISPLAY "Esto es irrelevante"
STOP RUN.

[#70 santicasas]

#6 una lagrimita ....

[#43 Javier1965]

#40 que va, el inmovilismo es lo más barato que hay !! me explico.

1- Los programas que hayas hecho en COBOL en los últimos 20 años, son básicamente iguales, usan la misma tecnología y recursos. Por lo tanto fáciles de mantener.

2- Cuando usas la nuevas tecnologías como el java, en que cada años aparecen 10 frameworks opensource, cada empresa programadora que contratas te propone una serie de frameworks diferentes: struts, spring, etc... y es que las modas van cambiando y si hace 5 años se llevaba Struts, dos años después se llevaba Spring.flows (o como se llame, no recuerdo el nombre). Resultado, en 10 años acabas teniendo un caos total de aplicaciones, casi imposible de mantener por la cantidad de tecnologías añadidas que vas incorporando, y todo para que la productividad de desarrollo sea peor que en COBOL.

[#47 Desactivado]

#43 Hombre, no me refería a dinero sino más bien a la fiabilidad de las aplicaciones hechas por legos allá por los 80 y la falta de programadores hoy en día.

[#16 RespuestasVeganas.Org]

joder que tiempos!! RM-COBOL 85 para MSDOS!!

[#33 Desactivado]

Hacer un gestor de bases de datos en Java es tan absurdo como hacer un videojuego en Cobol. Cada lenguaje es para lo que es.

[#34 sgaviglia]

#33 Tienes razón. Las palabras lo dicen: COmmon Business-Oriented Language.

[#36 pawer13]

Hay gente que para meterse con Java lo describe como el nu evo COBOL, y yo siempre pienso que ojalá tengan razón, porque eso me asegura tener trabajo para muchos años!
#33 no es un SGBD clásico, pero me parece que google usa Java para su Big Table

[#39 juanparati]

Common Old Boring Obsolete Language (COBOL)

Bueno ahora sin bromitas. Yo he trabajado con COBOL y creedme en estabilidad y rapidez de la mil vueltas a Java.

De hecho algunas de las ideas de Java como la ejecución multiplataforma desde un fichero objeto ya lo hacia COBOL en los años 70. Se podría decir incluso que el Runtime de COBOL era una especie de maquina virtual.

Aunque por supuesto tenia sus ventajas y sus deficiencias.

Como ventajas recuerdo que COBOL podía utilizar bases de datos de manera muy rápida y eficaz, pero por supuesto diseñar las tablas no era tan sencillo como hoy en día, ya que había que calcular los tamaños de los campos y el factor de bloqueo.

A pesar de ser intrepetado desde un archivo objeto es bastante mas rápido y estable que Java (Mucho mas).

COBOL ya no se utiliza tanto porque desde los años 70 estaba mas enfocado hacia mainframes y servidores que solo estaban al alcance de grandes empresas (Aunque por supuesto también había versiones para MS-DOS). Ademas no era un lenguaje que estaba diseñado para interactuar a bajo nivel con el hardware o el sistema operativo, lo cual complicaba la creación de programas que pudiesen utilizar el modo gráfico, o por ejemplo utilizar el API del Windows. Generalmente para hacer este tipo de trabajitos tenias que currarte programas externos o módulos en lenguaje C o ASM (Y cargarte la portabilidad).

Sin embargo COBOL se sigue utilizando porque es efectivamente muy estable y permite a sus desarrolladores hacer cambios continuados en el código sin tener demasiadas dependencias o dolores de cabeza. Ademas casi todas las aplicaciones se ejecutan en Mainframes del tipo IBM AS/400, que incluyen el sistema operativo OS/400 y permite la utilización de bases de datos relacionales como DB2 (El cual cumple con el estándar ACID). Estos Mainframes son maquinas con una arquitectura y un sistema operativo cerrado e impopular (A no ser que le instales GNU/Linux), y no existe apenas malware para estas maquinas lo cual ayuda a la estabilidad del sistema.

Hoy en día existen versiones de COBOL como Fujitsu-COBOL o NetCOBOL que permiten crear aplicaciones para Windows sin demasiado esfuerzo pero sacrificando un poco de estabilidad (No hay nada para COBOL como un AS/400).

En definitiva, si una cosa funciona bien y rápido ¿Para que cambiarlo?

[#64 Javier1965]

#62 Si estoy de acuerdo que pueden hacerse y es una tendencia en crecimiento.

Pero han habido serios fracasos de hacer cores de bancos en java, y aún hoy es un tema complejo. Aunque si ya existen paquetes de core bancario en java.

Especialmente el batch, consigue hacer un batch que liquide unos cuantos millones de cuentas en una hora, muchas implantaciones fallan por ahí.

Y aunque pueda hacerse, el tema para mi aún no muy claro es de la productividad.

[#2 Furiano.46]

Este leguaje representa y representó en el pasado lo que hoy es equiparable a Java. Que grande...

[#7 Desactivado]

#2 Qué gran mierda entonces.

java.security.GeneralSecurityException
at java.lang.reflect.Constructor.newShit(Constructor.java:513)
at java.lang.Class.newInstance(Class.java:308 y te la entocho)
at java.security.AccessController.doPrivileged(Native Method Jau)
at java.awt.Toothkit.getDefaultToothkit(Toothloss.java:826)

[#9 aqeloutro]

#7 Actualmente hay en el mundo unos 4500 millones de dispositivos que utilizan Java (http://www.java.com/es/about/). No me parece una cifra que merezca ser menospreciada.

[#51 ikkipower]

#9 Pero hay que se r concientes de lo bueno y lo malo de cada lenguaje de programación y java no es una excepción.

Es fácil de programar comparado con el c, con el tema de la consola virtual permite su ejecución en diferentes SO...

Pero a la vez es mucho más pesado y lento que el C. Si necesitas aplicaciones rápidas y optimizar recursos usarás C y no Java...

Y más cosas..

[#58 aqeloutro]

#51 y #55 no estoy comparando Java y Cobol, solo he salido al paso del comentario de #7 donde acusa a Java de ser una "gran mierda".

[#59 ikkipower]

#58 Por eso he dicho lo que he dicho, que java tiene sus ventajas y sus desventajas como todo

[#55 Samuvil]

#9 Ten en cuenta que cada vez que usas un cajero automático estás usando COBOL, y cuantos cajeros automáticos estimas que hayan?
También aclarar que se usa java para hacer el front.

[#26 D303]

#2 Tu comentario demuestra lo poco que sabéis de informática algunos informáticos, el Cobol no esta muerte, el Cobol esta vivo y seguira vivo durante mucho tiempo, cuando tratas bases de datos realmente grandes terminas en un entorno Mainframe, posiblemente con DB2 y Cobol, todavía hay implementaciones en otras bases de datos, y cuando te hablo de una base de datos grande te hablo de unos apuntes diarios de mas de 10000 registros, bancos, supermercados, administraciones públicas, no existe ningún entorno cliente/servidor capaz de soportar dichos movimientos, y por supuesto no existe ningún entorno cliente/servidor tan fiable como un zServer de IBM o cualquier otro Mainframe, donde no se apaga nunca, ni para cambiar módulos de memoria estropeados.
Parece, y es por suerte para algunos, que ese mundo este olvidado para los nuevos informáticos, incluyendo los que salen de la universidad... A ver si ampliamos miras todos un poco.

[#40 Desactivado]

#26 Pues va a ser que no.

Vamos a ver, COBOL no está muerto pero su agonía parece la de Franco: hasta el último instante seguirá dando por culo. Los desarrollos nuevos en COBOL son minoría y si los programadores de este lenguaje están bien pagados (algo discutible por cierto, porque a mí me pagaban una miseria) es porque son pocos y el mantenimiento de semejantes aplicaciones del Jurásico es siempre necesario.

De hecho IBM mantiene COBOL por la inercia de las grandes corporaciones, incapaces de migrar a otros lenguajes (que no otros sistemas, ojito, una cosa es COBOL y otra muy diferente los zServer corriendo CICS) el montón de aplicaciones que tienen.

Como curiosidad, hace unos cinco años estaba yo en una caja de ahorros picando COBOL y PL/I y me encontré con una barbaridad de 2000 líneas hecha allá por los años 80. La estructuración brillaba por su ausencia, hacía uso intensivo y extensivo de saltos incondicionales y los comentarios eran inexistentes. Cuando pregunté al autor me contó cómo COBOL era, en realidad, un lenguaje diseñado para los que no saben programar pero sí colocar instrucciones precisas en un lugar determinado, y que a él, economista, le había salvado el culo.

Resumiendo, COBOL es la rémora más espantosa que tienen las grandes empresas hoy en día. Y es que el inmovilismo sale caro.

[#56 D303]

#40 No se donde programaste tu en Cobol pero te puedo decir que en entornos Mainframes pagan bien, otra cosa es que hablemos del RMCobol o cosas así, es otro mundo.
Con respecto a la no actualización de las aplicaciones de las grandes empresas tiene su lógica, esa aplicación realizada hace 20 años en Cobol posiblemente haya pasado de un 4371 a un 360 y ahora corra sobre un System z9 y ese migración la habrán realizado sin un solo problema de compatibilidad entre los distintos equipos, y por supuesto esa programa cumple su función perfectamente, la complejidad que atañe desarrollar nuevas aplicaciones para entornos mainframes con nuevas características implican una complejidad innecesaria si tienes resulto el problema.
Las mejoras y actualizaciones en VMS han sido siempre absolutamente transparentes para el código de aplicación realizado, es mas, incluso ha aceptado un cambio de nombre de sistema operativo sin que haya dejado de funcionar alguna aplicación, encuentra esa similitud en un entorno cliente/servidor, tanto en Windows como en Linux

[#60 Desactivado]

#56 En Caixa Galicia cobrando 14.000 euros brutos al año.

Y cuando me refiero a actualizar una aplicación quiero decir que era un completo desastre desde el punto de vista ya no de la ingeniería del software, sino de los conceptos de programación más básicos. Eso sí, parecía funcionar.

[#72 KimDeal]

#40 lo siento pero tengo que votarte negativo por " COBOL era, en realidad, un lenguaje diseñado para los que no saben programar pero sí colocar instrucciones precisas en un lugar determinado". Yo la desestructuración y el caos más bestia lo he visto en programas VisualBasic, Java, PHP... Plataformas donde se apunta mucho novato que sólo sabe algo de la sintaxis del lenguaje. La gente que sabe programar con orden lo hace más o menos bien en cualquier lenguaje.
Normalmente, todo lo que he visto en Cobol o Pl/1 es bastante estructurado y ordenado.

[#73 Desactivado]

#72 Eso es que no has visto muchos

De todos modos tampoco te voy a quitar la razón: hay mucho novato que se mete con PHP o VB y hace auténticas barrabasadas. El problema de COBOL era que por aquella época casi todos eran novatos por obligación.

[#38 Javier1965]

Yo creo que tanto Java como COBOL pueden tener una larga vida:

- Java ha tenido un gran éxito en la capa de presentación: JSP's, etc... pero menos en la capa de lógica de negocio y de manejo de datos, EJB's, etc....

- COBOL sigue usándose muchísimo en la capa de lógica de negocio. El core de la inmensa mayoría de los bancos sigue hecho en COBOL.


Yo personalmente pienso que el Java es demasiado técnico para escribir aplicaciones de negocio. Has de restringir mucho los grados de libertad que tiene un programador para que no la acabe cagando, por ejemplo manejando threads a su antojo. Con COBOL to está más restringido y se cometen menos errores de diseño...

[#62 AaLiYaH]

#38 Hay unas cosas maravillosas llamadas Frameworks, como Spring MVC, que consigue que cualquiera pueda hacer una aplicación de negocio de puta madre. Vamos, eso de que Java no está hecho para aplicaciones de Negocio...no se, Java tiene el mayor mercado ahora mismo, y no he currado de otra cosa que no sea haciendo aplicaciones de negocio.

[#52 wendigo]

Jo que tiempos... hace 20 añitos que hice un añito de programación en COBOL , ya aunque odie profundamente el compilador y sus 123424 fallos por olvidarte de un punto o poner una linea un carácter mas p`alla , la verdad es que resultaba entretenido.

Por lo demás uno de los claros ejemplos de que si algo funciona ...NO LO toques, no es necesario..y con unos cuantos barbasblancas del código ya tienes el mantenimiento asegurado en unas maquinas que no se estropean ni a patadas

Saludos

[#37 Mindrod]

El COBOL es una p... mierda!! Como muchos dicen por aquí arriba...no está nada muerto. Todos los bancos y empresas de seguro usan COBOL en el backend, y no parece que vayan a cambiarlo en breve.
Yo trabaje con COBOL/CICS/DB2 durante 2 años y por suerte pude salir de ahi, aunque, la verdad, dá bastante dinero.

[#12 redeption]

Historia de Menéame: cualquier tonteria de informática sale a portada.

[#61 WhatTheFunk]

Acabo de viajar 5 años atrás en el tiempo, cuando estaba en un proyecto gordo de Cobol y me han vuelto de repente los JCL, el MicroFocus, el QFM, TSO QUERY, el Intertest la commarea y todo eso jaja (Ahora llevo 3 años con C++ en un entorno más ingenieril, no de gestión, y es otro universo, aunque se me quedó vocabulario cobolero como asteriscar y displayar jeje). Bueno, Cobol es añejo, de pelotas, pero para lo que se usa funciona de lujo y no se me ocurre una solución mejor para un backend de negocio de una compañía grande que necesite muchas transacciones de bases de datos, listados y concurrencia de usuarios accediendo a un mismo servidor o servidores (banca, seguros, aerolíneas, compañías telefónicas... yo que se...) que un mainframe IBM con Cobol + DB2 (el online supongo que el más común es CICS pero hay otros y no sabría opinar). Otra cosa es que a lo largo de los años no se hayan gestionado bien los parcheos y recauchutes de programas... pero eso no es culpa del Cobol. Me dan los mismos sudores o más pensando en un programa de hace 25 años escrito en C y modificado por nosecuantas personas distintas, buffff. Y lo mismo cualquier otro lenguaje...

Bueno, esa es mi humilde opinión, recuerdo con cariño el tiempo que curré con Cobol, además era muy exótico jeje y molaba todo el tema de cadenas batch nocturnas y todo eso. Ah, después también curré con Cobol de Bull en mainframes con GCOS, y buff, eso si que era más peleón!! IBM era user friendly comparado con eso!!

Bueno, es mi humilde opinión... salud!!

[#35 Desactivado]

- Programación visual con la posibilidad de utilizar objetos
- Uso de bibliotecas de clases
No digo que las versiones modernas del lenguaje incluyan esto, pero las que yo conocí a principios de los ochenta no sabían nada de clases, objetos ni programación visual.
Aun así, un gran lenguaje para la gestión y la contabilidad.

[#15 Desactivado]

A nivelde lenguajes no puedo dar opinion pero el
programa de facturación de mi empresa esta basado en cobol y aunque la interfaz esta "pasada" el programa funciona bastante bien.

[#66 Javier1965]

#65 mi comentario 63 era en broma por comentar la curiosidad de los bigdecimal, vosotros utilizáis los bigdecimal para manejar importes?

[#67 AaLiYaH]

#66 he editado un poco el comentario, que podías entender que iba por ti el segundo parrafo, y no tiene nada que ver.

Para importes usamos los Double de toda la vida

[#54 usuario2007]

Veo que aqui todo el mundo ha trabajado algo con Cobol y sabe un poco de lo que habla...
Pero hay ciertas cosas.... que no se, a lo mejor estoy equivocado pero se menosvaloran o se ignoran cuando se habla de Cobol, del que algunos parece que hablan maravillas:


" ...A los programadores Cobol se les paga mogollon y estan muy bien valorados..."
Falso. A los programadores CON MUCHA EXPERIENCIA en Cobol y sobretodo con conocimientos de la *arquitectura/standares codificacion/librerias/sistemas propias de la empresa*** e incluso me atrevería a decir con conocimientos de la logica del negocio (bancos, agencias viajes, CorteIngles, Telefonica) serán valorado en ESA empresa. No son valorados por saber solo Cobol, sino por saber como se usa en ESA empresa. Que puede ser distinto a como se usa en otro banco.
Saber Cobol no es garantia de nada. Puedes aprender Cobol en cualquier curso de formacion de cualquier consultora. Pero luego tendra que saberlo a las rigidas normas con las que se usa en la empresa X que sera parecido pero no igual, a la empresa Y.

"...Cobol es muy estable y rapido..."
¿Los lenguajes de programacion son estables? ¿O lo son las maquinas y sistemas operativos sobre los que se ejecutan? ¿Conoceis los contratos de mantenimiento de los mainframe y hardware de las maquinas que ejecutan cosas Cobol? ¿Y la potencia de esas maquinas? ¿Cobol es tan rapido y potente porque es rapido, o porque se ejecuta en maquinas especificas diseñadas para ello? ¿Que pasaría si Java se ejecutase en maquinas semejantes?

"De hecho algunas de las ideas de Java como la ejecución multiplataforma desde un fichero objeto ya lo hacia COBOL en los años 70. Se podría decir incluso que el Runtime de COBOL era una especie de maquina virtual."
¿Cobol es multiplataforma? ¿Puedes coger el codigo objeto compilado en un mainframe especifico y llevarlo a otro mainframe ligeramente distinto y funcionara al 100% ? Yo creo que no... ¿Runtime de cobol???!!!
Que yo sepa, el Cobol se compila...

"Como ventajas recuerdo que COBOL podía utilizar bases de datos de manera muy rápida y eficaz, pero por supuesto diseñar las tablas no era tan sencillo como hoy en día, ya que había que calcular los tamaños de los campos y el factor de bloqueo."
¿Usas un lenguaje de programacion para crear tablas? ¿O te estas liando con DB2, que es la base de datos aparte, que es un añadido y que se compila y linkea aparte?
La base de datos DB2, ademas de ser antigua y algo complicada, admito que debe ser muy potente y rapido. Sobretodo por la cantidad de tiempo que se lleva usando y el volumen de datos que maneja.
Pero eso es merito de la base de datos (y del SO/arquitectura), no necesariamente del lenguaje de programacion.
Como un amigo mio siempre decia, hay versiones de DB2 para windows. Ej :
http://www-01.ibm.com/software/data/db2/linux-unix-windows/



"A pesar de ser intrepetado desde un archivo objeto es bastante mas rápido y estable que Java (Mucho
mas)."
¿Cobol se interpreta? A lo mejor estoy completamente equivocado, pero juraria que se compila... y que luego.... no se interpreta...

"permite a sus desarrolladores hacer cambios continuados en el código sin tener demasiadas dependencias o dolores de cabeza"
(ironia:)
¡Claro que si! ¡Mantener el programa BX7564CO es mucho mas facil que la clase GestionEmpleados.java !!
Y los errores ABEND ASRA, SQLCODE -905, falta de linkeo de accesos de datos y sus PLAN NOT FOUND, recompilado de copys..., son mucho mas faciles de corregir que los "OutOfMemory in line 354" y los "AltaNominas.class not found" Lo que hay que oir....
Y los cambios de longitud del campo NUMEMPLE de 6 a 7 que obliga a cambiar los SORT de los todos los JCL que llamen al programa GRHD145T.... Superfacil de mantener, claro que si.



Cobol a lo mejor tiene una sintaxis muy sencilla como lenguaje de programacion... Pero el entorno en el que se ejecuta (y se programa) es mucho mas complicado y mas incomodo si lo comparamos con cualquiera de ahora. Logico, la informatica ha avanzado, en aquellos tiempos con que el ordenador funcionase bastaba. Ahora se busca que el sistema hable un idioma que la gente pueda entender, no
"Abnormal program termination" y mirar un log de 1500 lineas, para descubir que te falta un caracter al compilar.

¿Habeis diseñado alguna vez alguna pantalla IMS?
Esas pantallas negras que se pueden ver por ejemplo en algunos terminales del corte ingles que usan los empleados para consultar libros.
¿Sabeis lo que cuesta hacer que un campo se ponga en "brillante" , parpadeante, y obligatorio....?
Aunque claro, tal vez vovlemos a lo mismo... eso no es exactamente Cobol, es un añadido...
Aunque admito que en algunas empresas creo que usan herramientas un poco mas automaticas que diseñar esas ventanas.

No se, veo que algunos hablan maravillas del Cobol. Si, tiene sus ventajas y sus cosas buenas, una vez que te acostumbras a el... Pero tiene otras... que comparado con cualquier cosas moderna...

[#57 D303]

#54 Por supuesto que existe mucho desconocimiento, no todo el mundo se puede permitir un Mainframe en casa, en serio, como veras en mis comentarios hablo de la ventaja del Cobol dentro del entorno Mainframe IBM, esa es la arquitectura que es estable, VMS, ahora OS9, Cobol y DB2, y en ningún momento he dicho sea sencillo desarrollar para esos entornos.

[#3 Tensk]

Agh! el horror! el horror!

[#63 Javier1965]

Casi todos los euros que existen, son sólo unos bits dentro de una tabla DB2, actualizados por un programa en COBOL.


Por cierto, no sabéis que el java no sirve para cosas serias, como manejar dinero!!!!! (al menos con los tipos de datos básicos)

http://www.javamexico.org/blogs/luxspes/por_que_usar_bigdecimal_y_no_double_para_calculos_aritmeticos_financieros

Esto no pasa en COBOL, pensado desde su inicio para cosas serias.

[#65 AaLiYaH]

#63. Pues hombre, desarrollo en Java el área de facturación de una gran compañía que facturará en torno a 5 millones de clientes, así que creo que Java si que puede trabajar en proyectos de ese tipo, pero vamos, imagino que COBOL tiraría mejor, pero si nos ponemos así, seguramente con ensamblador tiraría todavia mejor. A veces es simplemente una cuestión de que en Java los recursos son más baratos.

Y bueno, cambiando de tema.

Ahora los que se creen los dioses de la programación programan en Python, dentro de tres años, diran que es puta escoria...en fin, cada lenguaje tienes sus pros y contras, y Java tiene muchos pros que algunos se niegan a reconocer. Ojo, no soy pro-java, ahora curro con Java, pero vamos, siempre he pensado que al programador le tiene que dar igual el lenguaje, porque todo depende del proyecto en el que estas.

Sólo digo que nos dejemos de sectarismos en plan COBOL es caca, Java es el demonio y Python es el becerro de oro de la programacion.

[#11 Desactivado]

Útil pero feísimo.

[#71 jm22381]

Y los cylons qué opinan de esto?

[#68 Desactivado]

Os traigo la palabra del TAO de la programacion. El TAO dice en su capitulo uno, versiculo 2:

1.2

El Tao engendró al lenguaje de máquina. El lenguaje de máquina engendró al ensamblador.

El ensamblador engendró al compilador. Ahora existen diez mil lenguajes.

Cada lenguaje tiene su propósito, aunque sea humilde. Cada lenguaje expresa el Yin y el Yang del software. Cada lenguaje tiene su lugar dentro del Tao.

Pero no programes en COBOL si puedes evitarlo.

[#10 Nas_Droid]

OMG el lobby informatico de meneame ataca portada de nuevo

[#30 ikkipower]

Yo no lo he usado, soy ya de turb c directamente

Sobre COBOL no puedo opinar no lo he usado nunca.

[#32 charangada]

El futuro es CoR (Cobol On Rails)

[#42 Elena_Nito_Del_Bosque]

Ya se dijo en el Tao de la Programción

"El Tao engendró al lenguaje máquina. El lenguaje máquina dio vida al ensamblador. El ensamblador se la dio al compilador. Ahora hay diez mil lenguajes.

Cada lenguaje tiene su propósito, aunque sea humilde. Cada lenguaje expresa el Yin y el Yang del software. Cada lenguaje tiene su lugar dentro del Tao.

Pero no programes en COBOL si puedes evitarlo."

[#31 gan]

COBOL! COBOL! COBOL!

[#21 Desactivado]

y todavía da dinero esto a unos pocos.