Complejidad

Allá por el año 1990 aprendí y utilicé un curioso lenguaje de programación para los ordenadores Tandem, llamado SCREENCOBOL (o SCREEN-COBOL), que solo servía para hacer programas que pintaban pantallas y recogían datos, en terminales “tontos” (pobres terminales). Era un lenguaje sencillo, fácil de aprender, y hacía muy bien aquello para lo que había sido diseñado.

Buscando en Google.com páginas que hiciesen referencia a ese lenguaje, encontré apenas 1.500. De esas sólo 15 están en español. Eso es casi como acabar en el más absoluto olvido.

¿Y para qué vale un lenguaje que solo pinta pantallas?, os preguntaréis.

Pues muy fácil: la arquitectura de aquellas desaparecidas máquinas Tandem obligaba (no recomendaba) a aislar la presentación de la lógica de negocio. Ésta última estaba en programas en COBOL de toda la vida que ¡no podían pintar pantallas!. Los programas en COBOL y los escritos en SCREENCOBOL se comunicaban mediante una cola de mensajes.

Además, nunca sabías que proceso iba a responder a cada petición de la pantalla, pues existía un conjunto de réplicas que podían hacerlo, en función de la carga de trabajo. Estos procesos se declaraban con un nombre virtual, en ficheros configuración. Tanto las pantallas como la lógica de negocio debían ser “libres de contexto” (perdon por la traducción).

¿Deja-vu total no? Año 1990, repito.

Ahora está de moda todo esto. Sobre todo la discusión sobre los Lenguajes Específicos de Dominio, del inglés Domain-specific Languages, como SCREENCOBOL, es decir, que hacen solo ciertas cosas pero más eficientemente que los lenguajes de propósito general.

Esto permite simplificar los sistemas hasta su complejidad esencial, es decir, la intrínseca del problema que se intenta resolver, eliminando la complejidad añadida por las herramientas, que no aporta nada.

Me propongo hacer una lista de esos lenguajes. A ver a cuantos de ellos les pasa lo que a SCREENCOBOL en los próximos 16 años.

Creo que casi todos los que trabajamos en el desarrollo de software estamos de acuerdo en que es imprescindible conocer más de un lenguaje de programación. Bastantes programadores o aspirantes a serlo me han hecho alguna vez la pregunta: ¿y que lenguaje aprendo ahora?.

He leido un interesante artículo sobre los 10 lenguajes que cualquier programador debería aprender. Yo me conformaría con cuatro o cinco de ellos.

Además considero que esa lista no está bien ordenada (ver las ofertas de empleo para cada lenguaje), que alguno de los propuestos no es un lenguaje y que contiene algún lenguaje “glamuroso” pero poco extendido aún.

Y añadiría uno muy importante: COBOL. ¿Quien se encargará de mantener los miles de millones de líneas (¿billones?) de código que aún conforman las aplicaciones de la mayor parte de las empresas grandes del mundo?

¿Dije que no creía ser ni siquiera el segundo en formular la Ley de Tesler? ¡Que consuelo comprobar que la red está llena de descubridores de esa Ley! ¿Cuantos más habrá que no tienen blogbitácora o página web alguna? ¿Decenas, quizá cientos? Eso dice Sean Mc Grath…

Pues he leido un artículo, algo antiguo pero interesante, sobre la Ley de Tesler: La Primera Ley de Matt (pobre Matt) sobre la Complejidad del Software. Interesante.

Lo cual llevó a Carlos E. Pérez a buscar un paralelismo entre las leyes de la Termodinámica y la complejidad del software (¿ya mencioné que yo una vez pensé en intentar algo parecido?). Más interesante. Y atrevido.

Y en efecto, como menciona David G. Miller en el blog de Matt, el IETF ha publicado una RFC, la 1925, sobre Las Doce Verdades sobre las Redes (The Twelve Networking Truths). En la 6ª se dice:

Es mas facil cambiar un problema de sitio (por ejemplo trasladándolo a otra parte de la arquitectura de red) que resolverlo.

Im-presionante.

Es duro averiguar que alguien antes que tú postuló una ley que creías haber descubierto el primero – en el fondo sí la descubrí, como Colon descubrió América, aunque ya lo habían hecho antes los americanos.

La complejidad, como la energía, no se crea ni se destruye, simplemente se traslada

Larry G. Tesler

Pero ni siquiera he sido el primero (quizá ni el segundo) en enfrentar esa frustrante verdad: otro antes que yo creyó haber descubierto la misma ley y también se equivocó. Al menos eso le ayudó a formular una ley propia.

La mayor parte de la gente, antes o después, descubrirán que lo que creen que es una nueva ley universal, ha sido descubierta por otra persona antes que ellos

Sean Mc Grath

En realidad, la ley de Tesler dice que para cualquier proceso existe un nivel básico de complejidad, inherente al propio proceso. Una vez alcanzado ese nivel mínimo no se puede simplificar mas, solo se puede mover la complejidad de un lado a otro.

Toda mi vida – profesional – he luchado inútilmente contra esta ley. He estado embarcado en un vano afán de simplificar las cosas que conocía, sin conseguir grandes resultados, por cierto. Lo cual me llevó al principio de Mr. Tesler.

De todos modos, a pesar de la imposibilidad de vencer la primera premisa – tal y como ocurre también con la Primera Ley de la Termodinámica – la segunda parte tiene su lado positivo.

Creo que el truco está en intentar trasladar la complejidad a donde menos moleste, como quien barre metiendo la suciedad debajo de la alfombra.