Portada
mis comunidades
otras secciones
![Muere Jean Sammet, Co-Diseñadora de COBOL [ENG]](https://cdn.mnmstatic.net/cache/2a/75/media_thumb_2x-link-2782637.jpeg?1496663346)
#11:
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. ADIOS.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "RIP Jean E. Sammet" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
000200 PROGRAM-ID. ADIOS.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "RIP Jean E. Sammet" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
#13:
Ahí van mis siete espacios en tu honor (no se ven porque esta web hace un trim, pero tú me entiendes). Si llegas a ver la mierda de programación que hay ahora hubieses muerto mucho antes. Unos programas cobol pueden estar corriendo sin fallo en una máquina de la memoria de una calculadora científica actual durante 20 años.
Y eran programas lineales, con funciones, como dios manda para luego poder entenderlos y arreglarlos cuando crezcan. No la puta mierda que nos sobrevendieron de la programación orientada a objetos que está muy bien hasta que te toca hacer algo realmente grande y se convierte en un brocoli gigante imposible de meterle mano.
Y eran programas lineales, con funciones, como dios manda para luego poder entenderlos y arreglarlos cuando crezcan. No la puta mierda que nos sobrevendieron de la programación orientada a objetos que está muy bien hasta que te toca hacer algo realmente grande y se convierte en un brocoli gigante imposible de meterle mano.
#3:
No sé qué lenguajes habrá en el futuro, pero seguro que Cobol estará todavía allí. Bill Gates.
#68:
#5 la cuestión que me atormenta es: qué pasó en la informática para que después de prodigios sencillos y rápidos como COBOL o PL/1 apareciera y triunfara el horror de Java?
Por suerte lenguajes como Python recuperan ese espíritu pero nunca entenderé porque todo lo que se ha hecho en Java no se hizo en otros lenguajes mas amigables con similares posibilidades
Por suerte lenguajes como Python recuperan ese espíritu pero nunca entenderé porque todo lo que se ha hecho en Java no se hizo en otros lenguajes mas amigables con similares posibilidades
#70:
si si, pero sin C ahora mismo estaríamos hablando de OBOL... BASI... PAS AL...
#5:
Cuando llegue al infierno Satanás la pondrá a programar en Java y entonces sabrá lo que es el sufrimiento.
Comentarios
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. ADIOS.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "RIP Jean E. Sammet" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
#11 Casi he llorado con esto.
#11 ¿Porqué copias los números de línea del editor ispf?
#11 PERFORM THRU
#11 Ouch.... acabas de llevarme 15 años al pasado cuando tenia que vermelas con monstruos en COBOL y modificar informes
#11 Menudos recuerdos me traen esas lineas.Lo jodido que era revisar cuando decia que tenias 300 errores en 1000 lineas y era porque se te habia olvidado un jodido punto al final de la instruccion.
#11 Que recuerdos me traen esas lineas. Que tiempos en los que te aparecian 300 errores en 1000 lineas de codigo y era porque se te habia olvidado un jodido punto al final de la instruccion.
#11 Que recuerdos me traen esas lineas. Que tiempos en los que te aparecian 300 errores en 1000 lineas de codigo y era porque se te habia olvidado un jodido punto al final de la instruccion.
#11 Hello word...bye world
Ahí van mis siete espacios en tu honor (no se ven porque esta web hace un trim, pero tú me entiendes). Si llegas a ver la mierda de programación que hay ahora hubieses muerto mucho antes. Unos programas cobol pueden estar corriendo sin fallo en una máquina de la memoria de una calculadora científica actual durante 20 años.
Y eran programas lineales, con funciones, como dios manda para luego poder entenderlos y arreglarlos cuando crezcan. No la puta mierda que nos sobrevendieron de la programación orientada a objetos que está muy bien hasta que te toca hacer algo realmente grande y se convierte en un brocoli gigante imposible de meterle mano.
#13 También otros entendemos lo de hacer trim (recortar espacios alrededor de una cadena de caracteres). En fin...
#41 Lo que quizás no entenderás será lo de los 7 espacios...
#47 Trim, Substring... 7, 15 y los que quieras. Siempre que no sean más espacios que el ancho de la cadena funciona. Y si te referías a algún arcano que sólo los iniciados en menéame conocen, me pareció un poco ofensiva la forma en que lo escribiste.
Sin acritud y de buen rollo.
#48 Por un lado yo no lo escribí y por otro el 'arcano' está relacionado con COBOL, que es de lo que va este meneo.
Algunos tenéis la piel muy fina para ofenderos y resulta que ni sabéis por qué.
Sin acritud
#73 Tan poco ofendido que sólo llega a categoría de mosqueado.
Sin acritud y de buen rollo.
#76 Pues para la próxima, al menos intenta aclararte del motivo del mosqueo
#78 Paso.
#13 >. No la puta mierda que nos sobrevendieron de la programación orientada a objetos que está muy bien hasta que te toca hacer algo realmente grande y se convierte en un brocoli gigante imposible de meterle mano.
Echa un ojo a Smalltalk y Pharo. Ahí es donde la OOP tiene sentido. Java, C++ y demás son un quiero y no puedo.
#13 No la puta mierda que nos sobrevendieron de la programación orientada a objetos que está muy bien hasta que te toca hacer algo realmente grande y se convierte en un brocoli gigante imposible de meterle mano.
Totalmente de acuerdo.
No sé qué lenguajes habrá en el futuro, pero seguro que Cobol estará todavía allí. Bill Gates.
#3 Aprovechando los 640 kb a plena potencia.
Ya sé que la cita es falsa, pero me lo has puesto a huevo
#29 No será cierta pero si parecia que MS-DOS estaba diseñado bajo esa premisa y durante mucho años esa limitación pesaba como una losa
Cuando llegue al infierno Satanás la pondrá a programar en Java y entonces sabrá lo que es el sufrimiento.
#5 la cuestión que me atormenta es: qué pasó en la informática para que después de prodigios sencillos y rápidos como COBOL o PL/1 apareciera y triunfara el horror de Java?
Por suerte lenguajes como Python recuperan ese espíritu pero nunca entenderé porque todo lo que se ha hecho en Java no se hizo en otros lenguajes mas amigables con similares posibilidades
Tenía una profesora de cobol andaluza. Qué risas que me echaba con la wokin eztorahe zezion...
#14 Me pasaba algo parecido cuando aterrizamos en España, escuchar decir o-ra-cle leído literalmente era para partirse. Siempre les preguntaba que si habían leído a Sha-kes-pe-a-re.
#91
Ahora cuando vuelvo a España y oigo Jabascript me suena fatal también
#25 Muchas veces, sin embargo, más nuevo no significa mejor. Sobre todo si hablamos de aplicativos transaccionales de muchísimo volumen (fábricas, bancos).
#32 Está claro que depende totalmente del proyecto. Pero en aquellos sistemas en los que se desarrolla a diario, las nuevas tecnologías sí te permiten muchas veces eliminar barreras de acceso a nuevos programadores, y facilitar el desarrollo. Y en mi experiencia (que no es en esos ámbitos que comentas), los que te suelen decir eso suelen ser los que no tienen mucha idea y sí mucho miedo de tocar algo que no controlan (o de que les vayas a dejar mal).
En todo caso creo que si la arquitectura está bien hecha, siempre habrá maneras de integrar "nuevas tecnologías" en aquellos apartados en los que aportarán valor (por ejemplo interfaz visual), dejando el "core" de la aplicación en modo "no toques".
El contexto determina la validez de la premisa.
#36 Conozco una pequeña empresa de venta de componentes electrónicos.
Les hicieron una aplicación en Cobol en los años 80 que funcionaba como un reloj.
A día de hoy la siguen utilizando para la gestión diaria de todo el stock.
Obviamente la aplicación corre en un sistema Novell Virtualizado.
El dueño de la empresa dice que el software funciona perfectamente, costó una pequeña fortuna y hace bien su trabajo.
¿Para qué cambiarlo?
#45 Creo que has obviado una parte importante de la argumentación: "en aquellos sistemas en los que se desarrolla a diario".
Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada.
#49 Aquí dices que: "Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada."
Y a la vez, en #10 , todo lo contrario: "Filosofía que básicamente mata de raíz todo intento de mejora en muchas empresas. No romperás casi nada, eso sí. Solo te quedarás estancado."
#59 Bien. Veo que me explico muy mal.
Mi contexto: empresa de desarrollo. Hablo desde el punto de vista de alguien que, diariamente, tiene que modificar un software, por incidencias o por mejoras. En ese contexto, la frase "si funciona no lo toques", tal y como he dicho en #25 y desarrollado en #36, en mi experiencia, pocas veces se aplica por cuestiones técnicas y es discutible.
Desde luego si me planteas la opción de #45, donde no hay nada que arreglar ni que mejorar, ni se plantea la cuestión. Y, en casos como ha detallado #32, puede que no aporte nada una nueva tecnología o un nuevo enfoque.
Por tanto, sí, mi frase en #25 generaliza, igual que la de #10, luego él puntualiza, y yo también, y todos somos felices (al menos yo, porque básicamente estoy de acuerdo con él).
#62 SE me olvidó un al final de mi comentario... igual así se entiende mejor.
En realidad estoy de acuerdo. "si funciona no lo toques".... si se trabaja con herramientas obsoletas que impidean realizar cambios, no te dan la funcionalidad que necesitas, o todo ello es muy ineficiente por carecer de personal que domine dichas herramientas... pues esta claro, lo que tienes no funciona, hay que cambiarlo.
#45 Esa empresa no estará por casualidad en Valencia? Si no es así, conozco otra con el mismo caso
#72 No es en Madrid, se llama "Digital".
http://www.digital-sa.com/tienda/
#36 Tu hablas de interfaces, lo que yo llamo "maquillaje". He visto sistemas cuyo interface es totalmente "moderno" (graficos, interfaz http y colorines) y cuya base son aplicativos de hace 30 años que funcionan como relojes. De hecho, esa carcasa (desarrollada a posteriori) se ha jodido algunas veces, y todo es llanto y crujir de dientes, mientras que el sistema base sigue funcionando de modo genial accesible por transacciones en modo directo (emulacion 3270). Pero claro, no pidas a determinados usuarios que sepan usar un CICS en nativo.
#61 Desde luego. Como he dicho antes, si la arquitectura está bien hecha, modificar la base de una aplicación para mejorar la parte visual no es necesario.
Ahora, en mundos menos ideales, muchos aplicativos se hicieron con los pies hace 20 años, es lo que hay, y hay que seguir manteniéndolos hoy en día con el infierno de capas de cebolla que se han ido creando por gente que tenía miedo de tocar la base y se han dedicado a crear sucesivas capas por encima "para no romper nada". Después de 20 años y 15 desarrolladores, el panorama suele ser desolador. Y cuando planteas tocar algo de la base te dicen "nooooo, loco!".
Cuando en la empresa queda alguien que sabe como funciona la "base", no suele haber problemas. Cuando jubilaron a todos los que había hace 5 años para poner a becarios a mantener un sistema del que no tienen ni idea es cuando empieza la fiesta.
Para que nos entendamos: si la arquitectura es buena, la tecnología es secundaria, y el crecimiento de la aplicación se puede gestionar. Si la arquitectura es mala, crecer durante años encima de ella no suele ser buena idea.
#65 O que cambia el sistema operativo, algún registro cambia de tamaño y el cobol que es tan cuadriculado con los datos pues se ha de "retocar". Y el que parió la aplicación hace diez años que se jubiló y los que venían después no habían ni oído hablar de esa aplicación... simplemente porque nunca había dado problemas.
Aquí... "apaños martínez"
#32 deja de romperle los sueños a los que ya están ahorrando para el nuevo iPhone
si si, pero sin C ahora mismo estaríamos hablando de OBOL... BASI... PAS AL...
#70 Java's RIP
En esa época los hombres se centraban en diseñar y mejorar los primeros ordenadores, y consideraban la programación algo secundario, con escaso reconocimiento, por eso fueron mujeres las primeras programadoras, que definieron los primeros lenguajes de uso común para las diferentes máquinas. Fue Bill Gates el que cambió la tendencia y vio la importancia y el negocio en el campo de la programación
#19 Yo creo que es más complejo que eso. En los 50-70, la informática estaba ligada a las ciencias físicas y matemáticas en un contexto académico. Allí, las mujeres estaban mejor representadas que en la empresa privada. Tampoco había prejuicios sobre lo que significaba programar, sino que era un campo nuevo, donde los jóvenes científicos, tanto hombres como mujeres estaban concentrando su investigación.
No sé lo que pasó en los 80, que la informática se empezó a llenar de connotaciones negativas para la mujer. Quizá alguien lo pueda explicar mejor, pero me parece muy triste. Tampoco me gusta que se le eche la culpa a los hombres sin pensar profundamente en qué pasó.
#56 http://flashbak.com/women-and-computers-in-the-1960s-and-1970s-photos-of-every-day-sexism-13560/
Propaganda y machismo para puretas acomplejados.
#56 Te digo lo que pasó, la informática pasó de la academia a la empresa y de la empresa al público.
#80 de acuerdo, pero ¿qué pasó en esa transición?
#85 Pues que empezaron a vender a hombres que era lo único que había en las empresas y los únicos consumidores de informática personal.
#56 ¿Sabes quien fue la primera persona que publicó un programa de software? Una mujer en pleno siglo XIX haciendo unas anotaciones sobre el trabajo de un hombre, esas anotaciones son impresionantes, una visionaria en toda regla, y el algoritmo que publicó es para un cálculo matemático muy complejo.
#90 ¿Hablas de Ada Lovelace?
#19 Hacía tiempo que no leía una ristra de idioteces tan grandes. Mi duda ahora es que cual es la mayor burrada, si lo que dices de las mujeres o lo de Bill Gates "cambiando tendencia".
#88 Pues es historia. Mujeres que hicieron a toda prisa el software para cálculo de trayectorias para la presentación de uno de los primeros ordenadores y luego ni eran invitadas a la fiesta de presentación con los ingenieros que fabricaron la máquina.
Silicon valley se sigue dedicando al silicio, a fabricar microprocesadores como en los 50-70? o ahora se dedican al software? Bill no cambió la tendencia, pero su empresa si.
Ahh... COBOL, el lenguaje de las instituciones ancladas en el pasado y las finanzas.
Su obra va a sobrevivirla por muchos años
#9 Si funciona: no lo toques.
#10 Filosofía que básicamente mata de raíz todo intento de mejora en muchas empresas. No romperás casi nada, eso sí. Solo te quedarás estancado.
#9 Echa un vistazo al IBEX-35. Probablemente casi todas las empresas que están ahí, sus sistemas informáticos funcionen por debajo con COBOL.
No es que estén ancladas en el pasado, es que no hay ningún lenguaje mejor para el propósito al que sirve COBOL.
#20 Lo de anclado en el pasado no es tanto por el COBOL sino por el inmovilismo que suelen tener. Vease, bancos.
#21 Hay más empresas que bancos. Automovilísticas en Europa casi todas, Airbus también así a bote pronto.
#20 de la Wikipedia:
COBOL has been criticized throughout its life, however, for its verbosity, design process and poor support for structured programming, which resulted in monolithic and incomprehensible programs.
#20 No es que no haya un lenguaje mejor sino que lo que hay funciona más o menos y migrarlo es una obra faraónica.
#9 Una profesión del futuro será la paleoinformática.
#0 Hace casi un mes.
#1 El COBOL nunca fue excesivamente veloz pero la noticia ha sido compilada correctamente.
#6 ¿qué nunca fue veloz?, al contrario, pocos sistemas hay tan veloces, fiables y estables como los que hay montados en Cobol.
#18 #24 #34 Creo que era un chiste
#6 No tienes ni idea, es de los lenguajes avanzados más cerca al ensamblador que hay.
#24 Forth también es una bala.
#51 De la misma manera que algunos insisten en llamar GNU/Linux, creo que hay que llamarlo Forth/Leo Brodie.
#6 pues programe en cobol unos años y no lo recuerdo veloz, lo recuerdo prácticamente inmediato. He visto peña manejar programas en cobol sin tocar un ratón a una velocidad que ningún lenguaje lento sería capaz de soportar ( y de paso diré que en general tras muchos años de uso, y robusto como el primer día)
#1 No está en la sección de Actualidad y no es dupe, todo correcto
Que los dioses de kobol estén con ella al pasar al otro lado.
#23 Eso decimos todos!
Fui programador cobol/400 ahora de java, pero aqueella fue mejor época de largo.
#12 Es que erás más joven...
He añadido el [ENG], sorry, lo olvidé al publicarla
El karma es ineludible.
#63 Es una variante. LISP se dividió en dos, CLISP y SCHEME.
Scheme es el sencillito, clisp es una locura.
#22 Scheme es dios. https://www.gnu.org/software/artanis/
#53 no lo conocía- Según veo en esta página es más o menos lo mismo que LISP, con sus millones de paréntesis:
https://www.ibm.com/developerworks/library/l-guile/index.html
R.I.P. Y gracias...
Decir que programar en lenguaje COBOL es más divertido, más fácil, más productivo, más bonito, más legible, etc... que Java o C++, es ir muy de hipster desesperado. También es de no tener ni puñetera idea.
Gracias por crear un lenguaje horrible que aún persiste hasta nuestros días, mujer tenía que ser. LOL.
C manda y mandó.
Cobol, lenguaje tormento de ingenieros y personas inquietas y capaces.
Programar en Cobol es el castigo de Sísifo aplicado a informáticos. Sólo Java se acerca a su verborrea insustancial.
#15 echa un ojo a LISP, por ejemplo.
#15 No es tan complicado.
#15 ¿El cobol verborrea? ¡Si son 4 intrucciones!
PD: Pedante
Su obra la sobrevivirá sine die
#4 ¿la? ¿no será "le sobrevirá...?
#40 Sí, es "le". Es un complemento indirecto.
Creí que quien inventó COBOl fue Grace Hopper:
https://es.wikipedia.org/wiki/Grace_Murray_Hopper
El lenguaje de programación mas tedioso y con más estructuras inútiles fue Co-diseñado por una mujer....ahora encaja todo.
Se están muriendo los patriarcas!!! ¿después quien sigue? nosotros?
Ese lenguaje con el que se puede resetear una tabla interna con un sólo MOVE sin arriesgarse a dejar un solo byte de basura, redefiniendo el registro de la tabla en un campo comp-3 en la working storage... el mejor truco que aprendí en COBOL... un ahorro de tantos bucles de reseteo como registros tenga la tabla... qué tiempos!