Entrevista con Edsger W. Dijkstra 2001/08/02

Charles Babbage Institute 2001
Pdf Original: https://conservancy.umn.edu/handle/11299/107247 
An Interview with Edsger W. Dijkstra OH 330 Conducted by Philip L. Frana on August 2, 2001 Austin, TX Charles Babbage Institute Center for the History of Information Processing
University of Minnesota, Minneapolis Copyright 2001, Charles Babbage Institute
Conducted by Philip L. Frana

RESUMEN:

En esta entrevista, Edsger Dijkstra relata su educación y formación temprana como físico teórico y como "programador". Dijkstra describe su trabajo desarrollando software para
Centro de Matemáticas en Amsterdam, la finalización de su Tesis Doctoral y sus actividades en sus primeras conferencias sobre procesamiento de información. Dijkstra también habla sobre el desarrollo de ALGOL 60 y los orígenes de la informática en Europa y América.

ENTREVISTA:

Dijkstra: Todo comenzó en 1951, cuando mi padre me permitió ir a un curso de programación en Cambridge, Inglaterra. Fue una experiencia aterradora: fue la primera vez que Salí de Holanda, la primera vez que tuve que entender a personas que hablaban inglés e inmediatamente estaba solo, tratando de seguir un curso sobre un tema totalmente nuevo. Pero me gustó mucho. Los Países Bajos eran un país tan pequeño que Aad van Wijngaarden, quien fue director del Departamento de Computación del Centro Matemático en Amsterdam lo sabía y me ofreció un trabajo que solo pude aceptar en marzo de 1952. Y a tiempo parcial, me convertí en programador del Centro de Matemáticas. Todavía no tenían computadoras; estaban tratando de construirlas. Programé hasta 1962 y los primeros ocho años de programador desarrollé el software básico para una serie de máquinas sucesivas que se construyeron en el Centro de Matemáticas. Al principio era un programador muy conservador. La forma en que los programas fueron escritos, la forma del código de instrucciones en papel y la organización de la biblioteca, entrada, salida, etc., estaba muy modelada a partir de lo que había visto en el 51 en Cambridge, pero todo funcionó satisfactoriamente.

Frana: Entiendo que cuando te casaste, no podías ingresar el término "Programador" en su registro de matrimonio?

 
Dijkstra: Eso es verdad. Si.

 
Frana: ¿Cuándo podría ser reconocido como un título?

Dijkstra: Creo que a principios de los años sesenta. Quiero decir que es una historia bien conocida y verdadera. Se suponía que debía estudiar física teórica, lo hice y esa fue la razón para ir a Cambridge, porque estaba siendo preparado para convertirme en un excelente físico teórico. La idea era que si además de todas las herramientas habituales también pudiera usar computadoras, tal vez podría convertirse en un mejor físico teórico, ser más que el promedio. Sin embargo, en 55 después de las tres años de programación, cuando aún era estudiante, concluí que el desafío intelectual de la programación era mayor que el desafío intelectual de la física teórica, y como resultado elegí la programación, la razón es que la programación era implacable: Si algo sale mal, quiero decir que un cero es un cero y un uno es uno. Yo nunca usé el software de otra persona. Usé máquinas en las que yo mismo había estado involucrado en el diseño, había documentado el código de instrucción y había escrito mi propio software básico y todos los programas y si algo salía mal, lo habría hecho yo. Y fue esta implacabilidad la que me desafió, porque también comencé a darme cuenta de que aunque en principio es muy simple. Un cero es un cero y un uno es uno, y debería tenerse un control intelectual completo de lo que estás haciendo, y que de alguna manera extraña y no entendida, los programas pueden volverse muy complicados y difíciles. Entonces fue en el 55 cuando decidí no convertirme en físico, sino en programador. es una dificil decision porque, como dije, fui preparado para convertirme en un científico de primera clase, y en ese momento la programación no parecía hacer ciencia, era solo una mezcla de ser ingenioso y siendo preciso. Recuerdo que envidiaba a mis amigos del hardware, porque si les preguntabas en qué consistía su competencia profesional, podían señalar que sabían todo sobre triodos, pentodos, válvulas y otros equipos electrónicos. ¡Y no había nada que yo pudiera señalar! En realidad, bueno, hice varios programas y tuve muy buena letra ...

Frana: Entonces, ¿cómo hiciste para que la ciencia de la computación fuera respetable?

 

Dijkstra: Bueno, eso sucedió después. Hablé con van Wijngaarden en el 55 y le expliqué
el dilema de que tenía que despedirme de la ciencia si me convertía en programador. Y él dijo, bueno, antes que nada señaló que las computadoras estaban aquí para quedarse, que no era una moda pasajera. Y luego dijo que estaba de acuerdo en que no existía un componente científico claro en programación informática, pero que bien podría ser yo una de las personas llamadas para convertirla en una ciencia.Y en ese momento, yo era el tipo de persona a quien le podías decir esas cosas e incluso hiciera caso. Como dije, fui entrenado para ser científico. Cuando llegué en 1952, estaban trabajando en ARRA [= Automatische Relais Rekenmachine Amsterdam], pero no pudieron hacerla fiable, y se construyó una versión actualizada utilizando diodos de selenio en lugar de relés. Y luego, el Centro de Matemáticas construyó una máquina para la Industria de Aviones Fokker, porque antes de eso habíamos hecho muchos cálculos en el ARRA para el F27. Entonces, la FERTA [= Fokker Electronische Rekenmachine Te Amsterdam], una versión actualizada de ARRA, fue construida e instalada en Schiphol. La instalación la hice junto con el joven Gerard Blaauw que luego se convirtió en uno de los diseñadores de IBM 360, con Amdahl y Brooks. Una historia divertida sobre el F27, que Fairchild más tarde construyó bajo el nombre de "Amistad". En mi primera visita a Australia, volé un gran 747 desde Amsterdam a Los Ángeles, luego cambié de avión y me subí a otro 747, desde América I volé a Sydney o Melbourne, no recuerdo cuál de los dos. Y luego fue la parte final del viaje en un F27 a Canberra, porque los australianos me habían invitado a Canberra. Y llegamos y salí del avión y conocí a mi anfitrión, a quien nunca había conocido antes, pero habíamos mantenido correspondencia extensa. Y se disculpó mucho porque este viajero a través del mundo tuviera que hacer la última etapa del viaje en un turbohélice bimotor tan inestable. Y me dio la oportunidad de hacer una jugada que nunca volví a tener en la vida. Honestamente pude haberle dicho: "Dr. Stanton, me sentí bastante seguro: yo mismo había calculado las frecuencias de resonancia de las alas ”[risas]

Frana: ¿Era este el mismo viaje que seguiste por el mundo? ¿Te detuviste en la India?

Dijkstra: No, no, este fue un viaje diferente, ese fue el viaje a Japón. De acuerdo, en '54 al completar ARRA, en '55 / '56 me convierto en programador. Luego, en 1956, sucedieron todo tipo de cosas. Obtuve mi título de físico teórico. Tan pronto como decidí convertirme en programador, terminé mis estudios lo más rápido posible, ya que ya no me sentía bienvenido en la Universidad: los físicos me considerarían un desertor, y los matemáticos, eran despectivos y también un tanto despectivos con respecto a la informática. de todos modos. Todo era finito, ¿no? En la cultura matemática de aquellos días en los Países Bajos, tenía que lidiar con el infinito para que tu tema fuera científicamente respetable. En 1956 hice dos cosas importantes, obtuve mi título y tuvimos la inauguración festiva del ARMAC [= Automatische Rekenmachine Mathematische Centrum]. Teníamos que tener una demostración. Ahora, el ARRA, unos años antes, había sido tan poco confiable, que la única demostración segura que nos atrevimos a dar era la generación de números aleatorios, pero para el ARMAC más fiable y podría intentar algo más ambicioso. El problema, por supuesto, es que para una demostración para personas que no son informáticas, debe tener una declaración del problema que los no matemáticos puedan entender, incluso ellos tienen que poder entender la respuesta. Así que diseñé un programa que encontraría la ruta más corta entre dos ciudades en los Países Bajos, utilizando una hoja de ruta algo reducida de los Países Bajos, en la que había seleccionado 64 ciudades (de modo que en la codificación, 6 bits serían suficientes para identificar una ciudad)

Frana: ¿Algo similar al problema de los siete puentes? 

Dijkstra: No, es solo la ruta más corta. ¿Cuál es la forma más corta de viajar de Rotterdam a Groninga, en general: de una ciudad a otra? Es el algoritmo para el camino más corto, que diseñé en unos veinte minutos. Una mañana estaba de compras en Amsterdam con mi joven prometida, y cansado, nos sentamos en la terraza del café a tomar una taza de café y estaba pensando si podría hacer esto, y luego diseñé el algoritmo para el camino más corto. Como dije, fue un invento de veinte minutos. De hecho, se publicó en el 59, tres años tarde. La publicación aún es legible, de hecho, es bastante agradable. Una de las razones por las que es tan agradable fue que lo diseñé sin lápiz ni papel. Más tarde supe que una de las ventajas de diseñar sin lápiz y papel es que casi estás obligado a evitar todas las complejidades evitables. Finalmente, ese algoritmo se convirtió, para mi gran asombro, en uno de los pilares de mi fama. Lo encontré a principios de los años 60 en un libro alemán sobre ciencias de la gestión: "Das Dijkstra’sche Verfahren". De repente, había un método que llevaba mi nombre. 

Frana: es de valor económico. 

Dijkstra: si. Y volvió a saltar recientemente porque se usa ampliamente en todos los planificadores de viajes. Si, en estos días, desea ir de aquí para allá y tiene un automóvil con un GPS y una pantalla, esto puede mostrarle el camino más corto desde su hotel hasta Robbie Creek Cove. ¿Si? 

Frana: Sí, generé un mapa, sí, en línea.

Dijkstra: ¿Lo usaste?

Frana: Sí, lo usé.
 
Dijkstra: Entonces usaste mi algoritmo esta mañana.
 
Frana: ¿Cuándo se publicó originalmente?

Dijkstra: Fue publicado originalmente en 1959 en un artículo alemán en Numerische Mathematik. F.L. Bauer había fundado esa revista y estaba solicitando artículos. Ahora, en ese momento, algo así como un algoritmo para el camino más corto, que apenas se consideraba matemático: había un número finito de formas de ir de A a B y obviamente hay uno más corto, entonces, ¿por qué tanto alboroto? Es por eso que no se publicó, pero cuando Bauer preguntó si podíamos contribuir con algo, le dije que sí, porque mientras tanto también había diseñado el árbol de camino mínimo. Lo había hecho para mis amigos de hardware. Ya sabes, en el panel grande tienes que conectar una gran cantidad de puntos con el mismo cable de cobre porque tienen que tener el mismo voltaje. ¿Cómo minimizar la cantidad de alambre de cobre que conecta estos puntos? Así que escribí un artículo "Una nota sobre dos problemas en relación con los grafos" o algo así. Pero ahora, cuando fui a mi oftalmólogo - y que yo sepa, él ni siquiera sabía que yo era un científico de la computación - dijo: "¿Has diseñado el algoritmo para GPS?" Resultó que había visto El Scientific American 2 del pasado noviembre.
 
Hiciste una pregunta ...

Frana: ¿Qué hiciste con tu fama entonces?

Dijkstra: ¿Qué hice con mi fama? Me impresionó!

Bueno, eso fue '56. '57 fue el año de mi matrimonio, que tuve que hacer como físico teórico profesional, historia loca. Además de eso, me enfrenté a la interrupción en tiempo real y casi entré en pánico. Porque, como ven, durante esos primeros cinco años siempre había estado programando para máquinas no existentes, que aún no existían. Discutiría, diseñaríamos el código de instrucciones, verificaría si este era un código de instrucciones con el que podría convivir, y mi amigo de hardware verificaría que este fuera un código de instrucciones que pudieran construir. Y luego escribiría la especificación formal de la máquina, y los tres la firmaríamos con nuestra sangre, por así decirlo. Y luego nuestros caminos se separaron y empezarían, sabían qué construir y yo sabía lo que podía construir. Pero toda la programación que hice fue en papel. Así que estaba bastante acostumbrado al hecho de desarrollar programas sin probarlos.


Frana: ¿No había forma de probarlos?

Dijkstra: No había una manera de probarlos, así que debes convencerte de su corrección razonando sobre ellos. Ahora, por supuesto, podría haber errores de escritura, nunca reclamé infalibilidad. Tienes que dejar eso a expertos en ese campo como el Papa. Pero un simple error de escritura no importó mientras la máquina aún no estuviera allí, y tan pronto como aparecieran los errores en la máquina, serían fáciles de corregir. Sin embargo, en el '57, me enfrenté con la idea de la interrupción en tiempo real y eso creó una visión de un programa con errores no reproducibles, porque una interrupción en tiempo real ocurre en un momento impredecible. Mis amigos de hardware me halagaron de mi resistencia. Dijeron: "Sí, sí, vemos tu problema, pero seguramente debes estar preparado para eso ..." Aprendí a enfrentarlo. Escribí un controlador de interrupciones en tiempo real que era perfecto y que se convirtió en el tema de mi tesis de doctorado. . Más tarde aprendería que por aquí, esto casi se consideraría una actividad no estadounidense.

Frana: ¿Por qué es eso?

Dijkstra: Bueno, la reacción estadounidense fue muy, muy diferente. Cuando IBM tuvo que desarrollar el software para el 360, construyeron una o dos máquinas especialmente equipadas con un monitor. Esa es una pieza adicional de maquinaria que registraría exactamente cuándo tuvieron lugar las interrupciones y de dónde a dónde. Y si algo salió mal, podría reproducirlo nuevamente y usar el historial grabado para controlar cuándo ocurrirían las interrupciones. Entonces lo hicieron reproducible, sí, pero a expensas de mucho más hardware del que podíamos pagar. No hace falta decir que nunca obtuvieron el OS / 360 correcto. 

Frana: Eso es verdad. Eso es muy cierto. 

Dijkstra: Porque ... 

Frana: ¿Eso nunca se le habría ocurrido a un europeo? 

Dijkstra: No, éramos demasiado pobres. 

Frana: ¿Para considerarlo? 

Dijkstra: Éramos demasiado pobres para considerarlo y también decidimos que debíamos tratar de estructurar nuestros diseños de tal manera que pudiéramos mantener las cosas bajo nuestro control intelectual y que no había necesidad de buscar errores en forma experimental. Esta fue una gran diferencia entre las actitudes europeas y americanas sobre la programación a la que volveré más adelante.

Bien, en 1958, escribí el software básico y escribí mi tesis al respecto. Solo tuve la defensa oral un año después porque escribí mi tesis en holandés. Esos fueron los días en que no podía escribir con fluidez en inglés, y fue traducido con la ayuda de un colega sudafricano. En 1959, publiqué esos dos algoritmos, el camino más corto y el árbol de expansión mínimo [Algoritmo de Prim?]. Tuve mi defensa oral y me convertí en Dr. Dijkstra. Y hubo una experiencia iluminadora en el Centro de Matemáticas. Había desafiado a mis colegas con la siguiente tarea de programación. Considere dos programas cíclicos, y en cada ciclo ocurre una sección llamada sección crítica. Los dos programas pueden comunicarse mediante lecturas únicas y escrituras únicas en una almacén común, y sobre las velocidades relativas de los programas no se sabe nada. Intente sincronizar estos programas de tal manera que, en cualquier momento, como máximo, uno de ellos participe en su sección crítica. Es una implementación del problema de exclusión mutua que más tarde se convirtió en la piedra angular del sistema de multiprogramación, subyacente al concepto de monitor y muchas cosas más. Lo miré y me di cuenta de que no era trivial en absoluto, había todo tipo de condiciones secundarias. Por ejemplo, si uno de los programas permanecería durante mucho tiempo en su sección no crítica, el otro debería poder continuar sin obstáculos, por lo que no se permitía ir alternativamente. Otra cosa que no estaba permitida era lo que llamamos el bloqueo "Después de usted", donde los programas competirían por el acceso a la sección crítica y el dilema nunca se resolvería. Entonces, mis amigos en el Centro de Matemáticas entregaron sus soluciones, pero todos estaban equivocados. Para cada supuesta solución, podría esbozar un escenario que revelaría el error. Bueno, lo que sucedió entonces fue que la gente hizo sus programas más sofisticados, más complicados, y uno o dos días más tarde se les ocurrió su próxima versión. También estuvo mal, solo la construcción y los contraejemplos se volvieron aún más largos y tuve que cambiar las reglas del juego. Les dije: "Señor, lo siento, pero ya no puedo pasar todos mis días refutando sus vanos esfuerzos. De ahora en adelante, solo acepto una solución con un argumento de por qué es correcta ". 

Frana: ¿Con la corrección del programa? 

Dijkstra: Sí, y al cabo de tres horas más o menos Th. J. Dekker vino con una solución perfecta y una prueba de su corrección. Había analizado qué tipo de prueba se necesitaría. ¿Cuáles son las cosas que tengo que mostrar? ¿Cómo puedo probarlos? ¿Cuál sería una estructura aceptable de la prueba de corrección? Habiendo resuelto eso, escribió un programa que cumplía con el requisito de la prueba. Lo que muestra claramente que se pierde mucho cuando restringe el papel de las matemáticas a la verificación del programa en lugar de la construcción o derivación del programa. Eso fue lo que aprendimos de la competencia que ganó Dekker.

(Disculpeme un momento.) . . . . .

Otra experiencia de 1959 fue el Congreso Zeroth IFIP en París, un precursor bajo los auspicios de las Naciones Unidas. Asistí a eso, aunque todavía era un joven no muy conocido. Había visitado Inglaterra varias veces, había visitado Alemania algunas veces. Mis contactos internacionales comenzaron en diciembre de 58, cuando comenzaron las reuniones preparatorias para el diseño de ALGOL 60. Normalmente, el Centro de Matemáticas habría estado representado por mi jefe, Aad van Wijingaarden, pero había tenido un grave accidente automovilístico y J.A. Zonneveld y yo, como sus subordinados inmediatos, tuvimos que reemplazarlo. Zonneveld era analista numérico e hizo el trabajo numérico, mientras que yo, como programador, hice el trabajo de programación. Y así comencé a asistir a las reuniones preparatorias para ALGOL 60. Esa fue la primera vez que tuve que llevar a cabo discusiones espontáneas en inglés. Fue difícil. 

Frana: ¿Cómo aprendiste? 

Dijkstra: Bueno, por supuesto, tenía inglés en la escuela, en la escuela secundaria. Había leído mucho, no tenía experiencia en escribirlo o hablarlo. Aprendí muchísimo de mis amigos tan pronto como supieron que me gustaba que me corrigieran. Y estoy extremadamente agradecido con Mike Woodger, del Laboratorio Nacional de Física, Teddington, a quien conocí en diciembre de 58 por primera vez. Rápidamente hizo una regla para sí mismo que solo corregiría los errores que me escuchaba cometer por segunda vez, porque de lo contrario la conversación hubiera sido imposible. Eso ayudó mucho y creo que después de tres o cuatro años más o menos, comencé a sentirme cómodo.

Frana: Te escuché comentar que aprender muchos idiomas diferentes es útil para programar. 

Dijkstra: Oh sí, es útil. Hay una enorme diferencia entre alguien que es monolingüe y alguien que al menos conoce bien un segundo idioma, porque te hace mucho más consciente del fenómeno de la estructura del lenguaje en general. Descubrirá que ciertas construcciones en un idioma no se pueden traducir. Una vez me preguntaron cuáles eran los activos más vitales de un programador competente, y dije, en ese momento, una inclinación matemática y un dominio excepcional de su lengua materna. Dije "inclinación matemática" porque en ese momento no estaba claro cómo las matemáticas entendidas en ese momento podían contribuir a un desafío de programación. Y dije "lengua materna" y no "inglés" porque, bueno por falta de formalismo, tienes que pensar en términos de palabras y oraciones usando un idioma con el que estés familiarizado. Además, pero no sabía que en ese momento, la investigación ha demostrado que cuando las personas adquieren un segundo idioma, nunca lo dominan más de lo que lo hacen de su propio idioma, su lengua materna: eso establece claramente el estándar de cómo de articulado vas a ser.

Frana: Sé que he interrumpido tu cronología aquí. Como marco de referencia, ¿qué tan lejos estamos del comienzo del Grupo de Trabajo 2.3?

Dijkstra: diez años.


Frana: ¿Diez años después?
 
Dijkstra: si. Eso comenzó en ...
 
Frana: ¿69?

Dijkstra: si. '69, y estábamos en '59 en París. Una de las principales cosas que recuerdo de eso fue que Alan Perlis del Instituto de Tecnología Carnegie, no creo que ya fuera CMU en ese momento, trató de contratarnos a Peter Naur y a mí. Debe haber tenido buen gusto para elegirnos, para elegir a Peter y a mí entre esa multitud de personas. Tan pronto como Peter escuchó lo que a Perlis le gustaría que hiciéramos, se volvió muy despectivo. Se refirió a los Estados Unidos como "El país atrasado".

Frana: Peter lo hizo?
 

Dijkstra: si. Dijo que si querían embarcarse en un proyecto tonto, mejor que lo hicieran ellos mismos.
 

Frana: Creo que se ha suavizado desde entonces.
 

Dijkstra: Lo conozco desde hace años.

Frana: Es amigo de Arthur Norberg, el Director de CBI.
 
Dijkstra: Oh si?
 
Frana: Todavía están en contacto. 

Dijkstra: ¿Lo son? Ahora bien, llegó ALGOL 60, que en retrospectiva, creo, debería considerarse como el comienzo de la ciencia de la computación; si deseamos marcar una discontinuidad en la forma en que pensamos acerca de la informática, entonces es el surgimiento de ALGOL 60. Volveré sobre eso más adelante, en la medida en que ha hecho, por ejemplo, el tema académicamente respetable.

Frana: Sí, quiero saber más sobre eso.

Dijkstra: Yo había publicado un artículo llamado "Programación recursiva", nuevamente en Numerische Mathematik, que era una locura porque no tenía nada que ver con las matemáticas numéricas, pero ese era el medio en ese momento. En el 61, comencé a pensar en la programación y comencé a darme cuenta de que la programación realmente era un desafío intelectual. Una de las cosas que Peter y yo hicimos fue ser oradores principales en un taller o una escuela de verano que se había organizado en Brighton, Inglaterra. Había algún tipo de instituto de estudio sobre programación automática, organizado por cierto Goodman; había un buen número de científicos británicos conocidos en esa audiencia y creo que eso jugó un papel importante en que me conocieran en Gran Bretaña. En mi conferencia tuve a Tony Hoare, y ninguno de nosotros recuerda eso. No lo recuerdo porque era una de las muchas personas del público, y él no lo recuerda porque en su memoria Peter Naur y yo, ambos con barba y acento continental, nos hemos fusionado en una sola persona. [risas] Más tarde reconstruimos que los dos estábamos allí. 

Frana: ¿Ambos estuvieron allí?

Dijkstra: Los dos estábamos allí: él estaba en la audiencia, y yo era uno de los principales oradores. Bien, ahora en 1962, fue cuando mi pensamiento sobre la sincronización del programa resultó en las operaciones P y V; ese fue un paso importante en 1962. La otra cosa que recuerdo fue una conferencia en Roma sobre manipulación de símbolos, en abril más o menos. Peter estaba allí, con su esposa. Y ellas, las chicas, fueron a Roma durante el día, y un día regresaron y había una recepción al final del día; Era temprano y mientras caminábamos entre la multitud, escucharon a un tipo resumir a otro la situación política: claramente, por supuesto, estaban los estadounidenses, y estaban los alemanes, y había
Los franceses y los ingleses. "Et alors il’y a les deux Fidel Castros!" Un momento hilarante ... Hubo mesas redondas y Peter y yo estábamos sentados uno al lado del otro y recibimos toda clase de comentarios desagradables, pero hicimos la regla de bajar las escaleras al micrófono por turno, cuando fuera mi turno, y la próxima vez iría él. Esto continuó así durante una hora más o menos, y Van Wijngaarden, mi jefe, estaba sentado al lado de un estadounidense y en un momento dado el estadounidense lo agarra del hombro y dice: "¡Dios mío! Pero si hay dos!. ”[Risas] ¿Esto puede incluirse en una historia oral? No es matemáticas, tampoco es informática, pero es una historia real ... 

Lo siguiente fue que, en septiembre, fui al primer Congreso IFIP, que se celebró en Munich, y pronuncié un discurso invitado sobre el avance de la programación, y fue allí donde
recibí una serie de aplausos [curtain calls]: claramente estaba diciendo algo inusual. Volveré a eso también más tarde. Luego me convertí en profesor de Matemáticas en Eindhoven, y durante dos años impartí clases sobre análisis numérico. Para 1963/64, diseñé con Carel S. Scholten la especificación de los canales de hardware y las interrupciones de la Electrologica X8, la última máquina que mis amigos construyeron, y luego comencé el diseño del sistema de programación múltiple, que fue completado unos años más tarde. Por supuesto, '64 fue el año en que IBM anunció el 360. Yo estaba extremadamente enfadado con Jerry Blaaw, con quien había cooperado y que debería haberlo sabido mejor, porque había graves fallas en la organización de E/S de esa máquina. . 

Frana: ¿Qué habías discutido con él antes?


Dijkstra: No, no lo había hecho, pero debería haber sabido de mi tesis doctoral, y él debería haber sabido sobre la atención que debe dedicarse al diseño de tales cosas, pero eso claramente no era parte de la cultura de IBM. En mi conferencia de Turing, describí la semana en que estudié las especificaciones del 360, fue [risas] la semana más oscura de mi vida profesional. En una conferencia de la OTAN sobre ingeniería de software en 1969 en Roma, caractericé la decisión rusa de construir una copia de IBM 360 compatible con bits como la mayor victoria estadounidense de la Guerra Fría.

Frana: ¿Eso formó parte de las actas? No lo recuerdo

Dijkstra: No. Eso no hizo el procedimiento, no; Brian Randell y John Buxton se dieron cuenta de eso. Pero se extendió de todos modos. Me dieron un anuncio que durante muchos años ha sido publicado en un centro de cómputo sovjet. Era un cosaco bailando con una bandera que decía: "Queremos a IBM". Y debajo había esa cita, sobre la victoria en la Guerra Fría. Y tuve el placer de contárselo a un público ruso en Petersburgo. Alguien me preguntó mi opinión sobre el 360, y pensé que este era el resumen más compacto que existía y lo di. Y un tercio de la gente se rió, así que sabías cuántos de ellos entendían inglés. Mi forma de revisarlos. Bien ahora, 64-65. Había generalizado la solución de Dekker para los procesos de N y la última oración de ese artículo de una página es: "Y esto, según el autor, completa la prueba". Según Doug Ross, quien escribió una revisión del artículo, se trataba de primera publicación de un algoritmo que incluía su prueba de corrección. Si eso es correcto o no, no lo sé. Sí, escribí "Procesos secuenciales cooperantes" e inventé el problema del quintuple de la cena, que más tarde se conoció como "el problema de los filósofos de la cena". Ese nombre se lo dio Tony Hoare. Y di una charla invitado en la Conferencia IFIP en Nueva York.
 
Frana: ¿Ese fue tu primer viaje?


Dijkstra: No, fue mi segundo viaje. Mi primer viaje había sido en el 63. Eso fue en una conferencia de ACM en Princeton. Y luego visité varios grupos de Burroughs, esa fue la primera vez que conocí a Donald Knuth. Hablé acerca de la fama: de una forma u otra ya debia tener fama en 1963 en mi primera visita a los Estados Unidos, porque esto era un taller de la ACM con aproximadamente 60 a 80 participantes y me invitaron a unirme. Y me pagaron quinientos dólares. Quinientos dólares eran bastante en esos días, y no tenía que hacer nada: no necesitaba pronunciar un discurso, no tenía que sentarme en un panel de discusión, solo querían que estuviera allí . Toda una experiencia increíble.

Frana: si.
 
Dijkstra: Ese fue el comienzo de mi visita. Y luego encontré otro dinero para viajar un poco más.


Frana: ¿Qué recuerdas de tus dos primeros viajes a Estados Unidos que te sorprendieron sobre la forma en que parecía funcionar la profesión?


Dijkstra: Bueno, la primera conferencia en ese taller fue dada por un tipo de IBM. Fue muy algebraico y complicado. En el pizarrón escribió fórmulas de pared a pared y no entendí ni una sola palabra. Pero hubo muchas personas que se unieron a la conversación, que se unieron a la discusión y plantearon preguntas. Y tampoco podía entender esas preguntas, ni las respuestas, y, como dije, me invitaron a venir e incluso me pagaron por venir. Me sentí miserablemente fuera de lugar y por la noche, durante una recepción, expresé mi preocupación de estar allí en falso. "¿Cómo?" [Me preguntaron.] "Del primer orador, no entendí una palabra". "Oh", dijo, "ninguno de nosotros lo hizo. Todo eso era una tontería y un galimatías, pero IBM está patrocinando esto, así que tuvimos que darle el primer lugar a un orador de IBM ".

Frana: muy común.

Dijkstra: Bueno, eso fue totalmente nuevo, totalmente nuevo para mí.
 

Frana: ¿Un orador principal sería alguien que realmente no iba a participar en la conversación?

Dijkstra: Sí, y todos lo saben y todos están haciendo estos movimientos. Era un grado de deshonestidad científica para la que no estaba preparado. O ... "un grado de deshonestidad científica", que es un término demasiado fuerte. Digamos que la valla entre la ciencia y la industria, la valla alrededor de un campus universitario, no es tan alta como yo solía estar acostumbrado.

Frana: ¿Fueron intelectuales públicos y científicos atacados esos dos primeros viajes?
¿Recuerdas cómo eran un par de años después? 


Dijkstra: Oh si. Fue en este viaje, creo que en mi primer viaje, que aprendí el término "cabeza de huevo". 
El recuerdo más divertido no tiene nada que ver con la informática. Estaba sentado frente a The Old Nassau Inn y hubo una reunión de veteranos de alguna guerra que querían tomarse una foto y la esposa de uno de ellos tomaría la foto. Sin embargo, esa era una vieja cámara Polaroid Land, y tenías que sostenerla por un tiempo y ella no pudo hacer eso: cada vez, un minuto después, cuando salió la cosa, todo estaba borroso, miré y lo vi. . Entonces uno de los muchachos me grita: “Hola, joven. ¿Tienes una mano firme? ”Así que este joven tenía una mano firme y tomé la foto. 

En el año 66 fue la finalización del diseño del sistema THE, el algoritmo bancario. El año 67 fue la Conferencia ACM sobre principios de sistemas operativos en Gatlinburg. Creo que fue la primera vez que tuve una gran audiencia estadounidense. Fue en esa reunión, una tarde que estaba sentado afuera, que le expliqué a Brian Randell y a algunos otros una de las razones por las cuales la declaración 'GOTO' introducía complejidad. Y me pidieron que lo publicara. Así que envié un artículo a las Comunicaciones de la ACM, llamado "Un caso contra la declaración GOTO". El editor de la sección quería publicarlo lo más rápido posible, por lo que lo convirtió de un artículo en una Carta al Editor , que podría publicarse de inmediato. Y al hacerlo, cambió el título a "El 'GOTO' Considerado Dañino". 

Frana: ¿Cuál era el título original?
 
Dijkstra: El título original era "Un caso en contra de la declaración IR A".
 
Frana: Bueno, eso cambia las cosas considerablemente.
 
Dijkstra: Sí, y el título se convirtió en una plantilla. Cientos de escritores han "X considerado dañino", con X cualquier cosa. El editor que hizo este cambio fue Niklaus Wirth.
 
Frana: Wow Esa es una frase que entró en ...
 
Dijkstra: la jerga ...
 
Frana: El léxico común ... sí.

Dijkstra: si. Ahora al 68. '68 fue emocionante debido a la primera Conferencia de la OTAN sobre Ingeniería de Software, en Garmisch. En BIT publiqué un artículo, 9 que pasó desapercibido porque la circulación de BIT era demasiado pequeña, sobre "Un enfoque constructivo para el problema de la corrección del programa". Recuerde lo que dije sobre la experiencia de Dekker en '59. 68 también fue el año del anuncio de IBM en Datamation, de una radiante Susy Mayer, a todo color, que acababa de resolver todos sus problemas de programación al cambiar a PL / I. Recuerde, esos fueron los días en que nos vimos obligados a creer que los problemas de programación eran los problemas de las deficiencias del lenguaje de programación con el que estaba trabajando, y si tomara el lenguaje correcto, ya no habría problemas.

Frana: no lo sabía.
 
Dijkstra: Oh si. Creo que lo superó antes de su muerte, pero durante muchos años APL fue "eso". Y esa fue una de las razones por las que escribió junto con Lipton y De Millo un documento contra las pruebas de corrección, porque no podía hacerlo para los programas APL. Publicó un artículo muy desagradable argumentando en contra de un enfoque matemático de la programación.

Frana: ¿Qué estaba mal con ALGOL?

Dijkstra: No se sintió satisfecho con eso o ... Nunca he entendido el desarrollo de Alan Perlis, pero se volvió matemáticamente severo. Si eso fue una reacción a su entorno, un conjunto socialmente aceptable ... o si fue propio, no lo sé. Bien, 1969. En ese año escribí "Notas sobre programación estructurada", que en retrospectiva creo que debía su impacto estadounidense al hecho de que había sido escrito al otro lado del Océano Atlántico; que tiene dos lados muy diferentes.

Frana: Sí, lo son.

Dijkstra: Sí, y tengo la sensación de que puedo hablar de esto con cierta autoridad, habiendo vivido aquí durante la mayor parte de diecisiete años.
 
Frana: Holanda y Texas son lugares muy diferentes.

Dijkstra: Claro. Pero hay una cosa que uno de estos días declararé enfáticamente en público, pero ya puedo expresarlo aquí, y es que creo que gracias a la gran posibilidad de comunicación, exageramos su importancia. Aún más fuerte, subestimamos la importancia del aislamiento.

[transición]

Dijkstra: Mira, mira lo que ilustra esa invitación del 63 al taller de ACM, en un momento en que había publicado muy poco, tampoco había hecho tanto. Había implementado ALGOL 60 y había escrito un controlador de interrupciones en tiempo real, acababa de convertirme en un programador profesional. Sin embargo, resultó ser bastante conocido. ¿Cómo? No lo entendí completamente, pero lo que sin duda desempeñó un papel es que, gracias a mi aislamiento, haría otras cosas y haría cosas diferentes a las personas sometidas a las presiones estándar de conformidad.

Frana: Ya veo, a la manera de IBM.
 

Dijkstra: si. No tuve presión para complacer a IBM o complacer a las personas que pensaban que IBM era genial. Yo era un hombre libre.

Frana: Entonces IBM Europa no tenía el control del camino ...

Dijkstra: No. Una de las cosas que salvó a Europa fue que hasta 1960 más o menos, los primeros diez años, por así decirlo; No se consideraba un mercado interesante. Entonces fuimos ignorados. Nos ahorramos la presión. Por supuesto, no entendí todo eso en ese momento. No tenía idea del poder de las grandes empresas. Hace poco me enteré de que, en dólares constantes, el desarrollo del IBM 360 resultó ser más costoso que el Proyecto Manhattan.

Frana: no lo sabía.

Dijkstra: si. Teniendo en cuenta que IBM 360 podría haber provocado un daño mayor, sería apropiado.

 
Frana: Ahora, también la cultura popular estadounidense, ¿tiene algún efecto? ¿El tipo de homogeneización de la cultura que existe?

Dijkstra: No me di cuenta de eso. Recuerdo que cuando comencé a ver publicaciones estadounidenses en el primer número de Communications of the ACM, me sorprendió la forma torpe e inmadura en la que hablaban de informática. Hubo un uso muy fuerte de la terminología antropomórfica, los "cerebros electrónicos o máquinas que piensan".

Frana: si.
 

Dijkstra: Sí, y eso es absolutamente mortal, porque una de las cosas más tortuosas que hacemos es existir a tiempo y el uso de terminología antropomórfica te obliga lingüísticamente a adoptar una visión operativa. Y hace que sea prácticamente imposible, al menos muy difícil discutir sobre programas independientemente de su posibilidad de ser ejecutados.

Frana: Entonces, ¿es por eso que la investigación de Inteligencia Artificial aparentemente no se desarrolla en Europa?

 
Dijkstra: Había una restricción financiera muy clara: en ese momento teníamos que usar las máquinas que podíamos construir con las cosas disponibles. También hay una gran barrera cultural. La mente europea tiende a mantener una mayor distinción entre el hombre y la máquina. Está menos inclinado a describir máquinas en terminología antropomórfica; También está menos inclinado a describir la mente humana en terminología mecánica. No sé si te das cuenta de que Freud nunca se enfureció en Europa como le ocurrió en Estados Unidos.

Frana: Tal vez este es un buen lugar para ... Estaba leyendo algunos de tus informes de Burroughs y había una declaración realmente interesante allí. Perdóname por repetir esto.
 

Dijkstra: si.
 

Frana: Usted dijo: "Las herramientas que utilizamos tienen una influencia profunda y tortuosa en nuestros hábitos de pensamiento y, por lo tanto, en nuestras habilidades de pensamiento".
 

Dijkstra: si.

Frana: Y luego, en otro lugar, dijiste, para tomar un rumbo diferente: “Mientras consideremos a las computadoras principalmente como herramientas, podríamos subestimar su importancia. Su influencia como herramientas podría llegar a ser una onda en la superficie de nuestra cultura ”. ¿Estás hablando aquí de toda la mirada cibernética que han prestado a la sociedad? ¿Nos hemos convertido en - - pensamos como nuestras máquinas?
 

Dijkstra: No no no no.
 

Frana: ¿Nuestras máquinas piensan como desearíamos que lo hicieran?

Dijkstra: No. La intrincada influencia de las herramientas se inspiró en la experiencia con un estudiante brillante. En el examen oral resolvimos un problema. Juntos construimos el programa, decidimos lo que tenía que hacer, pero muy cerca del final, el niño se quedó atascado. No podía concebir ..., y en realidad me sorprendió porque era un niño brillante y lo sabía perfectamente bien, había entendido perfectamente el problema. Y se dio cuenta de que se quedó atascado y sin una razón aceptable. Ya casi habíamos terminado, él ya tenía su calificación, al menos en mi mente. Discutimos cómo se quedó atascado. Resultó que lo que tenía que hacer era escribir un valor subíndice en una posición de subíndice, la idea de un subíndice suscrito, algo que no estaba permitido en FORTRAN. Y habiendo sido educado en FORTRAN, no podía pensar en eso, aunque era una construcción que me había visto usar en mis conferencias.

 

Frana: ¿Entonces el uso de ese lenguaje lo hizo incapaz de resolver eso?

Dijkstra: De hecho. Y también descubrí que cuando los jóvenes estudiantes tenían dificultades para comprender la recursividad, siempre se debía al hecho de que habían aprendido a programar en un lenguaje de programación que no lo permitía. Si ahora usted está entrenado en una forma de pensar tan operativa, en un momento dado su patrón de comprensión se convierte en visualizar lo que sucede durante la ejecución del algoritmo y la única forma en que puede ver el algoritmo es como un programa FORTRAN. Entonces, su patrón de comprensión se familiarizaría como si fuera un programa en FORTRAN.  Lo cual, por supuesto, significaría que comprender la recursión implicaba sentirse mentalmente obligado a implementar la recursividad en FORTRAN. No se esperaba que pudiera hacer eso.

Frana: He escuchado un comentario similar de un amigo mío, Herb Pelnar, un programador en el Sistema 3 en todo el Sistema 38; dijo que no fue sino hasta después de retirarse que realmente se dio cuenta del enfoque orientado a objetos de la programación. Él intentó muchas veces entenderlo realmente, pero la forma en que miró los problemas le impidió entenderlo todo.

Dijkstra: si.
 
Frana: ¿Y cuál es la respuesta para nuestros futuros estudiantes? ¿Intenta evitar la misma trampa?
 
Dijkstra: Enséñeles lo antes posible un lenguaje de programación decente que sea atractivo, que ejerza su poder de abstracción.
 
Frana: ¿Dónde ..., en qué punto, entonces, esta idea de programación matemática se convierte en una forma de describir el enfoque que estaba tomando? ¿Fue un término que acuñaste o fue ...
 
Dijkstra: ¿programación matemática? No.
 
Frana: No, fue una idea que alguien más ...

Dijkstra: Ese es un término peligroso porque también existen los términos programación lineal y programación dinámica, y no tienen nada que ver con la programación. Son técnicas de optimización.
 
Frana: No importa que la programación matemática ... suena como una contradicción de los términos.


Dijkstra: Esa fue una de las cosas que aprendí en 1968, en Garmisch. Mira, estaba en el Departamento de Matemáticas de la Universidad Técnica de Eindhoven, y el título oficial de nuestro producto era "Ingeniero matemático". Ahora había pensado que el diseño de sistemas digitales sofisticados era un área por excelencia para un ingeniero matemático. todos los aspectos constructivos, tiene todos los aspectos de prueba que tiene ... Por supuesto, debe encontrar sus formas de dar forma al programa de modo que su control intelectual se vuelva susceptible a las técnicas del pensamiento científico. Tienes que hacer eso. Durante Garmisch aprendí que en los oídos de los estadounidenses, un ingeniero matemático era una contradicción de términos: el matemático estadounidense que es un académico poco práctico, mientras que el ingeniero estadounidense es práctico pero apenas tiene formación académica.

Frana: ¿Hasta hoy?

Dijkstra: Hasta hoy, sí. Y eso hace que todas estas discusiones sean muy, muy difíciles. Te das cuenta de eso, te das cuenta de que todas las palabras importantes tienen significados diferentes, ligeramente diferentes. Me decepcionó en Estados Unidos por la forma en que rechazaron el ALGOL 60. No lo esperaba. En cierto modo, lo considero una tragedia porque es un síntoma de cómo Estados Unidos se está volviendo cada vez más amatemático. Ha utilizado todo el siglo XX para hacer eso, como lo ilustra Morris Kline ["Mathematics in Western Culture"] de manera elocuente. Precisamente en el siglo que presencia la aparición de equipos informáticos, vale la pena tener una mente matemática bien entrenada. Y cuando menciono la mente matemática, me refiero menos al quod que al quo modo, menos en el tema de las consideraciones que en la forma en la que se abordan los problemas. Así es como reconoces a alguien como matemático, incluso si trata temas en los que nunca has pensado.

Frana: Pero el negocio de Estados Unidos es el negocio, este país puede absorber tantos programadores de COBOL como pueda producir.
 
Dijkstra: si. NYNEX emplea noventa mil programadores COBOL.
 
Frana: ¿Nynex lo hace?
 
Dijkstra: En un momento lo hizo; ese es al menos el rumor que escuché. 

Frana: Quería hacerte otra pregunta sobre la comparación de estadounidenses y europeos. Un amigo mío, Peter Patton, es el director de tecnología de Lawson Software en St. Paul. Dirigió el Centro de Computación Académica de la Universidad de Minnesota durante muchos años, y el primer centro de supercomputación allí. E hizo instalaciones de máquinas CDC 6600 en Europa. Y no supe esto durante bastante tiempo, pero él escribió con seudónimo llamado "Libellator in Communications" en '63 de sus percepciones sobre las diferencias entre estadounidenses y europeos. Y dijo que los programadores europeos son solitarios y ferozmente independientes, mientras que los estadounidenses son jugadores de equipo. Y eso parecía contradecir, soy bastante joven, mi idea de cómo se comportan los programadores en Estados Unidos y en Europa. Me habría gustado pensar que podría ser al revés: que los estadounidenses son ferozmente independientes, y que los europeos son jugadores de equipo.

[Pausa para un descanso para tomar café]
 
Frana: ¿Quisiera abordar ese comentario?

Dijkstra: Eso fue muy perceptivo por parte de tu amigo. Varios años después de la guerra, Marten Toonder, un famoso artista holandés que ilustró sus propias historias. Escribió uno sobre “Heer Bommel en de teemgeest” - “teemgeest” es una palabra inventada - en la que ridiculizó la noción novedosa de “espíritu de equipo”. El comentario sobre los solitarios: bueno, cuando vine a Eindhoven en el Departamento de Matemáticas, llegué con diez años de experiencia en el Centro de Matemáticas, donde solíamos cooperar en grandes proyectos y aplicar una división del trabajo; Fue algo impactante cuando entré en esa comunidad en la que todos trabajaban solos. Después de completar el Sistema THE, por ejemplo, Nico Habermann escribió una tesis sobre el Algoritmo del banquero y sobre la programación, el intercambio y la prevención de puntos muertos. Al departamento no le gustó eso porque no estaba claro cuánto había hecho él solo y cuánto se había hecho en cooperación. Y, de hecho, protestaron tanto que Cor Ligtmans, quien debería haber escrito su Tesis Doctoral sobre otro aspecto del sistema - se negó a hacerlo.
 

Frana: Por miedo a que él también fuera ...
 
Dijkstra: si. No era…

Frana: Lo que me parece interesante de esto es que la naturaleza del plan de estudios no refleja lo que has dicho sobre el individualismo del estudiante, del programador. Parece que hay una educación mucho más general en Europa que en América, donde parece muy altamente especializada. ¿El resultado del currículo es diferente?

Dijkstra: Debo tener mucho cuidado al responder esto porque durante mi ausencia, el papel de la universidad, el financiamiento de la universidad y la fracción de la población a la que se supone que se dirige han cambiado radicalmente. Eso ya comenzó en los años 70. Entonces, todo lo que digo sobre la universidad está desactualizado y probablemente también idealizado por la memoria. Sí. Pero una diferencia importante fue que la valla alrededor del campus universitario era más alta. Para darle un ejemplo, cuando comenzamos a diseñar un plan de estudios de ciencias de la computación en los años 60, una de las reglas firmes fue que ningún producto industrial sería el tema de un curso académico. 

Frana: Eso suena notable. No sé qué enseñarías hoy.

Dijkstra: es encantador. Esto descarta inmediatamente todos los cursos de Java, sí, y en ese momento descartó todos los cursos de FORTRAN. Enseñamos ALGOL 60, era un abridor de ojos mucho más grande que FORTRAN. Fue el poder de IBM lo que hizo de Estados Unidos un país atrasado. 

Frana: ¿Existe una relación entre esto, el plan de estudios y la naturaleza de la financiación de las universidades? Esas son las inversiones públicas y privadas en educación: hemos visto ese cambio dramáticamente en los últimos quince o veinte años.

Dijkstra: Oh sí, dramáticamente.

Frana: ¿Eso hace que la informática sea diferente? Las elecciones que hagas deben ser diferentes.

Dijkstra: si. Tiene la mayor influencia en la financiación de proyectos de investigación. Con regularidad veo a la firma XYZ proponiendo otorgar becas estudiantiles o algo así y luego, en algún lugar de la letra pequeña, se dará preferencia a los estudiantes supervisados por profesores que ya tienen contacto profesional con la empresa. Versiones como esa.

Frana: ¿Se aceptan esas propuestas en UT Austin? ¿O son rechazados? ¿Modificado?

Dijkstra: No lo sé, pero me temo que UT Austin no es tan crítica como hubiera querido. Pero me gustaría recordar las razones por las que creo que es justo decidir que
La informática comenzó con ALGOL 60.

Frana: Claro, no hemos hecho eso. Y también quiero saber por qué la ciencia de la computación proviene de diferentes departamentos que parece mas en Estados Unidos que en Europa. Así que no sé si esas conversaciones se podrían unir pero ...

Dijkstra: No.

Frana: Quizás no.

Dijkstra: Ahora, la razón por la que ALGOL 60 fue un milagro fue que, por un lado, no era un proyecto universitario sino un proyecto creado por un comité internacional, mientras que, por otro lado, introdujo alrededor de media docena de novedades profundas. Lo que introdujo, en primer lugar, fue la ausencia de restricciones arbitrarias como, por ejemplo, descartar el subíndice suscrito, el ejemplo que mencioné y que mostró cuán dañinas podrían ser tales cosas. Una segunda novedad fue que, al menos para la sintaxis sin contexto, se dio una definición formal. ¡Eso hizo una tremenda diferencia! Se convirtió en análisis, es decir, un aspecto importante de la redacción de compiladores, una disciplina rigurosa, que ya no era un gran trabajo manual, pero tal vez más importante, hizo que la redacción de compiladores y los temas de definición del lenguaje merecieran atención académica. Jugó un papel importante en hacer que la informática sea académicamente respetable. La tercera novedad fue la introducción del tipo "booleano" como ciudadano de primera clase. Convierte la expresión booleana de una declaración de hecho que puede ser incorrecta o correcta en una expresión de una declaración de hecho que puede ser incorrecta o correcta en una expresión que tiene un valor, por ejemplo, "verdadero" o "falso". ese paso lo aprendí de la reacción de mi madre. Era una matemática talentosa, pero no podía dar ese paso. Para ella, "tres más cinco son diez" no era una forma complicada de decir "falso", simplemente estaba mal. Solo podía ver las expresiones booleanas como una declaración de hechos y no como expresiones con las que puedes calcular sin interpretarlas. Potencialmente, esto va a tener una influencia muy profunda en cómo se hacen las matemáticas, porque las pruebas matemáticas, que solían ser algo muy especial, ahora se pueden representar como simples cálculos que reducen una expresión booleana mediante transformaciones que preservan el valor en el valor "verdadero . ”La cuarta novedad fue la introducción de la recursividad en la programación imperativa. La recursión fue un paso importante. Fue introducido de una manera furtiva. El borrador del informe ALGOL 60 se distribuyó en una de las últimas semanas de diciembre de 59. Lo estudiamos y nos dimos cuenta de que las llamadas recursivas eran casi admitidas, aunque no se mencionó. Y llamé a Peter Naur - esa llamada a Copenhague fue mi primera llamada telefónica internacional, ¡nunca olvidaré la emoción! - - y le dí una sugerencia con la sugerencia de que la incluyera. Fue algo así como "Cualquier otra ocurrencia del identificador del procedimiento denota la reactivación del procedimiento". Algo así. Esa oración ha sido insertada furtivamente. Y de todas las personas que tuvieron que estar de acuerdo con el informe, ninguna vio esa frase. Así es como se incluyó explícitamente la recursividad.

Frana: ¿Se llamaba recursión en ese momento?

Dijkstra: Oh si. El concepto era bastante conocido. Fue incluido en LISP, que comenzaba a surgir en ese momento.
 
Frana: ¿Entonces fue que no querías llamar la atención?

Dijkstra: Lo hicimos imperceptible, sí. Y F.L. Bauer nunca lo habría admitido en la versión final del Informe ALGOL 60, si lo hubiera sabido. Inmediatamente fundó el Grupo ALCOR. Era un grupo que juntos implementaría un subconjunto de ALGOL 60, y de ese subconjunto, la recursión quedó descartada enfáticamente. Una próxima novedad que debería mencionarse fue la estructura de bloques, que de alguna manera fue el primer esfuerzo para hacer uso de medios técnicos para mejorar la capacidad de control intelectual de los diseños. Era una herramienta para estructurar el programa, con el mismo uso de la palabra "estructura" que usé nueve años más adelante en el término "programación estructurada". El concepto de alcance léxico se mezcló maravillosamente con vidas anidadas durante la ejecución, y nunca he sido capaz de descubrir quién fue el responsable de esa síntesis, pero me impresionó profundamente cuando la vi. Y finalmente, la definición de la semántica era mucho menos operacional que para los lenguajes de programación existentes. FORTRAN se definió esencialmente por su implementación,
Considerando que con ALGOL 60 surgió la idea de que el lenguaje de programación debería definirse independientemente de computadoras, compiladores, tiendas, etc .; la definición debería definir cómo debería ser la implementación. ¡El adjetivo "tiempo de compilación" no debe aparecer en una definición de lenguaje! Y esa separación de preocupaciones - ahora estos son cinco o seis temas que por muchos años Estados Unidos ha pasado por alto, y creo que es una tragedia.

Frana: Y todos los argumentos en contra estaban fuera de lugar ...

Dijkstra: Era la obsesión con la velocidad, el poder de IBM, la sensación general en el momento de que la programación era algo que deberían hacer los imbéciles sin educación elegidos en la calle, no debería requerir ninguna sofisticación o lo que sea. Sí ... Los falsos sueños paralizaron mucha ciencia informática estadounidense.

Frana: Esto es algo que incluso Fred Brooks ha visto. ¿Has leído El Mítico Hombre-Mes?

Dijkstra: No.

Frana: Oh, nunca lo has hecho?

Dijkstra: No. Lo conocí [Fred Brooks] hace un mes.

Frana: Entonces, la ley "Nueve personas no pueden tener un bebé en un mes".

Dijkstra: si.

Frana: También en algún lugar del libro habla sobre programadores promedio y cómo hay unos pocos excepcionales que pueden programar. Son diez veces más eficientes, son cien veces más eficientes, son simplemente mejores programadores. Y él no lo dice tan elocuentemente como usted, sino que hay algo diferente en ciertos programadores.

Dijkstra: si. Sí.

Frana: Y creo que se vio obligado a usar programadores promedio porque no tenía otra opción o no creía que la tuviera.

Dijkstra: Diseñé el sistema de multiprogramación THE, y toda la sincronización, la prevención de estancamientos, todo eso, fue hermoso e impecable, eficiente y compacto y todas esas cosas buenas, pero en la programación industrial no causó ninguna impresión. El punto de vista industrial rechazó lo que habíamos hecho y el argumento principal fue: "Te hiciste la vida muy fácil: solo tenías unas pocas personas y eran de primera clase". Como dije hace una hora, considero el diseño de sofisticados sistemas de datos, un área de actividad por excelencia para el ingeniero matemático, sí. Hay pocas áreas donde se pague tan bien ... [¿Te gustaría otra taza de café?

Frana: no gracias.

Dijkstra: ¿Suficiente?

Frana: suficiente.]

Dijkstra: Hay pocas áreas donde paga tan bien como para ser lo suficientemente brillante y bien entrenado. Esto, en general, también fue rechazado en los Países Bajos. No he tenido influencia en la enseñanza de la programación como una disciplina intelectual dura pero gratificante; Esta opinión es apenas tolerada.

Frana: ¿Pero debes haber convencido a la gente de aquí cuando viniste?

Dijkstra: Oh sí, he convencido a las personas; No he cambiado la universidad.

Frana: Perdóname, lo he olvidado ahora, pero ¿quién tomó la decisión de contratación cuando viniste aquí?

Dijkstra: Ese era el Departamento de Ciencias de la Computación. El presidente de la época era Mani Chandy. Pero fue …

Frana: Bueno, creo que deberíamos almorzar pronto. Pero quería preguntarle, una vez más, por qué la informática, los departamentos de informática, en Europa,....... parecen salir de los programas de ingeniería eléctrica aquí, pero no en Europa. 

Dijkstra: Eso es correcto. Ahora, hay algunas razones. Uno importante es el tiempo. Por razones financieras, Europa, dañada por la Segunda Guerra Mundial, fue más tarde. Entonces, la informática estadounidense era anterior, la industria informática surgió antes. La industria de la computación solicitó graduados, lo que aumentó la presión sobre las universidades para suministrarlos, incluso si la universidad no sabía exactamente cómo. El efecto neto fue que en muchos lugares, se fundaron departamentos de informática antes de que la forma de la disciplina intelectual se destacara claramente.

Frana: Creo que en un momento lo llamaste cóctel. 

Dijkstra: Oh si. También lo encuentra reflejado en los nombres de sociedades científicas, como la Asociación de Maquinaria Informática. [(ACM)]

Frana: es muy extraño.

Dijkstra: lo es. Es la British Computer Society y fueron los holandeses quienes tuvieron Het Nederlands Rekenmachine Genootschap; sin saber holandés, puede escuchar la palabra "máquina" en ese nombre. Y tienes los departamentos de Informática.

Frana: ¿En lugar de computar?

Dijkstra: en lugar del departamento de ciencias de la computación o el departamento de computación. Europa fue más tarde, había acuñado el término informática. Tony Hoare era profesor de computación.

Frana: ¿Qué es 69, Informática, Informática?

Dijkstra: Informatique.

Frana: Ha sido un acertijo por algún tiempo. Nadie ha sido capaz de precisar cuando
...
Dijkstra: Pensé que fueron los franceses los que lo empujaron. En un momento dado, - hoy los ingleses prefieren las tecnologías de la información, TI y sistemas de información IS. Creo que el momento ha obligado a los departamentos estadounidenses a comenzar demasiado temprano. Y todavía lo sufren. Aquí, en UT, aún se puede observar: es el Departamento de Ciencias de la Computación.

Frana: ¿Plural?

Dijkstra: Plural, sí. Si comienzas a pensarlo, solo puedes reír, pero esa vez había al menos tantas ciencias de la computación como profesores.

Frana: si. Bueno, ¿deberíamos almorzar, un almuerzo tardío?

Dijkstra: si.

Frana: gracias.