Existen en el mundo muchísimos textos no científicos, pero sería difícil encontrar uno menos científico que el Talmud. Aun así, recomiendo muy en serio su lectura. Permítanme explicarme.

Estudiar el Talmud es estudiar lectura. El Talmud es el desafío definitivo a los lectores atentos. Tanto si se lo hace como es debido, estudiando durante toda una década, como si uno se limitase a escarbar la superficie durante uno o dos años, es imposible que se complete su estudio sin haber adquirido nuevos conocimientos sobre cómo exprimir, destilar, sonsacar, arrancar, arrebatar, filtrar o cualquier otra manera de extraer significado a un texto difícil. En la actualidad, pocos científicos saben leer en serio. Están acostumbrados a hojear rápidamente artículos para extraer los datos y seguir adelante, sin molestarse en recrearse en el texto en busca de matices. Lo más probable es que no exista ningún matiz. Por lo general, la lectura es irrelevante para la ciencia. Pero existen excepciones, y pueden ser importantes.

Tienen especial importancia en la ciencia informática, porque se trata de un campo de la ciencia que no está muy seguro de sí mismo. Sospecha que es importante y que anda camino de conseguir algo grande, pero aún no tiene muy clara su importancia. La ciencia informática es la ciencia del soporte lógico o software, y el software es la cosa más extraña del mundo. Aún no lo entendemos muy bien, como tampoco tenemos claros los límites y métodos de esta ciencia.

La lectura atenta es importante en la ciencia informática porque los autores de algunos de los trabajos más trascendentales seguían dándoles vueltas en la cabeza a muchas cuestiones fundamentales del tema cuando los escribieron. En una lectura superficial. los textos dicen una cosa; entre líneas, abordan cuestiones básicas que aún están por resolver.

Entre las más básicas de dichas cuestiones está la relación entre el software y las matemáticas, Desde la invención, en 1957, del primer lenguaje de programación de amplio uso, muchos científicos informáticos han sospechado que el software se parece mucho a las matemáticas, o incluso que es matemáticas. Algunos especialistas creen que escribir un programa y elaborar una demostración matemática son actividades equivalentes e intercambiables, dos maneras igual de entretenidas de pasar una tarde de domingo. También están convencidos de que los instrumentos empleados para escribir software —principalmente, los lenguajes de programación— deberían definirse matemáticamente, mediante una serie de ecuaciones.

Otros insisten en que tales argumentos son erróneos (y de hecho, lo son). Alegan que el software no tiene nada que ver con las matemáticas. Un trabajo matemático es una forma de comunicación entre personas. Una pieza de software es un plan de funcionamiento para un tipo especial de máquina, una máquina «virtual» o «personificada». Cuando se hace funcionar el programa en un ordenador, el ordenador se convierte temporalmente en la maquina para la que el programa sirve de plan. Diseñar un programa no se parece a elaborar una demostración matemática; es mucho más parecido a diseñar un automóvil. Y además, esta escuela sostiene que los instrumentos que empleamos para escribir software deberían definirse en español (o inglés) claro y simple, no matemáticamente, en forma de una serie de ecuaciones.

Este debate afecta a la médula misma del software y la ciencia informática. Pero, además, se trata de una nueva batalla en una guerra que se viene librando a lo largo de toda la historia intelectual moderna: la guerra entre la visión matemática del mundo y la física. Algunas de sus batallas se han librado en el campo de la ingeniería civil (¿construimos puentes basándonos en modelos matemáticos, o nos basamos en la experiencia, la estética y la intuición?); otras, en el campo mismo de la física (¿son las matemáticas la luz primaria que nos guía, o lo es la pura intuición física?); y otras más, en la economía y en las ciencias sociales; en el campo de la informática son el pan nuestro de cada día.

Consideremos ahora el valor de la lectura atenta. En los casos a los que me refiero, ésta no nos premia con munición decisiva para destruir a la oposición, sino, simplemente, con indicios sutiles pero que valen la pena.

El Algol 60 es el lenguaje de programación más importante que jamás se ha inventado, y podría decirse que el informe revisado sobre el Algol 60, publicado en 1963, es, por varias razones, el texto más importante de la ciencia informática. El propio Algol 60 tiene una importancia decisiva por sí mismo, pero, además, el informe está considerado por muchos expertos como una obra maestra de escritura lúcida. Utiliza inglés llano y simple para explicar lo que significa el Algol 60 y qué es lo que hace. Quien quiera explicar un lenguaje de programación en inglés, y no mediante ecuaciones matemáticas, lo va a tener difícil para hacerlo mejor que este informe.

Y precisamente por esto, la escuela «matemática» insiste en que el informe sobre el Algol 60 es ambiguo e incompleto en algunos aspectos. «Ahí lo tienen», dicen. En este texto clásico, el idioma inglés echó el resto y se quedó corto. El camino matemático es el buen camino. Quod erat demostrandum.

Un paladín del enfoque matemático lo expresó de este modo: «Tanto los usuarios como los ejecutores de lenguajes de programación necesitan una descripción que sea comprensible, sin ambigüedades y completa... Casi todos los lenguajes están definidos en inglés. Aunque estas descripciones son, con frecuencia, obras maestras de aparente claridad, resultan muchas veces inconsistentes e incompletas». (1) El autor pasa a mencionar el famoso informe sobre el Algol 60 (2) y cita un conocido artículo cuyo mero título es suficientemente incriminatorio como para dar el caso por cerrado: «Los puntos problemáticos que aún quedan en el Algol 60». (3)

Una cosa que se aprende estudiando el Talmud es a consultar siempre las fuentes. Cuando examinamos el artículo de los «puntos problemáticos», encontramos reflexiones tan interesantes como ésta: «En realidad, la siguiente lista [de puntos problemáticos] es más notable por su brevedad que por su longitud.» Y termina con la siguiente conclusión: «El autor ha procurado señalar todos los fallos [del informe sobre el Algol 60] y desea que nadie examine jamás sus propios escritos de un modo tan meticuloso.»

Cuanto más lo pensamos, más claro vemos que este análisis de los «puntos problemáticos» es un testimonio de la soberbia claridad, no de la insuficiencia, del informe sobre el Algol 60 y sus definiciones en idioma inglés. El informe presentaba un instrumento complejo, sin precedentes y totalmente original. Ya es admirable que lo consiguiera con tan pocos fallos como demuestra el artículo sobre los «puntos problemáticos» (tal como reconoce el propio autor). Siguiendo esta línea de reflexiones, volvemos al informe y nos fijamos en el epígrafe, que concluye con las palabras Wovon man nicht reden kann, darüber muss man schweigen. Una de las máximas filosóficas más famosas de este siglo, con la que Ludwig Wittgenstein cierra su Tractatus: «En cuestiones de las que no se puede hablar, hay que permanecer callado.» Ahora bien, esto podría haber querido decir «Somos conscientes de que hay vacíos en el texto que sigue, pero es que el idioma inglés nos ha fallado. No estuvo a la altura de la tarea de llenarlos.» Semejante actitud guardaría una vaga relación con la auténtica contención de Wittgenstein, que se refería a los límites de expresividad de cualquier idioma. Pero una interpretación mucho más probable sería: «Somos conscientes de que hay vacíos en este texto, pero como no teníamos nada inteligente que decir, hemos preferido callar.»

Según esta lectura, los autores del informe no se engañaban pensando que su trabajo era perfecto. No produjeron una «obra maestra de aparente claridad» (el subrayado es mío) que luego se revelara como una chapuza de tercera clase en cuanto los clientes echaran una mirada más atenta. Según esta lectura, los puntos débiles del informe tal como son no se deben achacar al idioma inglés, sino a los autores.

Después de este sencillo intento de lectura cuidadosa, ¿está usted seguro de que el idioma inglés ha fallado la prueba y de que la única opción posible es la matemática?

Mi otro ejemplo también tiene que ver con la naturaleza del software y la guerra de las matemáticas. Pero sirve para presentar otro tema. La ciencia informática es un campo lleno de chiflados ávidos de novedades. En este aspecto, no hace más que reflejar (una vez más) el carácter de la vida intelectual moderna. No es mi intención condenar la ciencia informática ni apremiarla a que cambie de estilo. Tan sólo pretendo afrontar los hechos. Constituimos un mundillo terriblemente irreflexivo. Somos como el ganado, igualmente propensos a la estampida, pero los humanos tenemos la ventaja de ser capaces de reflexionar sobre las cosas, con pensamientos del tipo de «Bueno, allá va otra estampida. Yo diría que se parece bastante a la última». Es de suponer que, si nos esforzamos un poco, ganemos así un poco de perspectiva.

En 1971, Niklaus Wirth publicó la primera descripción de su lenguaje Pascal, que en unos pocos años se iba a convertir en uno de los, factores dominantes del panorama informático. En la actualidad, el Pascal ya no se utiliza tanto como en otros tiempos para la creación de software, pero sigue siendo uno de los lenguajes más enseñados y un hito histórico de primera clase. Y Wirth es un auténtico héroe en nuestro campo.

En 1975, Wirth publicó una valoración del notable éxito del Proyecto Pascal (4). Para los lectores atentos, el artículo resulta intrigante, no tanto por lo que dice acerca de la ciencia y la ingeniería como por lo que dice (entre líneas) sobre el modo de trabajar en la ciencia y la ingeniería. Visto superficialmente, el artículo es una sobria valoración del proyecto, pero entre líneas descubrimos las actas de un extraño y espectacular proceso, en el que Wirth se defiende de los que le acusan de una serie de delitos de nuevo cuño.

Los programas son estructuras complicadas en los casos extremos, probablemente las más complicadas que la humanidad conoce, y resulta muy difícil conseguir que funcionen a la perfección. Para convencer a la gente de que un programa funciona bien, es preciso someter el producto acabado a una serie de complicadas y laboriosas pruebas. A principios de los años 70, surgió una nueva escuela de pensamiento que sostenía que, puesto que los programas son matemáticos, debería ser posible demostrar matemáticamente que un programa funciona. No haría ninguna falta poner en funcionamiento el programa; bastaría con examinarlo cuidadosamente y elaborar una prueba. La prueba no dejaría lugar a dudas: el programa saldría de la caja con garantía de perfección. A este enfoque se lo llamó «verificación de programas».

Parece una gran idea, pero en la práctica es irrealizable. Es como si hubiéramos diseñado un nuevo automóvil y pretendiéramos demostrar, sólo con los planos del ingeniero, que todo es correcto y funcionará a la perfección. Podríamos vender el modelo a la ansiosa clientela tal como sale de la cadena de montaje, sin molestarnos en probar un prototipo ni una sola vez. Estaría muy bien si lo consiguiéramos, pero es imposible que lo consigamos, y, además, el software no funciona de este modo.

Cuando Wirth diseñó el Pascal, la verificación de programas estaba aún calentando motores. Cuando volvió la mirada varios años más tarde, era ya una tendencia arrolladora. En su mayor parte, las quejas retrospectivas de Wirth acerca de su obra no se refieren a experiencias reales de los usuarios del Pascal, sino que parecen dirigirse principalmente a la verificación de programas. Casi nos recuerda a un marxista recién converso, levantándose para confesar sus pecados y arrepentirse de su vida anterior. Los detalles son técnicos, pero voy a mencionar brevemente algunos de ellos. El Pascal simplificó y añadió dinamismo a las reglas de precedencia del Algol, pero esto resultó ser un error... no porque los programadores se quejaran, sino a causa de la «creciente importancia» de la «verificación de programas». El Pascal incluía una cosa que se llamaba «informe goto», que no dio buenos resultados... no porque a los programadores no les gustara, sino a causa de problemas relacionados con «la verificabilidad de programas». A los programadores les gustaba mucho el sistema de tipos flexibles del Pascal, pero lo verdaderamente importante de esta innovación no tenía nada que ver con su entusiasmo, sino con «invariantes necesarias para la verificación de programas».

Antes dije que Wirth es un héroe. Esto no sólo se debe a la importancia de su trabajo en general, sino precisamente a este artículo. Un aspecto del Pascal que enfurecía especialmente a los verificadores de programas era la «unión de tipo libre». Una y otra vez, exigieron que se la sacara del lenguaje para fusilarla. Wirth reconoce que la unión de tipo libre plantea graves peligros, pero se niega a rendirse a la multitud enardecida. «Parece que existen ocasiones —dice circunspectamente— en las que la alternativa a la insidiosa unión de tipo libre es insuficientemente flexible.» De manera que la unión de tipo libre se queda donde está. Los camaradas de Wirth se regocijan y la turba hace rechinar los dientes, pero al acercarse el amanecer la población ve con alivio cómo se va dispersando.

Como colectivo, deberíamos conocernos mejor de lo que nos conocemos. La lectura atenta de este artículo nos enseña una cosa muy importante acerca de los vaivenes de la moda en la ciencia informática. El Pascal sigue por ahí, pero la verificación de programas está (más o menos) muerta. Al menos, en la forma que se proponía en los 70.

Unas palabras más acerca del Talmud. Está compuesto como un texto básico con una enorme serie de comentarios. Se supone que cada comentario no sólo se refiere al texto básico (o, al menos, tiene conciencia de él), sino también a todos los comentarios que le preceden. El propio texto básico es una estructura con dos niveles: una concisa «base básica» llamada Mishnah y un largo comentario no muy organizado, llamado Gemara. Estudiar el Talmud es estudiar lectura atenta al nivel más alto posible de precisión analítica y rigor. A todo futuro científico le vendrían muy bien uno o dos cursos de estudio del Talmud.

Posdata sociológica. Un observador inocente podría decir «¡Maravilloso! El multiculturalismo se impone en nuestras universidades y colegios públicos». Exponer a un amplio sector de estudiantes a la belleza y profundidad de la cultura judía debe ser el no va más del multiculturalismo, ¿no?

No se entusiasmen tanto. Si el multiculturalismo fuera un movimiento intelectual serio y no la payasada tendenciosa que en realidad es, la cultura judía podría ser uno de sus grandes descubrimientos. Pero tal como es, el multiculturalismo no es más que la última encarnación del viejo anti-intelectualismo del tipo «Quita de en medio, Beethoven», que siempre ha formado parte de la vida estadounidense. La única diferencia entre este tipo de anti-intelectualismo y los anteriores es que sus más fervientes partidarios son los rectores de universidad. La historia está llena de sorpresas.

***********************

DAVID GELERNTER, profesor agregado de informática en la Universidad de Yale, es una de las principales figuras de la tercera generación de especialistas en inteligencia artificial. Hace trece años, cuando todavía era estudiante posgraduado, Gelernter diseñó un importante lenguaje de programación, llamado Linda, que permitió conectar varios ordenadores para que trabajaran en un mismo problema. Desde entonces se ha revelado como uno de los pensadores más influyentes en el campo de la informática paralela o distribuida. Es autor de Mirror Worlds, The Muse in the Machine y 1939: The Lost World of the Fair.

***********************

Notas

(1) M. J. C. Gordon, The Denotational Description of Programming Languages, Nueva York, Springer-Verlag, 1979.

(2) P. Nauer, ed., «Report on the Algorithmic Language Algol 60», Communications of the ACM, vol. 6, 1, 1963, págs. 117.

(3) D. E. Knuth, «The Remaining Trouble Spots in Algol 60», Communications of the ACM, vol. 10, 10, 1967, págs. 611-617.

(4) N. Wirth, «An Assessment of the Programming Language Pascal», IEEE Transactions on Software Engineering, 1975, págs. 192-198.