Regístrate | Conectar
El Tamiz Libros Recursos Series Únete 16 Users Online
Skip to content

Historia de un Viejo Informático. La Programación Estructurada.




En la entrada anterior comenté, entre otras muchas cosas, que a principios de los ochenta se comenzó a utilizar en España de forma sistemática la nueva técnica de Diseño Estructurado de Programas. Esto no quiere decir que fuera inmediatamente adoptada por todas las empresas, no. Las empresas pioneras, el banco donde trabajaba entonces entre ellas, comenzaron a usar Programación Estructurada de forma generalizada (incluso, al cabo de poco tiempo, y visto lo bien que nos fue durante los primeros tiempos, de forma obligatoria). El diseño y codificación de los nuevos programas se hizo más rápido, y con mayor fiabilidad, pero sobre todo se ganó muchísimo en el mantenimiento de los programas a lo largo de los años.

Pero la adopción de la nueva técnica no fue tampoco un camino de rosas. Siempre había algún virguero de la codificación tradicional que era capaz de, GOTO p’arriba, GOTO p’abajo, hacer el mismo programa más rápido y más eficiente que cualquiera, con o sin estructuras. Hubo bastante controversia (no sólo en España) sobre la manera de codificar en los lenguajes de la época (todos ellos  ”procedurales”, desde luego), con o sin GOTOs, con o sin Inicio y Final obligatorio…

Antes de entrar en cómo nos fuimos adaptando al nuevo método de programación, debo obligatoriamente, fiel a mi estilo lenguaraz, describir qué es la Programación Estructurada, y daros unas pinceladas históricas.

 

Organigrama típico (años 70).

Organigrama típico (años 70).

Ya sabéis que en los cincuentas, sesentas y primeros setentas, los informáticos de la época (en muchos casos, ingenieros metidos a informáticos), programaban sus rutinas como buenamente sabían y podían. Fueron inventando las diversas maneras de programar conforme programaban, con lo que los más avispados (o afortunados, quién sabe) fueron encontrando maneras de solucionar problemas diversos sobre la marcha.

Pero, en definitiva, la forma aceptada de programar era, mayormente, a la “mecagüendiez”, traducción castiza del no menos castizo “cada maestrillo tiene su librillo”.

En una entrada anterior, ya incluí un organigrama añejo copiado literalmente de la pizarra, donde, en Segundo de Carrera, un profesor explicaba el método para actualizar ficheros indexados.

En una palabra, en los primeros setenta, ésa era toda la cera que ardía…

Claro que, si nos damos cuenta, el problema no era todavía excesivamente importante: Había pocos ordenadores funcionando, y no había muchos programas en Producción, y, sobre todo, éstos eran muy pequeños. No había otro remedio, con 8, 16 ó 32Kb de memoria, no se podían hacer programas muy complejos, simplemente porque no cabían.

…Y sin embargo, alguien estaba ya dándose cuenta de que esa no era la manera correcta de programar de cara al futuro. Cuando el uso de las máquinas se fuera generalizando, éstas fueran cada vez más y más potentes, y más y más programadores se fueran incorporando a la profesión, los programas spaghetti no serían adecuados, debido no sólo a la dificultad de diseñarlos, programarlos y probarlos, sino sobre todo, de mantenerlos.

Conforme más y más aplicaciones se ponían en marcha, más y más aplicaciones había que mantener, modificar, cambiar… y la programación “personal” constituía un problema serio, sobre todo cuando el autor original del engendro, eeeh, digo, del programa, ya no estaba en la empresa para desentrañar lo que ahí dentro había (…y a veces, ni así).

En 1966, Bohm y Jacopini publicaron un artículo en el que demostraron formalmente que, usando exclusivamente tres estructuras de control era posible programar cualquier función computable. Las tres estructuras eran, claro está, la secuencial, la repetitiva y la alternativa. Combinándolas recursivamente es factible realizar cualquier programa.

  Las tres estructuras básicas: Secuencia, Iteración y Selección.

Las tres estructuras básicas: Secuencia, Iteración y Selección.

Una Secuencia consiste en una serie de elementos que ocurren secuencialmente, uno detrás de otro, y siempre en el mismo orden. Esta serie de elementos podría estar vacía, es decir, no contener elemento alguno.

Una Repetición (o iteración) consiste en un único elemento que se repite una y otra vez, o ninguna, hasta que cierta condición sea satisfecha. O lo que es lo mismo, de 0 a n veces, mientras se satisfaga una cierta condición.

Una alternativa (o selección) consiste en dos elementos, de los que sólo ocurre uno u otro, dependiendo de cierta condición. Aunque en principio se definen sólo dos elementos para definir la selección, no hay ningún problema en permitir más de dos ramas, siempre que sólo ocurra una de ellas, dependiendo siempre de dicha condición (en realidad es el resultado de des-anidar varias selecciones anidadas).

No obstante su importancia para la ciencia de la computación, el artículo de Bohm y Jacopini fue poco menos que ignorado, ya que ellos se limitaron a demostrar matemáticamente que esto era así (lo que hoy en día se conoce como Teorema de Bohm y Jacopini), pero no rompieron lanza alguna para defender que programar en base al uso de las tres estructuras fuera bueno y recomendable. Y todo el mundo siguió a su bola…

Hasta que uno de los científicos de la computación más reputados de entonces, y de todos los tiempos, el holandés Edsger W. Dijkstra publicó en 1968 su famoso artículo “Go To Statement Considered Harmful”, en el que cargó con armas y bagajes contra el uso (y el abuso) de la sentencia de bifurcación, abogando fuertemente por el uso exclusivo de las tres sentencias básicas.

Edsger W. Dijkstra

Edsger W. Dijkstra

La (reducida) comunidad informática de entonces aceptó bien, en general, la recomendación del maestro, pero seguía habiendo dificultades: todo esto está muy bien, pero, ante una necesidad determinada, cuando hay que resolver un problema concreto, ¿cómo diseñamos y codificamos el programa usando exclusivamente las tres estructuras?; en definitiva, ¿cuál debe ser el método a seguir?

Por tanto, no fue hasta que se comenzaron a formalizar métodos de Diseño Estructurado de Programas que se comenzó a considerar en serio la posibilidad de utilizar la técnica en el mundo real.

Y el primero que realizó esta necesaria formalización fue el ingeniero francés Jean Dominique Warnier, a la sazón trabajando en Bull, que publicó en 1972 su libro “Logique de Construction de Programmes”.

Proporcionaba, por primera vez, un método sencillo y potente para diseñar un programa usando sólo las tres estructuras, utilizando llaves (estas llaves:{“ ) que permitían definir el nivel siguiente, que a su vez se descomponía en otros, usando más llaves…

Se fijaba en los datos que tenía que tratar el programa para obtener la estructura correcta de tratamiento. Y obligaba siempre a especificar que cada bloque lógico tuviera un principio y un fin, aunque no hubiera nada que hacer allí, y estuvieran vacíos. Esto último, por muy completo que fuese, que lo es, fue lo que menos gustó al informático de calle, como podéis suponer.

 

Un típico Diagrama Warnier

Un típico Diagrama Warnier

El resultado de diseñar un programa con su método era como el que veis aquí al ladito, pintado a mano, naturalmente, que era como se hacían las cosas entonces.

Indudablemente, representó un gran avance. Mi primer contacto con esta nueva Programación Estructurada fue en Tercero de Carrera, donde en una asignatura de nombre “Metodología de la Programación”, el profesor dedicó un par de días o tres, no más, a explicar el método Warnier (por si os lo preguntáis, el resto de la asignatura versaba sobre el manejo de tablas, listas, árboles, y su representación, como la Polaca y la Polaca inversa, y su tratamiento en algoritmos: ordenación, búsquedas dicotómicas y hash, LIFOs –Pilas- y FIFOs –Colas-, etc; era una asignatura divertidísima).

En España, Bull tradujo del francés y publicó el libro de Warnier con el nombre de “La Programación Lógica”, libro que yo tenía, que presté… y que no he vuelto a ver. En fin.

La publicación de este método no tuvo, sin embargo, la repercusión que hubiera debido, por dos causas: primero, no se centraba en ningún lenguaje concreto, es decir, no daba instrucciones concretas sobre cómo llevar a la práctica sus predicados en Fortran, o Cobol, Assembler o lo que fuera. Y segunda, ¡era una cosa “not invented here” ! Como era obra de un francés, y publicada originalmente en francés, el mundo anglosajón no entró mucho al trapo… Entonces, igual que ahora, la informática se escribía en inglés, en inglés americano, para más señas. Y Jean Dominique Warnier era francés, había cometido la tropelía de publicar originalmente en francés… y para colmo, trabajaba en Bull, una empresa francesa.

Jean Dominique Warnier

Jean Dominique Warnier

No fue hasta que Ken Orr, a principios de los ochenta, publicó su método, muy similar al de (o basado en el de) Warnier, denominado Warnier-Orr en la literatura, que el mundo anglosajón descubrió a Warnier… ¡y cómo!, puesto que fue adoptado por una de las Metodologías importantes de Desarrollo de mediados y finales de los 80: Method/1, de Arthur Andersen (que aún no se había convertido en Andersen Consulting, ni mucho menos en Accenture).

Me encantaba Method/1: Como cuarenta o cincuenta o más, no me acuerdo, volúmenes de ochocientas o mil páginas cada uno… que nadie leyó nunca, claro, más allá de algún resumen. Pero especificaba todo, todo, todo lo que había que hacer, de qué manera documentar, quién debía firmar, etc, para asegurar que… para asegurar que… eeh

…Bueno, en teoría para asegurar que el proyecto se ejecutaba conforme a especificaciones, tiempo y coste (cosa que nunca pasaba), así que en realidad lo que aseguraba era que… en caso de que el proyecto se fuera al garete, tú, pobre director del proyecto, tuvieras la espalda cubierta, mayormente. Pero esa es otra historia, y será contada en otro momento.

Gracias a Orr se arregló la segunda de las causas antes citadas (el idioma y el “not invented here”); en cuanto a la primera de ellas (la falta de normas específicas de codificación) la solventó en 1974 Marie Thérèse Bertini, cuando publicó, junto a Yves Tabourier como coautor, “Le Cobol Structuré” (en francés, claro está). Apenas se encuentra nada en la red para refrescarme la memoria, así que recurriré exclusivamente a ella.

Básicamente el “método Bertini” derivaba del de Warnier, ambos de origen francés, y creo recordar que colegas en Bull durante una temporada: una vez conseguido el diagrama todo lleno de llaves, Bertini lo que preconizaba era, aproximadamente, reescribir la estructura del programa, pero ahora con “cerezas” (es decir, circulitos) para cada bloque lógico, conectados con líneas, pero ahora la jerarquía no era de izquierda a derecha, como ocurría con la técnica de Warnier, sino de arriba abajo, lo que resultaba más natural.

Sin embargo, supongo que para mantener algún tipo de compatibilidad con las llavecitas, inexplicablemente se empeñó en que los niveles se codificaran de derecha a izquierda, y no de la forma natural para los occidentales, de izquierda a derecha. Aunque, si he de ser sincero, siempre que he visto un diagrama de Bertini, estaba escrito de izquierda a derecha, dijera el libro lo que dijera…

Pero lo importante fueron sus normas para codificar la cosa resultante en Cobol (y sólo en Cobol; no publicó nada, que yo sepa, para ningún otro lenguaje). No eran muy complicadas, y básicamente se centraban en tres aspectos:

Por un lado, la obligatoriedad de codificar los inicios y finales de cada bloque (mediante un PERFORM INICIO-TAL-COSA y PERFORM FIN-TAL-COSA, respectivamente), incluso aunque alguno estuviera vacío (porque no hubiera nada que hacer allí), en cuyo caso llevarían sólo la instrucción EXIT, que no es tal instrucción, como imaginaréis, pues sólo sirve para que un párrafo vacío no esté… vacío.

prohibido-goto

Por otro, la prohibición de codificar PERFORM .. THRU … Esto forzaba a que para codificar una alternativa, hubiera que hacerlo así: IF tal y tal  PERFORM FULANO  ELSE  PERFORM MENGANO. Por tanto, generaba una gran profusión de procesos anidados en cascada.

Y por fin, la prohibición total y absoluta para siempre jamás de usar el GOTO.

La verdad es que yo nunca fui bertiniano practicante, aunque sí me leí en su día lo que cayó en mis manos… ventajas de haber aprobado cuatro años de francés en el Instituto. O sea, que treinta años después no estoy seguro al 100% de si las tres reglas eran exactamente así, o me falta o sobra alguna: Si algún lector bondadoso es o fue bertiniano y detecta algún error, por favor que me lo comunique y lo corrijo de inmediato.

El método tuvo un cierto éxito, y se enseñó bastante en centros de formación durante unos años. Pero no era perfecto. Bien está que se prohíban los GOTOs indiscriminados, pero es que, si quieres usar toda la potencia del Cobol, en ciertos casos es obligatorio usar GOTOs. Por ejemplo, si codificas con más de una sección, lo que es bueno y recomendable por claridad, necesitas en todas ellas menos la principal dirigirte al final físico de la sección para poder devolver el control al proceso llamador. Y no se me ocurre otra forma de hacerlo que con un GOTO. Es decir, usar Bertini implicaba codificar todo el programa en una sola sección, y cuando tienes dos o tres mil líneas de código en la PROCEDURE DIVISION… no es exactamente una buena idea.

Además, existían ya en la época ciertos problemas que no habían recibido atención por parte de ninguno de aquéllos incipientes metodólogos.

M.A.Jackson

M.A.Jackson

Hasta que, en 1975, el científico de la computación inglés Michael A. Jackson (que, que yo sepa, además de ser blanco durante toda su vida, canta y baila fatal), publicó su “Principles of Program Design”.  Y el tema se solucionó. Literalmente. Definitivamente. Ya no se volvió a publicar ningún otro método general de Diseño Estructurado de Programas, pues no había mucho más que añadir.

Resolvió tanto el procedimiento formal de diseño, dotándole de una lógica aplastante, como esos “casos especiales” que molestaban a los otros métodos de diseño estructurado. Y además, preconizaba una forma de codificar en los lenguajes más importantes de la época, significativamente Cobol, Fortran y PL/1.

…Después del rollo que os llevo soltado, ¡no me quedo con las ganas de citar brevemente cómo es el Método de Jackson!, que por algo es mi preferido, además del más completo. Espero sepáis perdonarme…

Lo más impactante del método es que todo el diseño de la estructura del programa se basa en lo único que es completamente conocido, fijo y seguro: los datos. Efectivamente, todo programa que se precie (y que sirva para algo) debe leer y escribir ciertos datos, que estarán en cualquier tipo de soporte, y que tendrán una estructura determinada, conocida y fija (si no es así, malamente vamos a poder programar nada). Y a partir de la estructura intrínseca de los datos, va siguiendo unos pasos concretos y muy bien definidos que terminan con el programa codificado en pseudocódigo, o directamente en el lenguaje que sea.

La idea es que, dado un problema determinado que se aplica sobre ciertos datos conocidos, sólo haya una solución posible. Como supongo suponéis, esto no es exactamente así… pero hay que reconocer que se parece mucho.

La notación que utiliza para representar las tres estructuras famosas es arborescente, y bastante intuitiva:

Representación de las tres estructuras básicas en JSP

Representación de las tres estructuras básicas en JSP

 
Cada bloque individual puede estar a su vez descompuesto en cualquier otro tipo de estructura, lo que permite crear árboles tan grandes como deseemos. Y con esta notación se pueden representar tanto datos como programas. Veamos sucintamente el método, que preconiza cinco pasos secuenciales (en la página de la Wikipedia inglesa dedicada al JSP hay un ejemplo de los diagramas de cada uno de los pasos; así, si os interesa, podéis seguirlo con algún ejemplo, porque no lo voy a repetir aquí).

1 Establecer la Estructura de los Datos. De todos los datos, por separado, tanto los de entrada como los de salida.

2 Establecer las Correspondencias entre Datos. Para que haya correspondencia entre dos entidades de dos conjuntos de datos, sean de entrada o de salida, debe darse que: a) Ambas tengan el mismo número de elementos, y b) Éstos estén en el mismo orden en ambas entidades, o sea, ordenados de la misma forma.

Hasta aquí, fácil, ¿no?

Estructura del Programa.

Estructura del Programa.

3 Crear la Estructura del Programa. Para ello, cada entidad con correspondencias da origen a una única entidad, del mismo tipo, en la estructura final del programa, y el resto se insertarán en su lugar correspondiente, sin cambiarles de naturaleza. Como en este paso tratamos ya con procesos y no con datos, el propio nombre de las entidades cambia. La entidad de datos “CUENTA”, por ejemplo, pasará a llamarse ahora “PROCESAR CUENTA”. Aquí al lado tenéis un pequeño ejemplo de cómo estamos hasta este paso.

Tampoco esto es muy difícil…

4 Listar y asignar las operaciones individuales. Jackson propone un checklist de operaciones, que debe cumplimentarse en orden, para que no se olvide nada:

a) Instrucciones de finalización del programa.

b) Instrucciones de cierre de ficheros.

c) Instrucciones de apertura de ficheros.

d) Instrucciones de escritura en ficheros.

e) Instrucciones de lectura de Ficheros.

f) Instrucciones de movimiento de campos, entre ellos los de claves de ruptura.

g) Instrucciones de cálculo.

Una vez obtenida la lista, se asignan por riguroso orden las instrucciones a la estructura. ¿Dónde? Siempre en secuencia, y en aquél lugar donde la instrucción se ejecute una y sólo una vez, teniendo en cuenta las operaciones ya asignadas, para situarla antes o después de ellas. Siguiendo el orden preconizado en el checklist, es fácil determinar el lugar exacto donde asignar cada instrucción. ¿Cómo? Con un círculo (otra cereza, vaya), dentro del cuál se inserta el número ó código de la instrucción en la lista.

Sencillo ¿no?

El Resultado sería algo como el siguiente gráfico (bueno, normalmente, bastante más complicado), en el que el autor ha sustituido los circulitos para representar las instrucciones (las cerezas) por cuadrados, por razones tipográficas (supongo).

  Diseño de Programa con Instrucciones Asignadas (con cuadrados, no circulitos)

Diseño de Programa con Instrucciones Asignadas (con cuadrados, no circulitos)

5 Generar el pseudocódigo. Muy fashion en esa época, pero nadie escribía ya el pseudocódigo, sino directamente el programa. Tiempo que se ahorra uno… Para ello, Jackson propuso un sistema de codificación de sus estructuras en los lenguajes más usados del momento, sobre todo Cobol, Fortran y PL/1.

¡Hala! Ya tenemos el programa escrito. Un auténtico chollo. Sencillo, rápido, bien definido… Además, catorce programadores diferentes a cuál más raro, obtendrán la misma estructura, puesto que los datos son como son, están perfectamente definidos, y todo lo demás se deriva de ellos… Más o menos… O así…

Además, Jackson, en su libro de 1975, resolvió una serie de problemas que se plantean habitualmente en computación. Entre ellos, preconizó la lectura adelantada (eso, ahora obvio, de leer el primer registro de cada fichero nada más abrirlo, lo formalizó él), incluso la doble o triple lectura adelantada, cuando sean precisas; y sistematizó el procedimiento para mezclar dos o más ficheros por clave (¡otra vez el Padre-Hijo a escena!). Pero además, formalizó la solución a otra serie de problemas habituales:

a) El backtracking. En esta estructura especial se trata un conjunto de datos como si lo que hiciéramos fuera a valer, pero permitiendo cambiar de opinión cuando detectamos que nos hemos equivocado. Puede parecer algo poco útil, pero es que exactamente eso es lo que pasa en las transacciones online: Hay que validar, en primer lugar, que todos los campos de entrada son correctos y la acción demandada es factible; sólo cuando se ha verificado que todo es correcto, se procede a realizar las actualizaciones pertinentes. La validación puede resultar bastante complicada, accediendo a diferentes Bases de Datos, etc. Además, en cuanto se detecta un error, se informa del mismo al peticionario, y se termina el proceso de la transacción: no tiene sentido seguir validando y gastando ciclos de CPU cuando ya sabes que la transacción es errónea.

Diseñar este caso sin backtracking es… es un tostonazo, con ramas de alternativas bajo ramas de alternativas bajo ramas de alternativas… Un tostón; y sin embargo usar un backtracking resuelve el tema de forma elegante y sencilla, como podemos observar en el ejemplo siguiente.

Backtracking en acción

Backtracking en acción

b) La Programación Invertida. (¡y no valen chistes, que bastantes hacíamos ya nosotros entonces…!), que resuelve el problema de la colisión de estructuras (es decir, cuando no es posible encontrar correspondencias entre una entidad de la estructura de datos de entrada y otra entidad en la de salida). La solución obvia es dividir el programa en dos, mucho más sencillos, usando un fichero intermedio…

La inversión de programas resuelve la no correspondencia entre estructuras

La inversión de programas resuelve la no correspondencia entre estructuras

Pero este fichero intermedio rara vez queremos (o podemos permitir) que exista físicamente. Debe ser un fichero virtual. Lo que sistematiza el método de Jackson es un procedimiento para eliminar físicamente ese fichero intermedio, pero que sigue existiendo lógicamente, es decir, sin cambiar en nada ni la estructura ni la codificación de ambos programas. Se consigue “invirtiendo” uno de los dos programas respecto del otro, es decir, convirtiendo uno de los dos programas en una rutina de entrada (o de salida) del otro, y comunicándose exclusivamente ente sí con el registro del fichero intermedio, que comparten ambos programas.

Supongamos que hemos decidido convertir al primer programa P1 en rutina invertida de entrada del segundo, P2, que queda en este caso como el principal. En este último poco hay que hacer: cada vez que en él se lee el fichero intermedio, se sustituye por una simple llamada a P1 (y se eliminan Open y Close, obviamente). Únicamente hay que tener en cuenta cómo comunicar el fin del fichero: la solución obvia es pasar el registro con una marca (en Cobol, típicamente, HIGH-VALUES, es decir, “FF’s” hexadecimales).

Pero, en el otro lado, para el programa P1, el P2 es su propia rutina de salida… Así que, cada vez que en este programa P1 se debe escribir el registro del fichero intermedio, lo que ahora debe hacer es devolver el control a su llamador (P2) que se encargará de “escribir” el registro, y volverá a llamar a P1 cuando necesite un nuevo registro… e informándole, de paso, de que su registro ha sido escrito, y que puede seguir su proceso por donde iba.

Programa invertido ejecutándose

Programa invertido ejecutándose

En una palabra, ambos programas se ejecutan simultáneamente, en una especie de columpio, cediéndose mutuamente el control de la ejecución, y comunicándose exclusivamente mediante el área del registro del fichero intermedio.

Es una solución de una elegancia suprema, y una potencia inigualable. Además, no está restringida exclusivamente a procesos batch. Puede utilizarse también (yo lo he hecho en bastantes ocasiones) en la resolución de transacciones online. Y sin embargo, siempre ha sido muy poco utilizada, no por la dificultad de entender el mecanismo, que es realmente sencillo, sino por la aparente dificultad de codificar la inversión en el programa invertido, pues supone usar GOTOs extraños, incluso GOTOs condicionales (GO TO DEPENDING ON) que casi nadie quiere utilizar, porque dan yuyu… y se pierden una de las técnicas más poderosas de programación jamás inventada.

.

Bien, terminado el paseo por el Método de Jackson de Estructuración de Programas, desde entonces prácticamente no se ha avanzado más en la teoría, porque todo había quedado establecido. Jackson hizo un trabajo formidable, y realmente no dejó mucho más que rascar.

Y fue entonces, principios de los ochenta, cuando nos pusimos en España a utilizar técnicas de Programación Estructurada en empresas e instituciones. Pero antes de eso, hubo que dar a conocer la nueva técnica a los responsables de Informática, para convencerlos de que era mejor para sus negocios adoptarla.

Como podéis imaginar, en aquellos años los responsables de Proceso de Datos no estaban demasiado al tanto de las novedades que se producían en la profesión, primero por su origen (casi ninguno era informático de profesión, sino que provenían de puestos administrativos, y su formación era en otras áreas, quien la tenía, porque, por ejemplo, uno de los Directores de Informática que yo conocí comenzó su carrera en el Banco como botones, lo que dice mucho en favor de su capacidad), y luego, por el dichoso inglés. Apenas se hacían salidas a Conferencias el Extranjero, y no se leían muchas revistas especializadas americanas o inglesas, que además de ser incomprensibles (por el idioma) eran caras… pero caras.

Por lo tanto, el trabajo de promoción le correspondió a las Consultoras y/o Empresas de Formación, que vieron en esta nueva técnica una vía de incrementar su negocio, así que promocionaron intensamente su propagación.

Enseñando el método de Jackson

Enseñando el método de Jackson

Ninguna entidad se adhirió al asunto de inmediato, pero ciertamente muchas comenzaron a hacer sus pinitos, sus pruebas para ver si la cosa de verdad funcionaba (y mejoraba la productividad de la programación) o era un canto más de sirenas, de los que de tanto en cuando aparecen aquí y allá. Así que enviaron a recibir formación en las nuevas técnicas a uno, o dos, quizá cuatro programadores “escogidos” (escogidos por las razones que fueran), en cursos abiertos que duraban tres o cuatro días. Yo fui uno de esos elegidos, a finales de los setenta, en el primer Banco en el que estuve.

Estos pocos programadores, al volver a su instalación, comenzaban a utilizar la nueva técnica, sobre todo por curiosidad, inicialmente de forma balbuceante, pero poco a poco con mayor convicción. Hablo por mí, y también por otros colegas de otras instalaciones, pues la Programación Estructurada era un tema caliente de las conversaciones entre colegas de la época.

Hicimos nuestros pequeños pinitos, sí, pero no conseguíamos convencer a nuestros mayores de que fuera conveniente la adopción generalizada de la técnica, entre otras cosas, porque éramos simples programadores… o sea, unos mindundis.

Y de pronto, algo ocurría: ante la necesidad que acontecía de vez en cuando de escribir un programa complicadísimo de resolver (de esos a los que nadie se atrevía a hincarle el diente), entonces te lo encargaban para que lo escribieras de forma estructurada, con la coletilla de “Hala (listillo: esto lo pensaban pero no lo decían), a ver si eres capaz de resolver este embolado con esa cosa rara nueva…”, y todo esto con una aviesa sonrisilla de diablillo que te llegaba hasta el hígado…

…Y entonces el avispado programador, tocado en su amor propio, se ponía a diseñar y codificar el maldito programa… y resulta que, sorprendentemente, en mucho menos tiempo del que se suponía, el programa estaba listo, y encima funcionaba bien rápidamente (no, a la primera, no, que a la primera no funciona nunca nada…), y además no se eternizaba en máquina… Y entonces era cuando las fuerzas vivas comenzaban a darse cuenta de la potencia del asunto, y a tomárselo en serio.

Unos pocos adelantados fueron abriendo camino...

Unos pocos adelantados fueron abriendo camino...

Por lo que yo sé, procesos similares fueron ocurriendo poco a poco en diferentes Centros de Cálculo, conforme las historias de éxito iban siendo conocidas, y además, aunque las entidades (los Bancos, por ejemplo) fueran competencia unas de otras, entre los informáticos de entonces había una sana camaradería, por lo que unos íbamos contando a los otros nuestras experiencias, ayudando a desechar lo que no había funcionado y a extender lo que sí. Así que, a lo largo de la primera mitad de los ochenta, las empresas se fueron convenciendo gradualmente de la bondad de la Programación Estructurada, y sobre 1983-84 ya todos los Centros de Proceso de Datos importantes habían adoptado la técnica.

Y se prepararon Planes de Formación para reciclar a los profesionales más antiguos (en algunos casos se contrataron empresas de formación, en otros se utilizaron recursos internos, depende de lo tacaña que fuera la empresa), y todo el mundo fue convertido a la nueva religión estructurada. Aunque no todas las conversiones fueron completas, pues seguía habiendo adoradores de los antiguos dioses del GOTO que, siempre que podían, elevaban una ofrenda a su dios ancestral…

Muchos adoptaron el Método de Bertini, quizá no en su forma completa, pero sí al menos su principal mandamiento: “El que ponga un GOTO, ¡al infierno de cabeza!”. Una norma sencilla de entender por todo el mundo. No es ni mucho menos tan completa y eficaz como el Método de Jackson, pero obligaba necesariamente a codificar de forma estructurada, así que muchas consultoras y empresas de Servicios adoptaron el Método, pues ahorraba costes de formación a su personal, y les permitía ser productivos lo antes posible.

Otras empresas (aunque no tantas) adoptaron el Método de Jackson; la posibilidad de usar backtracking, sobre todo en un entorno transaccional, facilitaba enormemente la codificación de las validaciones, y la programación invertida resolvía algunos problemas muy molestos. Vale, Jackson permite usar GOTOs (no cualquier GOTO, desde luego, sino en ciertos sitios y lugares, y siempre “hacia abajo” nunca “hacia arriba”, según se explica en su libro original, el mítico “Principles of Program Design”). Y el uso de GOTOs no gustaba a algunos (muchos de ellos, desertores del spaghetti, pero en fin). Los buenos resultados que se obtuvieron eliminaron casi todas las reticencias en no mucho tiempo.

En el mundo Jackson, todo el mundo hacía el “mono”, o sea, la estructura del programa con las instrucciones asignadas, a partir del cuál se codificaba. Aparecieron diversos precompiladores y programas, entre ellos JSP-COBOL del propio Jackson, que ayudaban al diseño y codificación de programas escritos según este método. Pero ninguno tuvo mucho éxito entonces, al menos en España, por una razón evidente: ¡No había PC’s! Y los pocos que había, carísimos y con muy poca potencia, se dedicaban a otros menesteres, no para que un vulgar programador pintara su “mono”.

Una pena.  Si hubiéramos dispuesto entonces de las facilidades que hubo sólo cinco, seis o siete años después, cuando se generalizó el uso de PC’s en Proceso de Datos, seguramente otro gallo hubiera cantado. Pero las cosas fueron así. Porque ahora, cuando sí es posible fácilmente preparar un programa para, visualmente, diseñar y codificar el programa estructurado… no hay interés. Aquí tenéis un programita freeware que permite diseñar programas usando el Método de Jackson y generar luego el código en C o Pascal. Lo he probado en Firefox y aparentemente funciona bien y es muy intuitivo, pero en IE me ha dado un error de “Java Unsupported Version y tal pascual”, aunque quizá sea culpa de mi anticuada versión de IE.

Bien, entonces, a falta de precompiladores o productos que ayudaran en el diseño y codificación, los “monos” (los de Bertini o los de Jackson) se hacían a mano, y los programas se codificaban conforme a las prescripciones del método correspondiente… y a las manías y querencias del programador de turno.

Un manual de Normas...

Un manual de Normas...

Por eso las empresas (las instituciones de la Administración Pública también, pero más tarde, y menos) empezaron a emitir normas de programación, en las que se especificaba qué método de diseño se debía utilizar, y, lo más importante, cómo codificar el programa resultante. Tanto Bertini como Jackson proponían un método de codificación en Cobol (el lenguaje más usado con mucho en la época), así que en muchos casos se adaptó la normativa a lo que decían ambos métodos, aunque en otros se usaron normas diferentes, o una sana mezcla entre ambas posibilidades.

Además de prohibir los GOTOs (o restringirlos a los usos especificados en el método de Jackson), y especificar cómo codificar Secuencias, Alternativas y Repeticiones (y Backtrackings y tal, en su caso), se dieron normas de nomenclatura, sobre cómo llamar a los procesos y campos de los programas, así como a los ficheros, impresos, bases de datos, y a los propios programas en sí.

Todo este esfuerzo normativo fue muy importante: en unos momentos de enorme actividad (muchas empresas estaban construyendo Sistemas de Información nuevos, de los que una parte considerable permanecen hoy en día), asegurar una serie de criterios unificados de nomenclatura y codificación redundó en una mucha mayor facilidad de mantenimiento posterior.

En el artículo dedicado al Cobol cité el hecho de que programas escritos hace veinte o veinticinco años sigan funcionando, tras años de modificaciones, y que sigan siendo mantenibles. El uso de toda esta batería de normas rígidas a lo largo del tiempo ha facilitado, si no directamente permitido, que esto sea posible.

Normas, y más Normas

Normas, y más Normas

Muchas empresas no sólo se quedaron en la publicación de las normas y la obligación, más o menos “moral”, de su uso: escribieron programas que verificaban que los programas que se ponían en Producción cumplían escrupulosamente la normativa, y si no… en general impiden su puesta en Producción; pero en otras, se limitan a informar al autor para que se arregle el desaguisado, pero se permite su uso, de momento (esto es así para facilitar el arreglo de un programa malvado a las tres de la mañana…).

Tomar una u otra opción depende de la instalación, ambas son en principio válidas. Pero lo que sí es cierto es que, una vez que un programa está en Producción, y si funciona como es debido, nadie lo va a tocar motu propio sólo para arreglar su adecuación a las normas, con la cantidad de trabajo que hay que hacer… Por eso es lo generalmente preferido que el Portero del Cotarro no permita el uso en Producción del programa, hasta que esté convenientemente arreglado y quede de acuerdo a toda la normativa de codificación y nomenclatura de la empresa.

Cómo burlar al portero...

Cómo burlar al portero...

…Y claro, dada una norma, siempre hay quien se rompe la cabeza… para romperla. Parece que es una de las características del carácter de los españoles es saltarse, por puro placer, las normas establecidas, sólo por el hecho de hacerlo (ignoro si por ahí fuera esto ocurre también, aunque sospecho que mucho menos que acá). Y fuimos capaces de saltarnos las normas, ya lo creo. Por puro deporte, además, sin ningún ánimo de ser perniciosos.

Cuando no había programas que comprobaban el cumplimiento de las normas, era muy fácil: bastaba con inventarse un caso donde con un par de GOTOs se evitaba una estructura compleja… así que ya teníamos nuestra coartada. Pero cuando se implantaron los programas de control, ya no era tan fácil… y sin embargo lo conseguíamos.

Por ejemplo, para meter un GOTO y que se lo tragara el Portero, poníamos la G en la columna 72 de una línea, y en la siguiente línea poníamos un guión en la columna 7 (en Cobol esto significa que es una línea de continuación, y debe añadir su contenido al de la línea anterior: se usa sobre todo para literales largos), y después la O en la columna 12. El compilador recomponía el GO de ambas líneas y lo interpretaba sin problemas… ¡pero el programador del programa de verificación no había pensado que un verbo GO no estuviera en una sola línea! (Normal, ¿a quién se le ocurre, si no es para fastidiar…?). Y así engañábamos al sistema… que en definitiva era engañar a nuestros propios compañeros, o sea, a nosotros mismos… pero así nos lo pasábamos bien. En descargo mío, debo confesar que, las poquísimas veces que lo hice, luego lo arreglé en la siguiente modificación… pero hubo quien no.

Y así, años más tarde, somos quienes somos, estamos donde estamos y hacemos lo que hacemos… porque venimos de donde venimos.

¿Se usa actualmente la Programación Estructurada? Pues sí. Más o menos. Nadie pone GOTOs (que definitivamente son considerados por todo el mundo “harmful”, como Dijkstra decía en su día, cuarenta años ha). Pero se trata de una programación estructurada “intuitiva”, poco apoyada en fundamentos teóricos… porque no se enseñan, que yo sepa.

¿Se usan los métodos de diseño estructurado de programas? Pues no creo, al menos tal como fueron definidos. Hace años que no veo a ningún programador pintar un “mono” de ningún tipo. Las pocas veces que Yo hago uno, me miran como si viniera de Marte… Quizá porque ahora son mucho más inteligentes que nosotros lo éramos y no lo necesitan. Porque nosotros… nosotros que lo necesitábamos.

¿Es conveniente que se enseñen estos métodos? Bajo mi modestísimo punto de vista, desde luego que sí. Es más, cuando alguien comienza a estudiar informática, ESO sería lo primero que yo le enseñaría, y se lo grabaría a fuego para que no se le olvide nunca. Porque sigue siendo útil; más que útil, necesario. Por mucho que el paradigma de Orientación a Objetos haya cambiado la forma de concebir y diseñar las Aplicaciones, cada proceso que se debe realizar, lo queramos o no, sigue siendo un proceso susceptible de ser estructurado. Sobre todo si es un proceso complejo, que debe acceder a Bases de Datos, validar una serie de campos, generar una respuesta…

Y del batch, ya, ni hablamos. Porque sigue haciendo falta ejecutar procesos batch. Y ahí sí que no hay excusa. Y se ve cada cosa por ahí codificada… yo me he encontrado con barbaridades como para erizarte el cabello de la peluca. Sin ir más lejos, y esto es un caso real, acceder a la Base de Datos de Cuentas una vez por cada movimiento de la Cuenta, en lugar de una vez por cada Cuenta. Y eso es, ni más ni menos, que por no asignar correctamente la instrucción de lectura (la SELECT cuenta… FROM TABLA-CUENTAS WHERE …) en su lugar correspondiente de la estructura. Y eso es, a su vez, por no saber. Ni más ni menos. Y el programa funcionaba perfectamente, claro que sí. Utilizando ocho o diez veces más de los recursos necesarios. Y lo peor es que, cuando avisas al programador (amablemente, lo juro) para que modifique el programa, porque está mal parido y consume muchos recursos, ¡encima se mosquea!, que esto… esto es lo que menos entiendo.

Bueno, como de costumbre me he extendido más de la cuenta. Y como de costumbre solicito vuestra indulgencia para que perdonéis la incontinencia, de momento sólo verbal, de este pobre informático pasado de moda… Y, por supuesto, todos vuestros comentarios y sugerencias serán bien recibidos.

El próximo episodio no va mucho de batallitas. Éstas volverán en el que le siga, pero el próximo lo dedicaré a contaros qué es eso del “Sort”, que tantas veces aparece en mis notas, y que tantos quebraderos de cabeza nos ha dado a los informáticos desde hace tantos años… si sorprendentemente todavía estáis ahí para leerme, y el Gran Jefe Pedro aún me consiente que siga dando el tostón al personal…

Disfrutad de la vida, mientras podáis.


Sobre el autor:

Macluskey ( )

Macluskey es un informático de los tiempos heroicos, pero no ha dejado de trabajar en Informática y disfrutar con ella hasta la fecha. Y lo que el cuerpo aguante. Y además, le gusta la música...
 

{ 37 } Comentarios

  1. Gravatar Pedro | 16/03/2009 at 05:19 | Permalink

    “El Gran Jefe”, dice… “me consiente”, dice… hay que joderse. Debe de ser la edad :)

  2. Gravatar saxsurfer | 16/03/2009 at 08:27 | Permalink

    Acabo de descubrir el sitio vía Meneame. Sólo puedo decir una cosa: ¡lo has clavao!, Macluskey ( ). Yo disfruté de la formación en Warnier, que impulsó primero Bull España (vía Fernando Saez Vacas) y luego heredó ERIA. Tu descripción de las batallas anglo-francesas, del papel de Jackson como “formalizador”, etc. han actuado como una madalena proustiana sobre mí, así que te doy las gracias por “retrotraerme” al estado de entusiasta programador estructurado en el que yo estaba hace 30 años. Formidable repaso histórico y emocional del asunto. ¡Chapeau!

  3. Gravatar almenas | 16/03/2009 at 09:12 | Permalink

    Se me han saltado las lágrimas. Excelente artículo.

  4. Gravatar Macluskey | 16/03/2009 at 10:47 | Permalink

    @Pedro: hombreee, no sé a qué viene el cachondeo… si yo sólo he sido educado… al fin y al cabo, el sitio es tuyo, y los demás estamos de prestao…

    @saxsurfer, almenas: Pues me alegro que os haya gustado. Yo he de reconocer que me lo he pasado bomba preparando la entrada, buscando imágenes, recordando las técnicas… Yo también me he retrotraído veintipico años atrás.

    Gracias por vuestros comentarios…!

  5. Gravatar jesusiv | 16/03/2009 at 11:29 | Permalink

    Sigo aprendiendo… gracias por compartir tus conocimientos!!

  6. Gravatar Jimmy Jazz | 17/03/2009 at 10:04 | Permalink

    Muy bueno! Y me encantan las batallitas :)

    Salud!!

  7. Gravatar Rabade | 17/03/2009 at 10:22 | Permalink

    Mac, te estás poniendo el listón muy alto, ¡excelente artículo!. Confiemos en que los ‘cachorros’ (los hay muy buenos) sientan curiosidad por el tema. Puedo aportar una experiencia a finales de los 80 (mi aterrizaje en el entorno de Producción), me encontré un programa en Cobol con doscientas algo lineas de Procedure y GO TO p’aca, p’alla, p’arriba, p’abajo,… y al final GOTO FIN, no hacía nada de nada, como es evidente el pgm no nacío así, simplemente era fruto de la dificultad de mantenerlo, y cada programador que pasaba por él lo enmarañaba algo mas. Un saludo viejo colega.

  8. Gravatar Txema | 17/03/2009 at 11:53 | Permalink

    Felicidades por tu blog, magnifico post. He llegado a través de meneame y me has dado una sobredosis de nostalgia binaria que no te haces ni idea… yo soy tambien un viejo programador y puedo reconocer casi todas las cosas que mencionas por haber vivido muchas de ellas en carne propia. Felicidades de nuevo.

  9. Gravatar Aníbal Potenza | 17/03/2009 at 01:00 | Permalink

    Me parece buenísimo tu artículo. Yo enseño trabajo en sistemas y enseño Programación I en una Universidad de Argentina. Tan interesante me resultó que voy a decirle a mis alumnos que lean este artículo para que vean como fue el camino de la programción.

  10. Gravatar Rohel | 17/03/2009 at 01:21 | Permalink

    enhorabuena una vez mas, un gran articulo

    PD: comparto muchas cosas contigo, si alguien no sabe estructurar su programa, que se aparte y deje hueco… y lo dice uno que tiene una jefa “biologa” -> programadora que me miro con cara rara cuando le dije que una iteracion no respetaba las normas de la programacion estructurada

  11. Gravatar Macluskey | 17/03/2009 at 02:54 | Permalink

    Muchas gracias por vuestros comentarios, amigos. Creo que era importante poner en su contexto cómo fueron los comienzos del diseño de programas, inicialmente estructurados, ahora de otra manera.

    Me sigue sorprendiendo el enorme desconocimiento que, como regla general, tienen los profesionales modernos sobre la historia de su profesión… es como si todo lo que pasó antes no valiera, no existiera, hubiera que no sólo mejorarlo, que sí, sino borrarlo, hundirlo, olvidarlo…

    ¡Cuántas veces he escuchado frases como: “Mainframes, Cobol, Jackson, etc, son los dinosaurios de la informática y no sirven para nada y bla bla…”! Por puro desconocimiento, en muchos casos, y en muchos casos porque nadie les ha contado una palabra de estos bichos… que siguen siendo tan válidos como antes… y que siguen dirigiendo el mundo, por mucho que el C++ y el java molen más (que habría que verlo, sinceramente: ya me gustaría a mí ver dentro de treinta años cuántas de las aplicaciones que se están escribiendo ahora siguen funcionando…)

    Todas las horas invertidas en preparar esta serie están bien invertidas si algunos tienen con ella la oortunidad de aprender a valorar lo que no conocen… y los que sí lo conocéis, que sintáis legítima nostalgia.

    Saludos, y muchas gracias otra vez por vuestros ánimos.

    Macluskey, el lenguaraz

  12. Gravatar dasan | 17/03/2009 at 03:24 | Permalink

    llevo tiempo siguiendo esta serie de posts. Acabé FP de informática en 2001 y recuerdo que en el temario había que estudiar POO, pero tenía unos profesores muy viejos que solo sabían Cobol, programacion extructurada y ensamblador, así que nos enseñaron C++, programación extructurada y bases de datos con ficheros. El último año llegó un profesor más joven y nos dio bases de datos relacionales y conceptos teóricos de POO. (sólo teóricos porque no sabía darnos ejemplos prácticos, jaja).

  13. Gravatar pere | 17/03/2009 at 03:53 | Permalink

    Muy interesante artículo sobre el desarrollo de software decadas atrás, yo tras terminar la universidad pasé a un entorno mainframe IBM para banca y leyendo tu artículo he ilustrado muchos de tus ejemplos con recuerdos de aquella época: cobol, pl1, programación estructurada, normas de programación, validación de calidad,etc. Años atrás recopilé una serie de artículos relacionados con el mundo de los mainframes y escritos por un técnico en estos entornos, erán de una índole más técnica pero para los no iniciados eran bastante aclaradores, en cuanto lo tenga posteo el link.

  14. Gravatar José García | 17/03/2009 at 03:53 | Permalink

    Fenomenal el artículo. La programación estructurada es básica, hasta segundo de carrera no vi otra cosa que no fuese programación estructura. Por muy ‘objeto pensadores’ que queramos ser, somos más’ homo procedimentales’.

  15. Gravatar Osvaldo J Schiavoni | 17/03/2009 at 04:09 | Permalink

    ¡Qué tiempos aquellos! Hace bien al espíritu rememorarlos. Yo empecé a programar sin saber una pepa (igual que ahora, ja!) allá por 1973, luego de haber leído un libro sobre COBOL, de David McCraken. Recuerdo haber estado una semana peleando a brazo partido con unos cortes decontrol, hasta que un compañero se apiadó y me explicó cómo se debían manejar. También recuerdo las caras de incredulidad, y hasta de indignación, cuando nos enseñaron que el GO TO no iba más. ¡Era ABSOLUTAMENTE IMPOSIBLE dejar de usar el GO TO!!! Gracias, Macluskey , por el tiempo que le has dedicado a rescatar esta historia.

  16. Gravatar Fabio | 17/03/2009 at 05:32 | Permalink

    Hasta hace 7-8 años (no se ahora) en la Universidad Tecnológica Nacional, de Buenos Aires, Argentina, el primer curso de Algoritmos y Estructura de Datos daba la forma tradicional de programación estructurada, no daban objetos primero, daban ESTO!!! :)

    Así es que todavía me sale programar en PHP de forma estructurada, cada método de un objeto, algo de esto se me desliza :) es que es mucho más útil que crear 200 clases y métodos cuando algo se podía resolver en 3 o 4 líneas bien escritas.

    es interesante porque hoy día conozco ambos paradigmas y no me siento tan perdido al leer un script para perl, bash o lo que fuere, simplemente resulta lógico.

    He tenido problemas con varios de mis programadores que sólo conocieron POO, se quedaron en eso, por más que sea moderno, les falta la base, que es lógica pura, matemática, la programación estructurada es una forma que es anticuada, pero necesaria para entender cómo funciona un procesador. La abstracción de objetos es genial, pero es una abstracción.

  17. Gravatar Maki | 17/03/2009 at 06:35 | Permalink

    Buenas. Me he leído todas tus entradas, estoy estudiando informática y además soy bastante apasionado en estos temas y cada vez que veo en Meneame que has publicado una entrada nueva me guardo el enlace para leermelo tranquilamente en un hueco largo y sin interrupciones. Tengo envidia de los que han podido vivir esos tiempos, pero bueno, se hara lo que se pueda.

    Un saludo y espero que hagas muchas mas entradas!

  18. Gravatar Macluskey | 17/03/2009 at 08:25 | Permalink

    @Todos: Gracias de nuevo por vuestros comentarios.

    No entiendo muy bien la polémica que hay “programación estructurada” vs. “Programación Orientada a Objetos”. No sé a qué viene.

    Porque, ¿sabéis? el ordenador sigue siendo una máquina Von Neumann, que tiene la mala malísima costumbre de hacer las cosas secuencialmente. Primero a, luego b, y si c>d, salta a e, y así.

    El que nosotros no pongamos GOTOS (en estructurado, en objetos, en LISP o en Haskell, o como sea) el compilador SÍ que genera GOTOS. A cascoporro. ¿O es que nunca habéis programador en Assembler, o visto la generación del código máquina de vuestro maravilloso programa compilado?

    Los amigos Bohm y Jacopini no hablaban de un tipo especial de codificación extraña: Demostraron matemáticamente que Toda Función Computable se puede realizar con las tres estructuras. Cualquiera. Y PUNTO PELOTA.

    Por muchas capas de abstracción que pongamos, al final, siempre estará el GOTO…

    Saludos, y bienvenidos al mundo del GOTO (del que nunca nos hemos ido)

  19. Gravatar Camaron | 17/03/2009 at 11:22 | Permalink

    Pero estas loco o que? como puedes escribir tantas palabras juntas!!!

  20. Gravatar joel | 18/03/2009 at 01:18 | Permalink

    Bueno, a mi me ha costado bastante leerme todo el artículo (varias sesiones aunque nocturnas).

    Yo que me podría considerar “hijo del Pascal” y que de cobol sólo he ojeado algún tutorial para hacerme una idea, no acabo de entender cual es el problema. En C, pascal, java, etc.. no se usan GOTOs para redactar los programas (aunque los pueda haber). ¿No son estos llamados lenguajes estructurados? ¿No lo dicen también del cobol? (el BASIC de todas las lineas numeradas de 10 en 10 sí que no era estructurado. O el mismo ensamblador)

    El ejemplo que pone la wikipedia de programación “tradicional” frente la JSP es algo que sólo haría un chapucero e inexperto (aunque alguno así ya me he encontrado por profesionales del sector, consecuencia del “MIENTRAS FUNCIONE…”). Creo que no hace falta dibujar monos para escribir bien ¿o es que los hay tan … que sí lo necesitan?.

    De todas formas prometo enterarme bien de que va, hasta que lo tenga claro y pueda pasar página. Lo de los monos, por otro lado, me recuerda a los diagramas que se hacen con las herramientas CASE, que luego generan código automáticamente y que nunca he llegado a utilizar.

    @Fabio: en la asignatura de Algoritmos y Estructuras de datos, ¿no tendrías un libro de un tal Niclaus Birth? Un libro (quizás interesante pero…) infumable en su traducción hispana.

  21. Gravatar joel | 18/03/2009 at 01:52 | Permalink

    Trasteando con el editor JSF que dices acabo de entenderlo. Veo que así se entiende mejor un programa que con diagramas como el que pones al principio de artículo. También entiendo que cuando ya tienes práctica escribes directamente el código que saldría de codificar el diagrama en vez de dibujarlo primero. Pero me falta entender lo de combinar las estructuras de los datos con el esquema. Otro día a ver si estoy algo más fresco…

  22. Gravatar Macluskey | 18/03/2009 at 08:20 | Permalink

    @joel: Tú lo has dicho: eres hijo del Pascal (inventado por Niklaus Wirth, no Birth), pero es que el propio Pascal es hijo también de Dijkstra, de Knuth, y un poco de Warnier y Jackson.

    Sinceramente, no sé muy bien cómo explicarlo: tú llegas a la Universidad y los profesores te empiezan a contar cómo programar con organigramas (como el primero que puedes ver, pero todos eran así). No te lo planteas; lo usas, funciona, y yastá. Un buen día, tienes que hacer un programa más complicado de los normal. Lo haces a tu modo. Eres BUENO programando… Y te cuesta un kohón. No te lo vas a creer, pero, treinta y pico años después, ¡aún me acuerdo del nombre del h de p del programa aquél! Pasan las semanas, y no funciona. Lo has cambiado doce veces, y no funciona… pero no te planteas nada: lo haces como sabes, y no sabes que hay otra forma.

    Entonces vas a un curso de Jackson… y ves la luz. Vuelves a tu oficina, reescribes el programa entero, y te funciona a la primera (o casi). Y te conviertes. Pero esta experiencia tuvieron que tenerla todos los programadores de la época, uno a uno, para consolidar la técnica.

    Por otra parte, hay otra cosa: los lenguajes de Alto Nivel de entonces (Cobol y Fortran, sobre todo) seguían estando muy muy cerca de los de Bajo Nivel (los Assemblers), en los que no hay otro modo de programar que poner GOTOs (BRs, vaya).

    Había que estar allí para entenderlo. Es normal que a los que habéis mamado la estructuración desde el principio no lo entendías del todo… como yo no entiendo el código de Hammurabi.

    Pero, mira, si os sirve para reflexionar y aprender algo de la Historia de la profesión, excelente cosa, ¿no crees?

    Saludos

  23. Gravatar rosalia | 18/03/2009 at 09:45 | Permalink

    Estupendo artículo. Lo necesitarían leer varios profesores. Habría que insistir en otros aspectos ademas de en los GOTOs. Lo de la única entrada y única salida para un bloque lógico, que comentas, pero no ejemplificas En una importante universidad Madrileña me explicaron, hace solo 3 años que en C, era “muy elegante” hacer WHILE TRUE IF condición THEN EXIT Evidentemente no hay quien entienda lo que hace el programa.

    En varias tesis doctorales de informáticos he leido IF condición=TRUE THEN booleano=TRUE ELSE booleano=FALSE ¡Con lo facil que es escribir booleano=condición!!!!!!!

    ¿qué decir de que la cabecera de un subprograma es un “contrato”? en que se solicita “cortesmente” la realización de la tarea. Por el contrario, el propio prof usa globales.

    MAC: tespecto a tu comentario de que no apoyas la polémica entre OO y estructurada. Muchos estamos contigo. Hay una frase de uno de los Gurus (cuyo nombre no recuerdo), que “los mejores programas estructurados son los que mas parecidos son a OO” (salvando las diferencias, claro esta). Legibilidad, mantenibilidad, reusabilidad,… no son inventos de OO como proclaman algunos.

  24. Gravatar Naeros | 18/03/2009 at 12:08 | Permalink

    Yo también he sido “hijo” de la programación estructurada y como dices, si no conoces otra forma no te lo planteas. Es decir, hoy en día empiezas muchas veces aprendiendo a programar con ifs, fors, whiles, etc etc, que es básicamente programación estructurada y muchas veces ni siquiera te dicen que exista el GOTO. Hay veces que incluso te miran mal por utilizar un break… El caso es que en tercero de carrera tuve que programar en ensamblador y ahí te das cuenta del por qué de todo esto. Cuando tienes que programar con GOTOs porque no hay otra, ves los programas de una manera diferente. Y no me cuesta imaginar la situación cuando, acostumbrado a esa forma de programar, te enseñen la estructurada =)

  25. Gravatar lucas | 19/03/2009 at 01:42 | Permalink

    Estupendo artículo, Mac.

    Me encantan tus metáforas que le dan una buena carga humorística a los artículos.

    A propósito, como curiosidad ¿hasta qué año vas a llegar en tu recorrido por la historia de la informática?, ¿hasta la actualidad?, ¿como cuántos capítulos nos quedan por delante?, ¿vas a editar un libro? :)

    Saludos amigo.

  26. Gravatar Macluskey | 19/03/2009 at 01:55 | Permalink

    @Lucas: Sobre hasta cuándo voy a llegar… no sé, pero una vez pasado el 2000 y el Euro (que aquí en Europa fue un trabajo enorme), la informática se ha vuelto bastante más aburrida… hojas de costes por aquí, peticiones por allá, Calidad, Control, montonazos de sistemillas pululando, cada cual de su padre y su madre… a mí me interesa menos, y además, es muy conocida… Así que no llegaré más allá del 2000, creo yo.

    Y sobre lo de escribir un libro…

    …¡Cuando lo hagas tú! Le proponemos a Pedro que escriba otro (tiene temas para dar y tomar) y nos vamos a alguna editorial por ahí, a ver si conseguimos que nos publiquen…

    Es más, animamos a todos los otros autores de Elcedazo para crear la Editorial “El Cedazo Tamizado”, e inundamos el mercado de excelentes obras de divulgación. ¿Qué te parece? Luego los traducimos a setenta idiomas, publicamos en todo el mundo… Bonito, ¿no?

    Un saludo, amigo.

    Y otro para el resto de autores y comentadores.

  27. Gravatar yomismo | 21/03/2009 at 08:56 | Permalink

    Uf, el METHOD/1, no había quien lo entendiera, porque además, toda la documentación estaba en inglés. Como en un próximo capítulo menciones el V-MODEL dejo de leerte!!!

  28. Gravatar Macluskey | 22/03/2009 at 08:51 | Permalink

    @yomismo: Pues sí: Eso mismo. Era un tostón insufrible, ocupaba cuatro baldas de un armario, y además… estaba en perfecto inglés. Inglés de Chicago, para más inri.

    Un rollo.

    Pero siento decirte que tengo pensado, unos capítulos más adelante, hablar de Metodologías, CASE… y seguro que volverá a salir el dichoso Method/1, como parte de Foundation, que era la Metodología de Arthur Andersen… ¡y de las otras muchas metodologías que aparecieron como setas! Pero aún queda, aún queda… puedes dormir tranquilo.

  29. Gravatar Make | 07/04/2009 at 11:17 | Permalink

    Muchas gracias por este fabuloso articulo… los metodos de uno y otro son interesantes y sobre todo la evolucion de ellos… Yo cuando mire COBOL ( digo mirar porque no me dio tiempo a estudiarlo mucho) si nos vendian la moto de los GO TO, pero solo para casos puntuales… y bucles si no recuerdo mal. Pero hace mucho tiempo de ello y ahora si que me arrepiento de no haber mirado eso con mas impetu… pero bueno el boom de los PC´s me cego… ajjaja ya ahora ni una cosa ni otra jajaja…

    Otro articulo fabuloso muchas gracias por compartirlo con nosotros.

  30. Gravatar Floc | 25/06/2009 at 12:53 | Permalink

    Llevo leyendote unos dias y lo encuentro todo interesante (eso de tostón nada!).

    Empecé a estudiar informatica este año y como dices, de base teorica se explica mas bien poco. Eso de los monos lo vi un poco por encima gracias a una profesora que tuve en bachillerato, pero en la carrera nada. Enseñan a programar un poco “apañatelas como puedas a prueba y error”: te explican mas o menos las instrucciones basicas de un lenguaje (en mi caso C++) y ejemplos y te dan una lista de ejercicios que se corrijen automaticamente via web. Luego llegas al primer programa minimamente largo, y no sabes por donde cojerlo.

    Sigue con esos ladrillos, toda esa informacion (y batallitas!) no se puede perder en el olvido!

  31. Gravatar Emmanuel | 05/08/2009 at 10:08 | Permalink

    Hola! encontre la serie por el ultimo articulo publicado pero espero leerla toda… Es bueno conocer como eran las cosas antes :D . En estos momentos estoy de JAVERO. Pero antes de la universidad llegue a programar en Assembler del poderosisimo Z80 de zilog. Un microprocesador de 8 bits a fabulosisimos 4MHZ. Lo programamos en un sistema minimo con algunos KB de RAM y algunos menos de ROM, ¡que nosotros mismos soldamos y diseñamos!. Cuando pase a programacion C (estructurado, para que nos enseñaran C++ faltaban un par de años) todo fue felicidad y hermosura :P . Y eso que solo tengo 24 años.

  32. Gravatar Jorge | 06/08/2009 at 10:16 | Permalink

    @Macluskey, por si te interesa en la Facultad de Informática sigue impartiendose tanto diseño estructurado como orientado a objetos.

    Hoy en día es poco útil el diseño estructurado porque por un lado la mayor parte de las aplicaciones que se realizan son orientadas a objetos y porque los lenguajes de programación son mucho más descriptivos ahora que entonces por lo que en la mayoría de los casos no necesitas un diagrama de estructura para desenmarañar lo que hace el código. Es mucho más fácil acudir al propio código y sus comentarios, si acaso acompañados de algún documento de descripción en lenguaje coloquial.

  33. Gravatar Silvina | 01/12/2009 at 01:39 | Permalink

    Para Jorge, que comenta que ya no es util el diseño estructurado y que es preciso solo el comentario y mirar código. Lamento contradecirte..en las grandes empresas, donde se manejan cantidades enormes de información sí que se sigue manejando diseño estructurado..el batch sigue vivo, el mainframe se sigue necesitando (y por ende el cobol, natural..si, aunque parezca mentira) . Así es que quizá por un sistema tenemos a mas de 20 o 30 personas, que se van renovando constantemente, que tienen que seguir manteniendo esos sistemas y se hacen modificaciones..o hay problemas muy puntuales. Justamente ante estos problemas, aunque no lo parezca..hacer un diagrama es muchas veces el mejor método y puede ahorrarte muchísimo tiempo en pruebas-error (doy fé! je) Por lo tanto, como dices, no queda otra que seguir enseñando programación estructurada y los diagramas, tanto como el paradigma de objetos.

  34. Gravatar Rafa | 13/10/2010 at 04:35 | Permalink

    Excelente regreso a la historia, estaba buscando sobre el método Warnier y me quedé leyendo asombrado de lo que ha antecedido a lo que ahora me da de comer… Muchas gracias por la dedicación y la explicación. Muy buen trabajo.

  35. Gravatar Sara Palacios | 14/11/2010 at 05:23 | Permalink

    Saludos, Macluskey, y comparto en todo tus conceptos, tu historia y tu nostalgia.

    Una vieja informàtica.

  36. Gravatar Venger | 13/01/2012 at 01:15 | Permalink

    ERRATA

    Donde dice “aquéllos incipientes metodólogos” debe poner “aquEllos incipientes metodólogos”

    Saludos y continúo leyendo…

  37. Gravatar Guillermo | 17/11/2013 at 09:47 | Permalink

    Hola Macluskey, excelente publicación, gracias por compartir tus conocimientos y anécdotas, desde México un abrazo.

{ 1 } Trackback

  1. Gravatar meneame.net | 16/03/2009 at 07:02 | Permalink

    Historia de un Viejo Informático. La Programación Estructurada…

    Nueva entrega de la serie Historia de un Viejo Informatico. En su linea: Hoy le toca a la programacion estructurada….

Escribe un comentario

Tu dirección de correo no es mostrada. Los campos requeridos están marcados *

Al escribir un comentario aquí nos otorgas el permiso irrevocable de reproducir tus palabras y tu nombre/sitio web como atribución.