Portada
mis comunidades
otras secciones
#2:
PERFORM VARYING MENEOS FROM 1 BY 1 UNTIL PORTADA EQUAL TRUE
END-PERFORM
END-PERFORM
#25:
#24 Desde mi punto de vista, no se puede afirmar que Java o .NET (por ejemplo) sean mejor que COBOL (por ejemplo también). Es como comparar huevos con castañas.
A mi no se me ocurriría escribir una aplicación web en COBOL, como no se me ocurriría escribir un driver en PHP. Los lenguajes de programación nacen para cubrir una necesidad, y hay que reconocer que COBOL ha cumplido su objetivo plenamente. Ten en cuenta que no existian las bases de datos tal y como las conocemos...
Ahora con tu ejemplo, (User.find_by_name("perl").posts.select.delete_all), imaginate que no tienes base de datos, y dime cuantas líneas necesitarías para hacer lo mismo.
Un saludo.
A mi no se me ocurriría escribir una aplicación web en COBOL, como no se me ocurriría escribir un driver en PHP. Los lenguajes de programación nacen para cubrir una necesidad, y hay que reconocer que COBOL ha cumplido su objetivo plenamente. Ten en cuenta que no existian las bases de datos tal y como las conocemos...
Ahora con tu ejemplo, (User.find_by_name("perl").posts.select.delete_all), imaginate que no tienes base de datos, y dime cuantas líneas necesitarías para hacer lo mismo.
Un saludo.
#14:
"A diferencia del Cobol, Ada nunca fue un lenguaje muy utilizado"
No todo en este mundo es informática de aplicaciones. Ada es uno de los lenguajes mas robustos y mejor adaptados a tiempo real, por lo tanto se usa mucho en control, y por desgracia, en muchisimas aplicaciones militares. La mayoría de cohetes y misiles van guiados con Ada. Por no decir, lanzaderas, satélites, robots, etc.
Cobol manejará mucho dinero, pero Ada ha "visto" otros planetas.
No todo en este mundo es informática de aplicaciones. Ada es uno de los lenguajes mas robustos y mejor adaptados a tiempo real, por lo tanto se usa mucho en control, y por desgracia, en muchisimas aplicaciones militares. La mayoría de cohetes y misiles van guiados con Ada. Por no decir, lanzaderas, satélites, robots, etc.
Cobol manejará mucho dinero, pero Ada ha "visto" otros planetas.
#10:
Los anteriores capítulos (todos ellos recomendables), repletos de detalles curiosos que hoy resultan incluso cómicos:
Historia de un Viejo Informático. Introducción
Historia de un Viejo Informático. Los estudios: El Instituto de Informática
Historia de un Viejo Informático. El equipamiento informático en la década de los setenta
Historia de un Viejo Informático. El Método de trabajo en Proceso de Datos en la década de los setenta
Historia de un Viejo Informático. Los mainframes de IBM
Una vez más, voy a leer éste y meneo.
Historia de un Viejo Informático. Introducción
Publicado hace 15 años por
--101913--
a
eltamiz.com
Historia de un Viejo Informático. Los estudios: El Instituto de Informática
Publicado hace 15 años por
macluskey
a
eltamiz.com
Historia de un Viejo Informático. El equipamiento informático en la década de los setenta
Publicado hace 15 años por
macluskey
a
eltamiz.com
Historia de un Viejo Informático. El Método de trabajo en Proceso de Datos en la década de los setenta
Publicado hace 15 años por
maxim.rudin
a
eltamiz.com
Historia de un Viejo Informático. Los mainframes de IBM
Publicado hace 15 años por
Zapiron
a
eltamiz.com
Una vez más, voy a leer éste y meneo.
Comentarios
PERFORM VARYING MENEOS FROM 1 BY 1 UNTIL PORTADA EQUAL TRUE
END-PERFORM
Los anteriores capítulos (todos ellos recomendables), repletos de detalles curiosos que hoy resultan incluso cómicos:
Historia de un Viejo Informático. Introducción
Historia de un Viejo Informático. Introducción
eltamiz.comHistoria de un Viejo Informático. Los estudios: El Instituto de Informática
Historia de un Viejo Informático. Los estudios: El...
eltamiz.comHistoria de un Viejo Informático. El equipamiento informático en la década de los setenta
Historia de un Viejo Informático. El equipamiento ...
eltamiz.comHistoria de un Viejo Informático. El Método de trabajo en Proceso de Datos en la década de los setenta
Historia de un Viejo Informático. El Método de tra...
eltamiz.comHistoria de un Viejo Informático. Los mainframes de IBM
Historia de un Viejo Informático. Los mainframes d...
eltamiz.comUna vez más, voy a leer éste y meneo.
"A diferencia del Cobol, Ada nunca fue un lenguaje muy utilizado"
No todo en este mundo es informática de aplicaciones. Ada es uno de los lenguajes mas robustos y mejor adaptados a tiempo real, por lo tanto se usa mucho en control, y por desgracia, en muchisimas aplicaciones militares. La mayoría de cohetes y misiles van guiados con Ada. Por no decir, lanzaderas, satélites, robots, etc.
Cobol manejará mucho dinero, pero Ada ha "visto" otros planetas.
#24 Desde mi punto de vista, no se puede afirmar que Java o .NET (por ejemplo) sean mejor que COBOL (por ejemplo también). Es como comparar huevos con castañas.
A mi no se me ocurriría escribir una aplicación web en COBOL, como no se me ocurriría escribir un driver en PHP. Los lenguajes de programación nacen para cubrir una necesidad, y hay que reconocer que COBOL ha cumplido su objetivo plenamente. Ten en cuenta que no existian las bases de datos tal y como las conocemos...
Ahora con tu ejemplo, (User.find_by_name("perl").posts.select.delete_all), imaginate que no tienes base de datos, y dime cuantas líneas necesitarías para hacer lo mismo.
Un saludo.
#24
ATENCION: El formateo/indentación se me queda hecho un asco. Si algun editor con poderes divinos tiene algún truco para arreglarlo, estaría superagradecido.
IDENTIFICATION DIVISION.
PROGRAM-ID. POR-QUE-NO-TE-CALLAS.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. MI-CASAAAAA.
OBJECT-COMPUTER. LOQUEQUIERAS.
DATA DIVISION.
WORKING-STORAGE SECTION.
77 SQLCODE PIC '9999' COMP VALUE 0.
77 FECHAHOY PIC '999999'.
77 FECHALIM PIC X(xx).
* NO RECUERDO EL FORMATO DE FECHAS ISO... QUE LE VAMOS A HACER
PROCEDURE DIVISION.
MAIN SECTION.
BEGIN.
ACCEPT FECHAHOY FROM DATE
CALL 'MESPASADO'
USING FECHAHOY
GIVING FECHALIM
END-CALL
EXEC SQL
DELETE FROM POSTS
WHERE USER = 'PERL' AND
FECHA
Gran lenguaje el COBOL. Insuperable para tratamiento de datos.
#30 Jajajajajaja! Pero cómo te pones cuando te tocan tus juguetes! Que no es nada personal, hombre, que son lenguajes de programación! (el negativo te lo has ganado en la última línea!).
Sigues en lo mismo: 3000 peticiones. Dime cuántas actualizaciones haces en cada petición. Dime cuántas entitades diferentes tocas en cada transacción.
En mi instalación tenemos todo el frontal (que no es nada trivial) desarrollado en java. El backend, en PL/I. La productividad de los equipos que llevan frontend vs. los que llevan backend es similar. En ambos casos, porque nadie está inventando nada: en ambos ámbitos hay librerias de código y montones de experiencia ayudando.
RAILS, J2EE, .NET... todo eso está muy bien para escribir frontends. Pero para los backends, NADA se compara a un mainframe programado usando COBOL o PL/I.
Llevamos años estudiando las posibilidades de hacer downsizing de cosas que tenemos en los backends. Con números en la mano, a la que te apartas de temas triviales (y casi todos orientados fuertemente al "query" puro y duro), nada de nada. No sale a cuenta.
(Otro resulado antiintuitivo es que -nuevamente con los euros en la mano- es más barato pagarle al diablo Ballmer y usar Windows Server que apostar por Linux con RedHat o SuSe... la razón es que MS prácticamente regala las licencias a las grandes corporaciones).
Y sí, lo, siento, ruby, python y cosas parecidas son juguetes. A nadie le gusta que le toquen sus airgamboys, pero es una cosa que se cura: ya crecerás. Es sólo cuestión de tiempo ;).
#20 Le daran por saco o sera un lenguaje maldito, sobre todo aqui en Meneame que pareceis todos unos pimpollos que habeis nacido programando en C y en calculadora con monitor en color, pero los que programamos en Cobol o RPG, otro lenguaje maldito, seguimos teniendo trabajo y posiblemente siendo los programadores/analistas mas buscados por la gran empresa.
Me siento vieja. Yo hice programas en Cobol. Anda que no he rellenado hojas de codificación como la que viene en el ejemplo....
"Y es emblemático en Cobol el uso del punto para indicar el fin de la frase, es decir, el fin de sentencia o del párrafo, de la misma forma que el punto se usa en la escritura para terminar una frase o párrafo (salvo que seas Gabriel García Márquez y escribas El Otoño del Patriarca… entonces sólo pondrás un punto cada seis o siete páginas..."
#22 por el amor de cristo bendito, ¿aún vive RPG? mi padre prgramó el IBM de antibióticos de 8KB en RPG II, sacaba la nómina de más de 5.000 tíos con 8KB de ram y tarjetas perforadas allá en el 1970 y una gota, cuando se marchó porque le putearon la IBM fué incapaz de hacerlo decía que con 8KB era imposible...
P.D. aún tengo el código fuente en casa y la ficha del resultado de compilación en el centro de oviedo, 7148 bytes... toma ya billgatos...
#16 No, no le falta ningún punto. La FD termina en el RECORD-OUT.
Un saludo.
Estas peripecias definitivamente me alegran el día. Acostumbrado a tener que leer y aprender lo más moderno y lo último de lo último se agradece plantarse y ver con retrospectiva lo que se ha sido el gremio en los origenes y que fue la verdadera base de informática.
Chapeau por la serie.... ¡Meneo!
Otro buen artículo... aunque incluso un monstruo como COBOL fué cambiando con los años.
A partir de la versión COBOL-80, desapareció el fatídico ALTER. Se acabó el código automodificable. Lo cual es, desde luego, Algo Bueno.
Otra: la posibilidad de escribir programas estructurados. Por cierto, en ese "estilo" sólo se usa un punto al final de cada párrafo. Será que los programadores que llegamos a usarlo tenemos algo de Gabo? (En mi caso sólo usé COBOL por una temporada, soy del bando del PL/I ;)). Aparecen sentencias tipo WHILE PERFORM..END-PERFORM, IF...ELSE...END-IF, etc, etc... Incluso las sentencias de tratamiento de ficheros son estructuradas:
PERFORM UNTIL
END-PERFORM
.
READ FICHERO INTO REGISTRO
AT END
NOT AT END
END-READ
.
... y cosas así. El COBOL de hoy en día es un lenguaje medianamente decente.
Aunque donde esté el PL/I que se quite COBOL...
Mis conocimientos de cobol están un poco dispersos... desde los 12 años no lo toco (y no no soy tan mayor)... pero en la hoja del programa , en las lineas 208 y 209 ...le falta el punto
Saludos
#17 Pues si que los tenia dispersos ...si
Saludos
otro articulo genial
por cierto #2 , confirmo que falta el continue dentro
#2, creo que te falta un CONTINUE, ¿o puede estar vacío el cuerpo de un PERFORM (pregunto, no estoy seguro)?
PERFORM VARYING MENEOS FROM 1 BY 1 UNTIL PORTADA EQUAL TRUE
CONTINUE
END-PERFORM
[Talibán COBOLero]
COBOl tiene una gran ventaja, y es que resuelve la mayoría de errores en tiempo de compilación, por lo que los programas luego resultan ser muy robustos.
Ay, que recuerdos de aquellos tiempos, estudiando con el MS-COBOL. Horas y horas picando código para que al final el compilador te soltara aquello de:
10000 ERRORS OR WARNINGS.
.
.
.
¡Que le den por saco al COBOL!:D:D:D:D:D:D
#24: No creo que tu ejemplo valga... porque los metodos de que hablas están ya escritos. Imagina ahora que tienes que programar el método find_by_name, el posts.select, el delete_all... y todos los que estos a su vez llaman...
Ahora nos parece todo más sencillo, porque hay mucho escrito ya. Pero Alguien Ha Tenido que Escribir las Clases y Métodos. Eso es bueno, porque ahorra trabajo, ya lo creo. Pero no es comparable.
#5 es posible que esté mal, la sintaxis correcta aqui: http://cobol.comsci.us/syntax/statement/perform-until.html
Majete...Escribe un libro que esto es apasionante. Gran trabajo.
#29 No nos engañemos, si COBOL sigue usándose es pq la usan cajas y bancos y tienen procesos MUY CRÍTICOS para cambiarlos todos de nuevo y tienen pasta para pagar el mantenimiento de sus sistemas en COBOL.
Te lo dice alguien que estuvo trabajando en COBOL (para una caja de ahorros como no) y que lo sufrió en sus carnes.
Eso sí, COBOL cumplió su labor con creces teniendo en cuenta las limitaciones de la época. Todo lo demas.... ¡nostalgia!
¡Je,je! ¡qué tiempos aquellos..! ¡Cuántos recuerdos me trae ese texto!
Si Bertini levantara la cabeza...
¡Gran artículo! ¡Que recuerdos! Yo sí estudié COBOL en la universidad... y luego he trabajado muchos años de programador y analista-programador en COBOL. Sobre todo para banca y seguros (varios clientes). Y no sólo aplicaciones BATCH, también on-line, con acceso a bases de datos, etc.
La verdad es que nunca me gustó mucho el dichoso lenguaje... pero todo lo que explica el artículo es cierto: es súper fácil de aprender y se pueden seguir y modificar programas escritos hace más de 20 años por programadores de los que nadie se acuerda (y de hecho se hace continuamente). Y el famoso "efecto 2000"... cientos de campos fecha de 6 dígitos en decenas de ficheros, tablas, módulos, programas, transacciones...
Me siento jovenzuelo a mi solo me enseñaron c++, visual basic, pl/sql y algo de java y php. Ahora prácticamente recuerdo poquísimo de todo ello. El cobol y el pascal los he visto en sistemas del año la polca y siempre me pareció extraño que no los actualizasen hasta que vi lo que costaría, entonces me di cuenta de que no tengo ni puta idea
madre mia!!! acabo de recordar que me sabía de memoria las cuatro divisiones, una y otra vez lo mismo.
#12 echo de menos a pascualillo. Como me gustaba ese lenguaje.
Mi padre lee esto y se pone a llorar, te lo juro.
#22 estais cotizados porque sois muy pocos los que conoceis ese lenguaje tan ... horroroso
decid lo que querais, pero en Ruby on Rails (por ejemplo), para cargar todos los posts (pensad en el dominio de un blog) del usuario "perl" que hay en la BBDD y eliminar los anteriores al mes pasado se hace:
User.find_by_name("perl").posts.select.delete_all
A ver en cuantas líneas haceis eso en Cobol. Y sobre todo, con tanta claridad. Y no me vengais con 'cobol es para sistemas de alta estabilidad', que Rails (y Java, y .NET y Scala y ...) también escala (al fin!), sino mirad Twitt... digo... basecamphq.com
Prefiero mil veces más un lenguaje fácilmente mantenible que una ultra rápido y eficiente.
#25 sí, desde luego que son ámbitos diferentes, pero me da que .NET (y creo que J2EE también) son perfectamente capaces para hacer lo que describe #29 . Tal vez un sólo mainframe no sería capaz de hacer 3000 transacciones de esas por segundo, pero escala muy bien (mirad Google, amazon... no tienen Cobol por ningún sitio, acaso un banco tiene más movimientos que éstos??) y el código es más fácil de desarrollar y, sobre todo, de mantener.
#28 y en Cobol no utilizais librerías 'de alto nivel' que ya están desarrolladas? o programais siempre todo desde cero? está claro que todos los métodos están ya hechos pero, oh wait! de eso se trata, de no reinventar la rueda.
#29 bájate de la parra macho (qué es eso de 'un lenguaje de programación de verdad'?? el resto de los ingenieros somos de segunda o así??). Te parece que esas tropecientas líneas son más claras que su equivalente en Ruby?? anda ya!! eso es objetivamente falso. Por no hablar del diseño del código, que aplicar un patrón mínimamente complejo (Activerecord, mismamente) me temo que debe ser, cuando menos, labor de maestros (no me refiero a ti, eh, que sólo nos faltaba que te lo creas más si cabe). Pobre del becario, necesitas un año para formar a alguien mínimamente. Por cierto, tenemos una aplicación Rails (es web pero sólo ofrece una interfaz REST) en un famoso hospital universatrio madrileño que está atendiendo 2000-3000 peticiones por segundo, con transacciones nada triviales, y funciona de maravilla. Nos ha costado desarrollarlo un par de meses, y mantenerlos es sencillísimo, ya que cuando lees el código casi lees en inglés.
De todos modos, sólo quería decir que me parece que las aplicaciones Cobol son muchísimo más costosas (intrínseco en la complejidad del lenguaje) en mantenimiento que las otras, por muy potente que sea el lenguaje.
Perdón si he ofendido a alguien (where #29 != alguien)