Jean E. Sammet, Ingeniera de Software y diseñadora de COBOL, lenguaje de programación que llevó la computación a los negocios, murió el 20 de Mayo en Maryland, tenia 89 años.
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.
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
#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).
#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)
#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".
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.
#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.
#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.
#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.
#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.
#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.
#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ó.
#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."
#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.
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).
#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"
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.
#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
#13No 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.
#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.
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!
#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.
#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.
#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.
![Muere Jean Sammet, Co-Diseñadora de COBOL [ENG]](https://peta.meneame.net/backend/media?type=link&id=2782637&version=0&ts=1496663346&image.jpeg)
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.
Su obra va a sobrevivirla por muchos años
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.
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.
Programar en Cobol es el castigo de Sísifo aplicado a informáticos. Sólo Java se acerca a su verborrea insustancial.
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.
Ya sé que la cita es falsa, pero me lo has puesto a huevo
PD: Pedante
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.
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.
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?
Sin acritud y de buen rollo.
Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada.
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.
es.wikipedia.org/wiki/Grace_Murray_Hopper
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ó.
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."
Propaganda y machismo para puretas acomplejados.
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).
www.ibm.com/developerworks/library/l-guile/index.html
Scheme es el sencillito, clisp es una locura.
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.
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
Algunos tenéis la piel muy fina para ofenderos y resulta que ni sabéis por qué.
Sin acritud
www.digital-sa.com/tienda/
C manda y mandó.
Sin acritud y de buen rollo.
Totalmente de acuerdo.
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.
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.
Ahora cuando vuelvo a España y oigo Jabascript me suena fatal también