Tony Hoare (C.A.R. Hoare) Interview: Communications ACM

Original [EN] text: https://conservancy.umn.edu/handle/11299/107362
By:  Philip Frana: 2002/07/17

Other: http://cseweb.ucsd.edu/~ricko/HoareInterviewCACM.pdf
By: Len Shustek 

Turing Award 1980:

CITATION: For his fundamental contributions to the definition and design of programming languages.
http://amturing.acm.org/award_winners/hoare_4622167.cfm

 Tony Hoare (C.A.R. Hoare)

Una entrevista con C.A.R. Hoare
(Charles Antony Richard Hoare)

C.A.R. Hoare, desarrollador del algoritmo Quicksort y colaborador de toda la vida en la teoría y el diseño de lenguajes de programación, analiza la aplicación práctica de sus ideas teóricas.

RESUMEN:
Sir Antony Hoare es investigador sénior en Microsoft Research en Cambridge, Inglaterra, e investigador / profesor emérito en la Universidad de Oxford. Hoare es el destinatario de la A.M. Premio Turing por contribuciones fundamentales a la definición y diseño de lenguajes de programación. También ha sido galardonado con el Premio Kyoto en Tecnología Avanzada por contribuciones pioneras y fundamentales a la ciencia del software. En esta historia oral, Hoare cuenta su participación personal en el desarrollo de la ciencia y la educación académica en computación en la Universidad de 'Queen', Belfast, Irlanda del Norte, y en la Universidad de Oxford. Habla sobre su interés desde hace mucho tiempo en construir puentes entre los departamentos universitarios de ciencias de la computación y la industria. Hoare también detalla su trabajo actual en Microsoft Research al aplicar 'asserts' y otras técnicas y teorías científicas a las operaciones industriales. Habla sobre su defensa de los 'asserts' en el mantenimiento y la transformación del código heredado. Hoare también comenta sobre otros temas, incluida la traducción automática de idiomas, la inteligencia artificial, el razonamiento bajo incertidumbre, el diseño y la confiabilidad del software, y la gestión de proyectos. La entrevista incluye una discusión sobre el problema de la preservación e interpretación del código.

CINTA 1 (Lado A)
 
Frana: ¿Cómo llegaste a estar aquí en Microsoft?

Hoare: En parte por preocupaciones románticas, comencé en la industria. Trabajé durante ocho años para un pequeño fabricante británico de computadoras, trabajé durante más de treinta años en la Universidad, y pensé que sería bueno crear un sándwich en mi vida al regresar a la industria durante los últimos años de mi vida laboral. En particular, las universidades británicas operan en una edad estricta de jubilación, que es de 65 años. Para entonces no me sentía totalmente acabado, por lo que la oportunidad de seguir trabajando en la investigación informática fue una oportunidad que realmente no pude resistir, a pesar de que significó mudarse de Oxford a Cambridge, que es un movimiento bastante significativo, a nivel personal. Creo que una oferta de Microsoft fue particularmente relevante, porque esta es una compañía que tiene el software como su producto principal, y sentí que si había alguna perspectiva de dieran frutos algunas de las ideas de investigación en las que había estado trabajando, y otras ideas de investigación a largo plazo que emanaban en general de la comunidad académica, Microsoft era el lugar en el que estar. Escuché una charla de Nathan Myhrvold, quien fue el fundador de la división de Investigación de Microsoft, y su descripción de la libertad académica y la naturaleza a largo plazo de la investigación realmente me atrajo, porque sentí que las universidades estaban bajo una presión creciente para concentrarse en Investigación a corto plazo e investigación con objetivos industriales a corto plazo. Microsoft no estaba adoptando una visión a corto plazo y sentí que me gustaría ayudar a contribuir a cualquier visión que tuvieran.  

Frana: ¿Podría contarme un poco sobre los grandes desafíos que describió cuando regresábamos del almuerzo y cómo llegó a verlo como un ejercicio valioso aquí en Microsoft?

Hoare: Bueno, la investigación en ciencias de la computación ha sido estimulada por una asignación bastante grande de fondos para los temas de Tecnología de la Información y Comunicaciones, pero los fondos generalmente se han asignado y vienen con ciertos lastres políticos. La investigación políticamente tiene que ajustarse a los objetivos de previsiblemente estar bastante cerca de su aplicación comercial, tener una buena perspectiva de brindar un beneficio económico a corto plazo y tener un camino claro hacia su aplicación. Sentí, y de hecho muchas personas piensan, que la ciencia no progresa solo por una serie de objetivos a corto plazo y que, aunque pueden contribuir en gran medida al progreso de la ciencia, también es necesario considerar los objetivos a largo plazo de un tipo que trasciende proyectos de investigación individuales, mientras trabaja con presupuestos limitados en escalas de tiempo limitadas. En la mayoría de las disciplinas científicas maduras, los objetivos a largo plazo se generan a partir de la lógica, la estructura de la ciencia misma. Están motivados por la curiosidad y el entusiasmo, y están algo separados de la aplicación final para la cual el conocimiento resultará relevante. La ciencia de la computación en general no ha tenido el privilegio de determinar sus propios objetivos de esta manera, y pensé que sería bueno, sería un desafío, digamos, tratar de complementar las motivaciones de investigación existentes con algunos grandes desafíos bien elegidos.

Frana: Entonces, ¿entiendo que las metas a corto plazo producen un crecimiento evolutivo, pero para producir un crecimiento revolucionario se necesitan metas a largo plazo?
 
Hoare: creo que es correcto. Al seleccionar objetivos a más largo plazo, uno debe crear oportunidades que los objetivos a corto plazo no permitirían. El objetivo a corto plazo siempre tiene que tener en cuenta: "¿Cómo llegamos allí desde aquí?" Siempre parte de la situación económica tal como es ahora y traza un camino evolutivo que en algunos casos está fuertemente limitado por el legado, en el caso del software, software heredado; en el caso de las comunicaciones, hardware heredado. Está limitado prácticamente en todos los casos por las creencias y actitudes heredadas de los usuarios de computadoras. Entonces, persiguir un objetivo revolucionario será un gran desafío que cambiará la forma en que todos pensamos sobre el tema, es preferible antes que a uno que de todos modos se logrará mediante pasos evolutivos.

Frana: ¿Entonces su experiencia en Oxford fue de una libertad cada vez menor?

Hoare: Creo que la libertad en Microsoft proviene del hecho de que no tenemos que crear una serie de propuestas para subvención. Aún así, creo que en Oxford fui realmente muy afortunado. Agradezco mucho la oportunidad y el aliento de trabajar con la industria para probar algunas de nuestras ideas. Tuve algunas colaboraciones muy exitosas con IBM y con una empresa británica de microprocesamiento llamada Inmos. Realmente inspiraron mucho del trabajo con el que ahora, incluso desde un punto de vista teórico, estoy muy contento.

Frana: ¿Tuviste conexiones con Microsoft cuando estabas en Oxford?

Hoare: No hubo conexiones con Microsoft en absoluto.

Frana: ¿Aparte de su uso de 'asserts'?

Hoare: Eso fue algo que descubrí más tarde. Estas cosas rara vez se atribuyen a su fuente cuando se usan en la práctica.

Frana: ¿Entonces no tenían idea de que los 'asserts' eran su especialidad? 

Hoare: Bueno, creo que muchos de ellos lo sabían, de hecho. Cuando llegué por primera vez, envié una misiva general preguntando a las personas sobre cómo estaban usando las aserciones [asserts], y descubrí que las estaban usando de muchas maneras diferentes. Los usaban principalmente para pruebas de programas, usando la aserción como un oráculo de prueba de la forma en que los ingenieros usan la instrumentación en un banco de pruebas para detectar la ocurrencia de errores lo más cerca posible del lugar en el que ocurren. Eso me sorprendió bastante, porque durante la fase académica de mi carrera fui muy antagónico con las pruebas. Me estaba concentrando en el papel potencial de las aserciones como un medio para verificar los programas de computadora, evitando los errores por completo, en lugar de simplemente tratar de eliminarlos mediante la depuración. Veo que el uso de aserciones para la prueba, el uso de aserciones para la especificación, el uso de aserciones para la verificación y el uso de aserciones para la optimización del código y para su documentación, todo esto está contribuyendo entre sí. Si podemos expandir la cultura del uso de aserciones, tal vez podríamos usar las mismas aserciones para más de uno de estos objetivos, y así explotar el esfuerzo que implica construirlos y formalizarlos de manera más efectiva. Ese es un mensaje que he estado predicando dentro de Microsoft durante algunos años. 

Frana: ¿Entonces estas aserciones quedan fuera del código compilado final que llega al usuario?

Hoare: La visión original era eso. Después de que las aserciones hayan cumplido su propósito durante las pruebas, como sondas de ingeniería, se eliminan antes de la entrega al cliente. En realidad, las computadoras entregadas a los clientes ahora son tan rápidas y tan grandes que es perfectamente posible dejar muchas de las aserciones en el código para que se ejecuten en el sitio del cliente. También protegen el código contra la posible aparición de errores que de otro modo podrían descarrilarlo. 

Frana: Ahora, este es un engranaje relacionado, pero leí un artículo que escribiste titulado "Legacy" [Herencia]. Se trata de proteger el código heredado con aserciones.

Hoare: si. He venido a aprender a vivir, e incluso a amar, lo heredado. Una parte importante del trabajo de un desarrollador de Microsoft es introducir cambios y adiciones a la funcionalidad del código heredado. Al mismo tiempo, tienen que leerlo y comprenderlo. Cuando lo han entendido, se inclinan ocasionalmente por mejorarlo; mejorarlo desde el punto de vista de hacerlo más comprensible, mejorar la documentación, agregar más aserciones, etc. Es el mantenimiento del código heredado el principal motivador para agregar aserciones redundantes adicionales al código en primer lugar. Por lo tanto, incluso el código heredado puede usarse como argumento para el uso más efectivo de las aserciones.

Frana: Gracias por actualizarme un poco sobre su investigación actual aquí en Microsoft.

[pausa]

Frana: Una de las cosas que los sociólogos nos dicen es que la experiencia requiere un cuerpo creíble de conocimiento. Cuando comenzaste, ¿tuviste el tipo de dificultad que tuvo tu amigo Dijkstra, por ejemplo, incluso para llamarte a ti mismo un "programador"? Una vez dijo que al principio no podía obtener un certificado de matrimonio porque las autoridades no reconocían la palabra "programador". En su lugar, tenía que identificar su profesión como "físico teórico".

Hoare: No, nunca tuve dificultades con la palabra "programador". Inicialmente, la palabra programador se refería a alguien que construye programas para programas de televisión, pero una vez que se superó esa confusión, creo que fue aceptado en mi pasaporte sin dificultad. Mi esposa también es programadora, así que espero que nuestro certificado de matrimonio tenga la palabra programador dos veces. Cuando me mudé por primera vez a la industria, la programación no se consideraba una profesión, ni nada a lo que se pudiera aplicar un cuerpo de conocimiento preexistente, porque simplemente no había ningún cuerpo de conocimiento preexistente. Acabamos de leer el manual, quizás asistimos a un curso corto y comenzamos a escribir código. Pensamos en ello como algo que cualquiera podría hacer. Se requieren talentos: poder imaginar la ejecución del programa, que aún no se ha escrito o ejecutado, y planificar cómo las diferentes partes de la ejecución encajarían entre sí. Pero para aquellos que podían hacerlo y les gustaba hacerlo, y generalmente lo hicieron, no se consideró realmente un gran desafío. Realmente fue solo cuando me mudé de la industria a la universidad en 1968 que comencé a pensar en lo que enseñaría. ¿Cómo se puede convertir este tema, que cada practicante se había enseñado a sí mismo, en algo que podría enseñar a otros? En realidad, leí un artículo de Peter Naur donde resumía su opinión sobre en qué debería consistir la educación en ciencias de la computación, y eso me influyó mucho. Luego, cuando tuve que establecer un título de posgrado y luego un título universitario en el tema, pude desarrollar mis ideas aún más.

Frana: Cuéntame un poco sobre Belfast. ¿Se enseñaba informática en el departamento de matemáticas en ese momento?

Hoare: El departamento de informática de la Universidad de 'Queen' en Belfast en 1968 empleó a cuatro personas y enseñó un curso de maestría. Fue miembro de un grupo de departamentos de la Escuela de Matemáticas y Física Aplicadas.

Frana: ¿Y qué tan rápido se convirtió en una rama separada con divisiones cuidadosamente definidas? ¿Teníais una ciencia de la computación que fuera altamente matemática y otra en una escuela dedicada a negocios y economía?

Hoare: Creo que en Belfast, como en muchas universidades en Gran Bretaña, el departamento de informática era bastante independiente de los departamentos de ingeniería. No solían estar dominados por la electrónica. Casi todos ellos eran completamente independientes de los departamentos de negocios y sociología. La asociación más probable fue una agrupación matemática. Pero podrían ser creados por un acto del vicerrector más o menos de la nada, y con libertad para desarrollar el tema con cualquier libertad académica de las personas que tengan para desarrollar su propio tema, de la misma manera que otros temas científicos también se definen a sí mismos. 

Frana: ¿Alguno de ellos surgió de la manera en que lo hizo Carnegie Mellon? ¿Alguno de los departamentos surgió de la administración de empresas o los programas de investigación de operaciones?

Hoare: no puedo responder a esa pregunta con ninguna autoridad, pero creo que en la London School of Economics el departamento de informática tuvo ese tipo de origen.

Frana: ¿Hubo una gran controversia sobre la "respetabilidad intelectual" de la informática cuando estabas en la Universidad de 'Queen'?

Hoare: Creo que definitivamente sentimos que teníamos que justificarnos. Existe un terrible orden jerárquico académico en las universidades que es un poco generalizado: los físicos no tienen que justificarse ante nadie, los biólogos también son bastante seguros y los matemáticos. Informática: sí, esa es una de las cosas que tenemos que hacer para ganar el respeto de nuestros colegas. Pero luego hay temas que incluso podemos despreciar.

Frana: Sé que los historiadores pasan mucho tiempo debatiendo sobre su respetabilidad, pero luego tenemos los politólogos para elegir.

Hoare: si.

Frana: ¿Le fueron útiles las primeras guías curriculares de ACM y BCS? 

Hoare: Miré las guías del plan de estudios de ACM, y creo que hubo algo similar de BCS y probablemente tuvieron una buena influencia inicialmente. Creo que una vez que la universidad ha establecido un departamento, también tiende a estar dominada por el legado, y solo hace pequeños cambios.

Frana: ¿Si señalaras las mejores novedades del departamento que estableciste en la Universidad de 'Queen'?

Hoare: en The Queen’s University, no sé si pensé que estábamos siendo muy novedosos. Los cursos se desarrollaron gradualmente porque los consideramos juntos como una escuela de titulación conjunta con matemáticas o física. Eso nos dio la posibilidad de comenzar siendo pequeños. En una universidad tradicional, una materia determinada solo podría ofrecer uno de cada tres cursos en el primer año de todos modos, y luego un par de cursos en el segundo año; luego un par de cursos en el tercer año, y luego ya tienes un título conjunto. La enseñanza creció a medida que creció el personal, siguiendo los intereses y la experiencia del personal disponible. 

Frana: ¿Cuándo obtuvo un programa de doctorado?

Hoare: Muchas universidades en Gran Bretaña comenzaron con un doctorado, y Belfast tenía estudiantes de doctorado en ciencias de la computación incluso antes de que yo llegara.

Frana: ¿Qué pasa con la acreditación? Durante su mandato en Belfast, ¿hubo organizaciones de acreditación?

Hoare: Las universidades en Gran Bretaña no tenían organizaciones de acreditación. Tenían órganos de gobierno independientes. Más tarde, por supuesto, las sociedades profesionales organizarían visitas de acreditación, pero no participé en ellas hasta que estuve en el cargo por algún tiempo.

Frana: Que usted sepa, ¿se adoptaron modelos de otras profesiones? Sé que a menudo has comparado la informática con la ingeniería. 

Hoare: si. He tomado la ingeniería como una especie de ideal al que aspira la informática, porque la ingeniería tiene un contenido claro, intuitivo y de sentido común. También tiene un contenido científico con una base matemática. Uno de los cargos en los que siempre he incurrido, justificadamente, es concentrarse en las matemáticas más de lo que a muchas personas les gustaría. Creo que es un poco como la programación. No hay un libro de texto sobre cómo ser un profesor en una universidad, por lo que todos tienen la libertad de encontrar su propia salvación, lo cual disfruté haciendo.

Frana: ¿Qué pasa con esta idea de un "sacerdocio" de la programación? ¿Qué edad tiene esa idea?

Hoare: Bueno, dibujé esa analogía entre los programadores y el sumo sacerdocio en un artículo que escribí sobre el tema. El número de puntos de similitud ciertamente es bastante arcano. Las instrucciones que el sumo sacerdote le da a la persona que lo consulta generalmente tienen la forma de un sinsentido (slash-slash dot-dot: algo u otro) y comparé esto con el mensaje que quería transmitir: que la programación era una profesión y debería desarrollarse como una profesión, y que deberíamos copiar algunas de las prácticas de los profesionales en otras disciplinas. Mantenerse al día con la literatura en el tema, por ejemplo, es una de las tareas que disfruta el profesional responsable. Los programadores en general no lo hacen. Están demasiado ocupados como para leer literatura.

Frana: Usted ha dicho que la especialización es una condición previa para una profesión en toda regla. Entonces, ¿cómo se crean mecanismos que nutren las mentes de propósito general, las personas que pueden saltar intuitivamente los límites de estas especialidades? Knuth habla de convertirse en experto en dos sub-sub-especialidades divergentes.
 
Hoare: Creo que es lo mejor que podemos hacer, sí. Los cursos que planeé en Belfast y más tarde en Oxford incluyen los principales paradigmas de programación: programación funcional, programación de procedimientos. También incluyen diseño de hardware, porque eso requiere el mismo tipo de habilidad intuitiva de inventar algoritmos y técnicas para lograr un objetivo que se aplique en todas esas áreas. Así que uno espera que el alumno obtenga gradualmente la habilidad.

Frana: Knuth argumenta que quizás el dos por ciento de la población es realmente adecuada para la programación profesional. Me parece por las piezas que has escrito que no estás de acuerdo. Todos podemos ser entrenados hasta cierto punto. 

Hoare: si. Condenaría treinta años de mi vida académica profesional si no creyera que se podrían desarrollar algunos talentos. Es extremadamente difícil de medir, es extremadamente difícil de convencer de que con un poco de entrenamiento aquí y sumando diferentes materias se puede construir un profesional completo. Estoy sorprendido y muy satisfecho por el hecho de que muy pocas personas se arrepienten de la educación que se les ha dado. Lo mismo es cierto con la informática. Los graduados dirán, honestamente, que muchas de las cosas que aprendieron nunca pudieron aplicarlas directamente, pero no creo que ninguno de ellos se arrepienta de haberlo aprendido.


Frana: Bueno, estas cosas pueden ser útiles muchos, muchos años más adelante sin que te des cuenta de que es algo que aprendiste hace muchos años.

Hoare: Eso es correcto. Creo que cuando se está buscando una solución a un problema insoluble, debe tener un espacio de búsqueda muy amplio y muy buenos criterios para reducir el espacio de búsqueda. Una educación es ciertamente buena para darle criterios para reducir el espacio de búsqueda, pero no se desea al mismo tiempo suprimir la imaginación, lo que le da el espacio de búsqueda para acortar. De vez en cuando surge una solución milagrosa.

Frana: Parece que son motivaciones competidoras: estructurar las mentes y, sin embargo, ayudarlas a ser flexibles en formas que les permitan desarrollarse. En tu última nota que me enviaste, "Quise decir que la investigación era un oficio, no que la programación lo es". Supongo que esto a menudo se malinterpreta. Si bien la programación es rigurosa, matemáticamente y lógicamente, el proceso de investigación no es tan difícil y rápido.

Hoare: creo que es correcto. En la investigación uno tiene que tener una imaginación mucho más libre. En la programación, después de haber tenido una idea brillante, hay una gran cantidad de disciplina, rutina y construcción de código, que aún requiere una gran habilidad y una gran concentración. Si le preguntas a alguien que realmente está escribiendo código, te dirán que han apagado su imaginación. No quieren escuchar nuevas ideas mientras escriben código.

Frana: Dijiste hace unos momentos que la gente ha sido crítica porque has enfatizado lo matemático. ¿Ves que has enfatizado las matemáticas excluyendo otras cosas?

Hoare: espero no haber excluido demasiadas cosas. Los estudiantes en Oxford y en Belfast habían tenido las oportunidades habituales. De hecho, establecemos tareas que tienen que realizar en el laboratorio práctico, en realidad escribiendo programas y resolviendo problemas. Creo que el desafío del educador es poner cada ejercicio práctico en un contexto teórico para que ilustre una idea de mayor generalidad que el programa particular que se está escribiendo. Es como otros ejemplos: De deben dar ejemplos, pero también debe hacer que el alumno los vea no solo como un conjunto de ejemplos que deben aprenderse, sino como ilustraciones de un principio general que también pueden aplicarse igualmente a cualquier otro caso.

Frana: ¿Y esto es algo que aprendiste en la Universidad de Queen y luego saliste y aplicaste en Oxford?

Hoare: Bueno, recurrí explícitamente a la analogía de un experimento físico o químico, que también debería tener la misma propiedad. Solía dibujar esta analogía de que muchos estudiantes considerarían su entrenamiento en computación como nada más que muchos experimentos, como queda claro en un laboratorio de química. Sus profesores realmente tienen que tratar de enfatizar las fórmulas y hacer que las personas vean que un experimento es para verificar una fórmula en lugar de simplemente hacer que un líquido tenga un color bonito.
 
Frana: bien. ¿Entonces supongo que esto significa que los estudiantes tienen prisa?

Hoare: Sí, los estudiantes son como las otras personas. Están tratando de optimizar sus preocupaciones. Si les dijeras cuál será la pregunta del examen, no perderían su tiempo en conferencias de clase. Aprendí rápidamente que la característica de un buen curso que dura un trimestre es que después de la primera mitad del curso, los estudiantes simplemente no pueden ver de qué se trata, pero al final del curso no pueden ver lo que ellos encontraron más difícil. Por lo tanto, debe elegir un período de tiempo fijo, y si no tiene esa confusión inicial y duda, probablemente no esté enseñando cosas que tiren lo suficiente de sus estudiantes..

Frana: Eso es muy útil. ¿Te nombraron para la cátedra de James Martin cuando fuiste a Oxford?

Hoare: La silla de Oxford era solo una creación reciente cuando llegué. Fue creada para mi predecesor inmediato Christopher Strachey, quien también es un gran nombre como pionero en la teoría de la programación. Murió muy joven. Oxford estableció la cátedra, y luego recibió el nombre original que Strachey le había dado como silla en Computación. El nombre fue cambiado por la generosidad de James Martin, quien hizo una donación a la universidad para financiar una cátedra a su nombre.

Frana: Belfast era un lugar muy difícil para estar en la década de 1970, ¿no?

Hoare: si. Me mudé a Belfast con mi joven familia solo dos semanas antes de los primeros disturbios en Londonderry. Vivimos el grueso de los problemas a principios de la década de 1970. 1972 fue el peor y más deprimente año.

Frana: Por lo que acaban de disculparse ayer.

Hoare: Sí, lo sé. Eso también me tomó por sorpresa. Todavía me interesa y simpatizo con mis colegas y amigos en Irlanda del Norte. De hecho, los visité a principios de este año y lo pasé muy bien.

Frana: He hablado con muchas personas de la comunidad de desarrollo de software, tanto de arriba como de abajo, acerca de usted para determinar la opinión popular sobre su trabajo. Lo que me dicen una y otra vez es que en algún momento a fines de los ochenta o principios de los noventa, usted suavizó su posición en la industria adoptando algunas de las trampas teóricas de la informática. Cuando leo la literatura no tengo esa percepción en absoluto. Te encontré escribiendo sobre cómo la brecha es tolerable, pero trabajemos para cerrarla o mantener las cosas para que sigan funcionando en paralelo.

Hoare: Me gusta tu segunda interpretación. No puede construir puentes simplemente concentrándose en un lado de una división. También debe ver los problemas que surgen en el otro lado, pero puede elegir la cantidad de atención que desea prestarles. Creo que la ciencia, la ingeniería y la industria funcionan bien juntas si es posible reconocer las diferentes preocupaciones y las diferentes escalas de tiempo a las que informan los diferentes jugadores en el juego. Todavía me complace enfatizar el deber, la característica definitoria del científico puro, probablemente encontrado trabajando en universidades, que se comprometen absolutamente a objetivos especializados, a buscar la manifestación más pura de cualquier posible fenómeno que estén investigando, a crear laboratorios. que están mucho más controlados de lo que jamás encontrarías en la industria, e ignorar cualquier restricción impuesta por, por así decirlo, el realismo. Más abajo en la escala, las personas que entienden y quieren explotar los resultados de la ciencia básica tienen que hacer mucho más trabajo para adaptar y seleccionar los resultados, y combinar los resultados de diferentes fuentes, para producir algo que sea aplicable, útil y rentable. en una escala de tiempo aceptable. Siempre he descubierto que cada vez que busco en un entorno práctico encuentro un problema teórico nuevo y fascinante. No siempre sucederá, por supuesto, pero la investigación es más emocionante cuando de repente encuentras una nueva dirección para correr. Dónde encontrará esa nueva dirección, no lo sé. Si te concentras demasiado en las cosas con las que estás completamente familiarizado, no lo encontrará. Entonces, haga lo extraño, lo quijotesco, vaya a su banco local y vea cómo están usando las computadoras, cualquier cosa, pero debe ser quijotesco, de improviso, al azar, y luego piense en ello. Básicamente, está dando un paseo entre las flores, por así decirlo.

Frana: Otro comentario que haces que parece surgir con bastante frecuencia, donde dices: "¿Cómo se volvió tan confiable el software sin pruebas?" Una pregunta retórica aquí, pero ¿se puede usar para defender la falta de rigor?

Hoare: Creo que si miras en el artículo verás una serie de razones por las cuales la industria realmente hace mejor para concentrarse en los resultados de la investigación completa en lugar de la investigación que se está llevando a cabo actualmente. Lo peor de todo es confiar en los resultados de la investigación que acaba de comenzar. Y este ha sido un error tan generalizado en la financiación de la investigación - un error que yo mismo he cometido - que la iniciativa de investigación se anuncia y se financia sobre la base de una motivación política, y luego se supone que la Industria interviene y ayuda en el trabajo.

CINTA 2 (Lado A)


Pero los ingenieros industriales en realidad no quieren usar nueva tecnología. Siempre es un riesgo. Entonces tienes al científico, cuya motivación principal es descubrir tanta tecnología nueva como sea posible, y al ingeniero, cuya motivación principal es evitar usarla en la medida de lo posible. Quieren salirse con la suya con algo ya probado. Sería una locura hacer algo nuevo, si pudiera evitarlo.

Frana: Su premio Turing fue otorgado en 1980. ¿Ha habido un cambio dramático en la dirección de su investigación desde esa ocasión?

Hoare: Creo que los temas generales se mantuvieron cercanos. Para 1980, el intento principal de construir una definición axiomática bastante completa de un lenguaje de programación secuencial estaba, bueno, en el saco. Yo adopté el desafío de aplicar las mismas técnicas a la programación concurrente. Fui muy explícito conmigo mismo sobre lo que pretendía hacer: reproducir para la programación concurrente el concepto y la comprensión que Dijkstra nos había dado en su libro sobre la Disciplina de la programación, y su soporte técnico en términos de precondiciones más débiles. Me mudé a Oxford y a la colaboración con algunos estudiantes muy buenos antes de comenzar a ver cómo se podía lograr ese objetivo.

Frana: Entonces hay continuidad.

Hoare: De hecho, sí. Y desde entonces he estado tratando de aplicar la misma técnica más profundamente en la teoría y con diferentes aplicaciones, diferentes tipos de lenguajes de programación.

Frana: Ahora es algo inusual que alguien tan profundamente teórico como usted haya tenido tales conexiones con la industria a lo largo de los años. Tuve la oportunidad de hablar con Dijkstra el verano pasado en Austin, y él habló sobre el "trabajo de curso industrial indecente" que a menudo era parte del plan de estudios en Texas y en otros lugares. Sin embargo, parece haber encontrado una salida a ese enigma, trabajando primero con IBM y ahora con Microsoft. Se te ha otorgado un paso bastante libre entre estos mundos. ¿Hay una salida? ¿Hay alguna forma de integrarse?

Hoare: creo que es una cuestión de reconocer que hay un espectro y elegir un punto en él. He sido programador de la industria, y Edsger también. Trabajó para Burroughs durante varios años.

Frana: eso es correcto. Consultoría principalmente.

Hoare: Pero Edsger es mi modelo cuando pienso en el científico puro, y en la importancia absoluta de que nuestra sociedad apoye a una buena proporción de científicos que trabajan en el extremo más puro posible del tema. Con razón dice que es el atributo del científico separar las preocupaciones, hacer que todo lo que sea posible sea irrelevante y concentrarse en un solo tema en cualquier momento. Es tarea del científico perseguir la verdad absoluta, la pureza absoluta. Él no quiere detenerse en 99.9 por ciento puro. Él quiere ir a por todo o nada. Edsger se niega a considerar las preocupaciones de la administración o incluso las preocupaciones financieras. No son asunto de un científico. Tengo un gran respeto por las personas que pueden tener en cuenta esas preocupaciones y aún así entender y aplicar los resultados de la investigación científica pura.

Frana: Bueno, tu experiencia personal fue muy diferente. Tuvo un problema de administración muy temprano para superar en el sistema de software Mark II.

Hoare: si.

Frana: ¿Leíste el libro de Fred Brooks 'The Mythical Man-Month'?

Hoare: Por supuesto, los problemas de Fred Brooks surgieron después de los míos, pero sí, de hecho leí el libro. Simplemente resonó, obviamente: consolar que tales cosas le sucedan a otras personas. Recuerdo que después del fracaso del proyecto del sistema operativo Elliott, leí descripciones preliminares de OS / 360, y me dije a mí mismo: 'Wow, estas personas deben ser muy inteligentes, ¿cómo podrían hacerlo y yo no?' descubri que ellos tampoco podían.

Frana: ¿También agregaste mano de obra a un programa tardío, lo hiciste más tarde?

Hoare: Sí, creo que debo haberlo hecho. No fue una gran cantidad de mano de obra.

[pausa]

Frana: Sé que este no ha sido el objetivo principal de su investigación - razonando bajo incertidumbre - pero que lo ha estado estudiando de vez en cuando desde su educación inicial.  

Hoare: si. Estudié probabilidad como un pasatiempo en la escuela, y lo seguí desde un punto de vista filosófico como un medio para explicar el fenómeno del razonamiento incierto. De hecho, pasé un año estudiando estadísticas para una calificación en Oxford.

Frana: ¿Eso fue con Leslie Fox entonces?

Hoare: No, el curso de estadística fue con Norman Bailey. Mientras estaba en ese curso asistí a un curso de programación de una semana impartido por Leslie Fox.

Frana: ya veo.

Hoare: Creo que desde que descubrí las computadoras y la programación, he vuelto al ideal filosófico original de la certeza, logrado aparentemente por razonamiento matemático, y me concentré mucho en ese aspecto de la informática. Pero reconozco que la probabilidad se está volviendo cada vez más importante en la informática, tanto porque proporciona formas rápidas de obtener soluciones a problemas que de otro modo no se podrían resolver, y porque cuando las computadoras están conectadas juntas en una vasta red, como lo son hoy, suceden muchas cosas por las cuales solo las consideraciones probabilísticas nos pueden dar una base para la comprensión.

Frana: ¿Te has alejado de eso en el pasado por una razón específica, o simplemente no es tu especialidad?

Hoare: Simplemente no es mi especialidad.

Frana: ¿Estabas leyendo cosas como Leonard Savage, la idea de probabilidad personal, probabilidades subjetivas?

Hoare: En general, me he mantenido alejado de consideraciones de razonamiento impreciso. Y porque creo que esto es quizás una justificación, es un patio de recreo para los charlatanes. Si volviera al razonamiento incierto, trataría desesperadamente de hacer que las probabilidades funcionen porque esa es una base muy segura para lidiar con la incertidumbre.

Frana: Si cuantificas la incertidumbre, ¿qué tienes? ¿Es a eso a lo que estás reaccionando?

Hoare: Creo que sí. La probabilidad es una buena medida abstracta de incertidumbre y tiene un buen cálculo que lo respalda, y que permite hacer predicciones que luego se pueden probar. De lo contrario, no he encontrado un enfoque convincente para un estudio científico de la incertidumbre. No creo que sea peor la incertidumbre por ese motivo. De hecho, cuanto más uno se dedica a la formalidad y las matemáticas y las computadoras, más tiene que admirar la forma en que las personas realmente lo hacen. Por ejemplo, me había dado por vencido con el diagnóstico informático en medicina, tan pronto como me di cuenta de lo que hace un médico promedio cuando entras en la consulta: Se dice a sí mismo: "Sé lo que tienes", y no ha hecho una sola pregunta: algo relacionado con la forma en que te ves, la forma en que caminas, es indefinible.

Frana: ¿Qué te pareció la inteligencia artificial?

Hoare: No me sentí muy atraído por la inteligencia artificial en general. De alguna manera he estado en lo cierto, y de alguna manera me he equivocado. Creo que se ha logrado un enorme progreso, hacia objetivos de inteligencia artificial como, digamos, traducción automática de idiomas, ahora que las computadoras son mucho más rápidas y más grandes de lo que eran. Ese es un ejemplo interesante debido a su parte en mi propia introducción a las computadoras. Cuando era un estudiante graduado en la Universidad Estatal de Moscú, recibí una carta del Laboratorio Nacional de Física que me invitaba a postularme para un puesto como oficial científico superior para trabajar en un proyecto que tenían para programar la computadora Pilot Ace para traducir del ruso al Inglés. Habían oído hablar de mí como un hablante ruso y pensaron que podría ser útil para ellos. Mientras estaba en Moscú, pasé un poco de tiempo conociendo gente que trabajaba en la traducción automática. Lo pensé un poco y llegué a la conclusión de que no iba a ser posible. Así que no quise el trabajo ofrecido en el Laboratorio Nacional de Física. En cambio, tomé un trabajo con Elliot Brothers, donde tuve la oportunidad de trabajar en un lenguaje artificial, ALGOL 60, y escribir un traductor para eso, que afortunadamente funcionó.

Frana: Hoy, estos investigadores de MT parecen estar interesados en el procesamiento del lenguaje natural. Es decir, lo que intentan hacer es tomar todo lo que se ha traducido y luego emparejarlo. ¿Es así como lo entiendes?

Hoare: Creo que la clave resulta ser muy diferente de todo lo que cualquiera estuviera trabajando en esos primeros días, cuando se pensaba que era una cuestión de algoritmos. La forma en que funciona, y también en otras áreas, es en términos de capacidad de almacenamiento masivo, la capacidad de almacenar grandes cuerpos y luego hacer una comparación de patrones estadísticos para obtener una respuesta de calidad cada vez más razonable. Realmente sugiere que esta puede ser la forma en que funciona el cerebro, porque aprender y entrenar con el ejemplo parece mucho más intuitivamente razonable que ejecutar de alguna manera un algoritmo por programa. Eso no parece ser lo que hace el cerebro en absoluto.

Frana: ¿Has estado pensando en esto últimamente entonces?

Hoare: Encendido y apagado, sí.


Frana: Hablando de memoria limitada y velocidades de ejecución, ¿ha leído la tesis "La evolución del diseño de software" de David Koepke, un estudiante de la Universidad de California en Northridge? En el prefacio dice que se contactó con usted y le hizo algunas preguntas. David adjuntó, en un apéndice, una carta que recibió de usted. Concluye: ‘La memoria limitada y la velocidad de ejecución de las computadoras de los años 50 y principios de los 60 obligaron a los programadores a concentrarse en un objetivo de diseño: la eficiencia. Los programadores tuvieron que desarrollar trucos ingeniosos, como modificar su propio código, para superar las limitaciones de la computadora. Este entorno de hardware restrictivo tuvo un impacto negativo en el diseño y resultó en programas que eran menos claros ". ¿Estaría de acuerdo?

Hoare: Oh, por supuesto que sí. Pero creo que a medida que los programas se hacen más grandes, el programador sensato limitaría los bits realmente difíciles a áreas bastante pequeñas en el código, y buscaría preservar la estructura y la anotación en la gran mayoría del código que está escrito.

Frana: Una de las ideas que imparte es la posibilidad de sobre-diseñar el código. ¿Hay algún punto en el que puedas tener casi demasiada memoria?

Hoare: Ciertamente, hay rendimientos decrecientes, pero los rendimientos que no disminuyen son lo suficientemente grandes como para compensarlo. El fenómeno del código heredado es que nadie elimina nada y, por lo tanto, un poco como el genoma en realidad, probablemente haya mucha basura allí, que nadie se atreve a eliminar porque nadie sabe si en algún lugar, de alguna manera, podría estar haciendo algo útil. En los viejos tiempos solíamos usar instrucciones del código como constantes si resultaban ser las que queríamos. "Obtenga esta instrucción del almacén, oculte los cinco bits inferiores y úsela".

Frana: Una vez más, una cita de la tesis de David Koepke: 'Los programas ya no se ven como una jerarquía secuencial de procedimientos (acciones) que pasan datos arriba y abajo de la jerarquía, sino más bien como un conjunto de objetos (datos y acciones) que permanecen en existencia , ejecutar simultáneamente si es posible e interactuar entre ellos mediante el envío de mensajes. "¿Eso encapsula el diseño del software?

Hoare: Creo que expresa una idea muy, muy importante, sí. Refleja el desarrollo que hice en mi propio progreso científico, al pasar de la construcción secuencial de la jerarquía de códigos hacia la orientación a objetos y la concurrencia.

Frana: ¿Hay un tercer turno del que estamos a punto?

Hoare: ¿Me lo dices?

Frana: no lo se. Creo que la programación distribuida es donde estamos ahora. Creo que esta orientación a los objetos todavía es muy apreciada, y la gente solo ahora se da cuenta de que es honesta.

Hoare: Sí, eso es correcto. Creo que el advenimiento de la Web y la posibilidad de explotar realmente la informática distribuida se considera ciertamente un nuevo impulso y avance en Microsoft. La informática distribuida y la concurrencia han sido temas de investigación durante un tiempo increíblemente largo. Han recibido bastante apoyo de las agencias de financiación de la investigación desde principios de los años ochenta. Todos lo han visto venir. Ha llevado un increíblemente largo tiempo en venir. Y ciertamente todavía no está aquí. Creo que los usos prácticos de la concurrencia todavía tienen que explotar.

Frana: ¿La informática todavía está muy lejos de poseer el marco que usted y otros han imaginado? McCarthy en particular ha sido muy directo al decir que tal vez estamos más lejos que nunca. ¿No te sientes así?

Hoare: Creo que podemos estar haciendo un buen progreso, y la meta aún puede estar retrocediendo. Eso no es imposible. De lo contrario, el sujeto está muerto cuando nos ponemos al día. Lo que sucedió es que los programadores prácticos han utilizado cualquier comprensión que hayan adquirido, o los teóricos les han ofrecido, para aumentar la complejidad. Por lo tanto, los lenguajes de programación en general son mucho más complicados de lo que solían ser: la orientación a objetos, la herencia y otras características todavía no se están pensando realmente desde el punto de vista de una disciplina coherente y científicamente bien fundada o una teoría de exactitud. El postulado original, que he estado persiguiendo como científico toda mi vida, es que uno usa los criterios de corrección como un medio para converger en un diseño de lenguaje de programación decente, uno que no establezca trampas para sus usuarios y otros en los que el diferentes componentes del programa corresponden claramente a diferentes componentes de su especificación, por lo que puede razonar compositivamente al respecto. Los lenguajes de programación en general no han prestado mucha atención a este aspecto. Tienden a definirse únicamente en función de lo que hace la máquina cuando ejecuta el programa y, a menudo, también con un nivel de granularidad bastante bajo: los accesos de almacenamiento individual. Todavía creo que tenemos que transmitir el mensaje. Las herramientas, incluido el compilador, deben basarse en alguna teoría de lo que significa escribir un programa correcto. Ese mensaje es uno que sigo predicando. Microsoft es un buen lugar para predicarlo.

Frana: También has advertido que puede haber consecuencias desastrosas. ¿Alguna vez ha testificado en un juicio penal o civil donde el software puede haber fallado?

Hoare: No. Afortunadamente me he ahorrado eso, porque creo que si uno estuviera dando testimonio tendría que admitir que el estado del arte, tal como se entiende en general, no incluye el uso de técnicas de prueba en la programación. Se podría argumentar que no es razonable, y un tribunal de justicia debería hacer cumplir eso. La ley tiene que seguir el ritmo de la percepción pública, la aceptación pública y los medios de detección, debe ser realista. He dejado de tratar de poner los pelos de punta a la gente contando historias terribles de lo que podría pasar si el software falla. Creo que es ineficaz. Creo que el software se ha equivocado lo suficiente como para que las personas se den cuenta de que es costoso cometer errores. Algunos de los virus recientes han sido extremadamente costosos. El problema es que cuando las cosas van mal, siempre hay más de una razón para ello. Siempre podría haber habido más de una forma de prevenir el desastre. En última instancia, siempre se puede decir: "Si nuestro sistema de prueba y verificación hubiera incluido la prueba que reveló este error, el programa nunca habría entrado en producción".


CINTA 3 (Lado A)

Hoare: hay otras medidas que uno puede tomar para reducir la probabilidad de tales errores. Hay otros más fáciles que comenzar a usar pruebas formales en la verificación del software. No se puede culpar a las personas prácticas por hacer las cosas más fáciles antes. Así que tiendo a ir más atrás que cuando escribía sobre cómo el software se volvió tan fiable. Considero la teoría como algo que fundamenta las herramientas que se pueden utilizar para demostrar la fiabilidad del software. Los programadores no la van a usar directamente, a no ser que las herramientas les ayuden a usarla.


Cuando era académico deploraba este resultado. Como académico y maestro, quieres que la gente entienda las cosas y las aplique. La posibilidad de que la computadora lo haga todo parecería ser una evasión. Ya no me siento así. Creo que en realidad si tomas la analogía con otras áreas de la ingeniería, y cada vez más de la ciencia e incluso de las matemáticas, puedes ver que las personas no tienen que aprender la gran cantidad de fórmulas que solían aprender. En cambio, tienen que aprender a usar la computadora de manera efectiva. Creo que esto les libera para comprender los conceptos y los fundamentos mientras aprenden la mecánica de la aplicación de la teoría. Creo que ya ningún ingeniero hace su propio análisis estructural. Los ingenieros deben comprender los conceptos de análisis estructural para poder utilizar la computadora de manera efectiva. Tienen que entenderlo más si quieren hacer innovaciones, no solo estar limitados por las herramientas. Hasta que no tengamos las herramientas, los compiladores, y tal vez incluso los lenguajes que incorporen las teorías y las hagan aplicables, creo que los programadores tendrán que hacerlo lo mejor que puedan con su intuición y su educación tal como es.

Frana: Esos son comentarios realmente notables. No creo que las personas que te conocen solo desde tus días de "pre-Turing" esperen que digas algo así:

Hoare: He decepcionado las expectativas de la gente. Tengo que decir que es un fenómeno bastante común. Me gustaría enfatizar que no considero que esto invalide los entusiasmos e incluso los entusiasmos equivocados que tenía cuando era más joven. Quiero que los jóvenes de estos días sean igualmente idealistas y entusiastas. Espero que muchos de ellos sean naturalmente entusiastas. Desafortunadamente, muchas personas tienden a sentir, como yo, que el valor de su trabajo fue degradado por el hecho de que no se estaba aplicando. Muchas personas no estaban dispuestas a intentar aplicarlo, o incluso creer que algún día sería aplicable. Lo que me gustaría hacer ahora es decirle a la gente que esto no es así. Tu trabajo es esencial. Va a ser aplicado. Todo esto es tiempo futuro, pero ciertamente Microsoft lo necesita. Necesitan poder controlar el fenómeno del error, particularmente cuando nos movemos hacia la concurrencia. Debes seguir investigando estas cosas y debes seguir enseñándolas, porque necesitamos que las personas lo entiendan. Y estas son las personas que van a liderar la profesión en el futuro.

Frana: Entonces, de nuevo, estás facilitando una situación similar a la que estableciste en el pasado, cuando te dijiste a ti mismo: "Sé que lo que estoy haciendo ahora no verá la luz en la industria durante treinta años , pero al final verá la luz del día" Estás aconsejando a los investigadores jóvenes que aborden las cosas de la misma manera.


Hoare: si.
 
[pausa]

Frana: Una cuarta razón por la que estoy aquí es la interpretación histórica del código. Conservar nuestro patrimonio de software es algo de gran interés en la historia profesional de la informática. Ha habido un gran debate, en realidad, que se ha extendido por una década o más, entre aquellos que ven el código real como algo que deberíamos trabajar muy seriamente para preservar, de la misma manera que hemos preservado parte del hardware. Hay otros en el otro lado de la cerca que dicen que esto es un tremendo desperdicio de recursos. Sería maravilloso preservar el código, pero al ser un mundo de recursos limitados, deberíamos considerar hacer otras cosas. Quizás, dicen estas personas, es más importante tener un video de alguien usando un sistema de software que preservar el código subyacente. Curiosamente, en esta conferencia a la que asistí en la Universidad de Strathclyde, hubo un discurso de apertura de Wendy Chun. Ella dijo que el software es ideología, y que todas las ideologías pueden reflejarse en el software. Dijo, con bastante elocuencia que podría agregar, que "tanto el software como la ideología intentan mapear lo inmaterial en términos materiales". Pero aún es muy difícil convencer a los historiadores de que conserven estas cosas.

Hoare: Bueno, ¿cuáles son los costos de estas colecciones? Quiero decir que la cantidad de bits involucrados es minúscula.

Frana: Creo que los historiadores están pensando en cambio en los costes que generarían los historiadores accediendo realmente a este tipo de material.

Hoare: Bueno, eso es realmente cierto. Uno tiene que imaginar una situación en la que el arqueólogo del futuro quiera descubrir cómo lograron obtener algo útil de esas primeras máquinas. Es inconcebible que la primera computadora en la que trabajé cuesta en moneda moderna medio millón de libras británicas. Funcionó a dos mil operaciones por segundo y tenía veinte mil bytes de almacenamiento. Será inconcebible saber cómo usamos estas máquinas, de la misma manera que ahora no sabemos cómo se construyeron las pirámides. Entonces, ¿no te imaginas el programa de televisión del futuro preguntándose cómo se hizo? Y si puedes imaginar eso, entonces creo que como archivero tienes que guardar el código. Hay algo sorprendente sobre el sistema THE de Dijkstra. Quizás haya algo sorprendente sobre los primeros programas que escribimos. Son tan pequeños ¿Como lo hice? Hice algunas cosas muy buenas - también todos nosotros -, algunas muy inteligentes para unas cosas tan pequeñas como eran. Por ejemplo, para que los saltos hacia adelante funcionen correctamente, nuestro compilador ALGOL leía  el código intermedio al revés desde su salida en cinta de papel. Esa tecnología es bastante irrelevante ahora, pero fue bastante fantástica entonces. ¡Creo que deberías pensar detenidamente sobre qué bits de software, o muestras representativas, vais a conservar, o te acusarán de haber destruido restos arqueológicos!


Frana: No creo que nadie esté minimizando la importancia del código. Puede ser, en mi opinión, que los historiadores simplemente no son programadores. Quizás un obstáculo es esta idea de que necesitas poder emular el código.

Hoare: Eso no es problema. Tendría que mantener también las descripciones de la máquina. En aquellos días las máquinas eran bastante simples, y las personas se esforzaban mucho para completar las descripciones. El proyecto de escribir un emulador para una máquina como esa es de pregrado. Ciertamente puede obtener copias de trabajo que continuarán trabajando en el futuro indefinido. Creo que la Computer Conservation Society se está dando cuenta de que el software es el legado intelectual duradero, y se debe permitir que el hardware decaiga. Dijkstra estaría de acuerdo con eso.
 
Frana: Oh, estoy seguro de que lo estaría. La razón por la que le pregunto sobre todo esto es porque en su artículo, "Teorías de la programación", escribe sobre el software como un artefacto hecho por el hombre. Usted toma una visión del software muy antropológica, centrada en el ser humano, casi cultural. Usted argumenta que es como cualquier otra cosa que la humanidad produce, como el arte, la arquitectura o la literatura. Me pregunto si hay lugares obvios donde podemos mostrar cómo el software es un reflejo de la sociedad y la cultura o si la cultura se ha incidido de alguna manera en el software. ¿Hay ejemplos que se te ocurran?

Hoare: si. Ocasionalmente, he pensado en analogías políticas y sociológicas de sistemas operativos que intentan administrar usuarios o tareas de usuario de manera equitativa, o al menos no sujeta a abuso. Hay toda una analogía que sentí que podía percibirse muy lejos. Supongo que el movimiento de inteligencia artificial es uno que ha tenido un gran impacto cultural. La analogía entre la mente y la máquina realmente afectó la forma en que las personas piensan acerca de las mentes, probablemente de manera probablemente incorrecta. Pero fue, y hasta cierto punto sigue siendo, la analogía de la mente como un mecanismo en el que la gente tiende a pensar. Es comparable al descubrimiento newtoniano de la fuerza de gravedad que afecta la forma en que las personas piensan sobre los objetos materiales en el mundo real. Las ideas de determinación científica, por ejemplo, se inspiraron en los éxitos de las predicciones astronómicas, y en realidad son bastante generalizadas en Occidente. Es realmente una expectativa poco realista, pero sin embargo, es parte de una cultura compartida es creer que la ciencia, en principio, puede predecir mucho más de lo que puede en la práctica. El movimiento de inteligencia artificial inspira el ideal de que una computadora puede hacer lo que un ser humano puede hacer, y esto inspiró una investigación fructífera en el cerebro y el comportamiento.

Frana: Creo que los sociólogos, en particular, nos han alejado del resto de la analogía al explorar cosas como la 'cualidad necesaria para ser gato' ['cat-ness']. En lugar de comparar humanos y máquinas, han estado comparando perros con seres humanos, o gatos con seres humanos. Si de alguna manera no se pueden poner en la misma categoría, argumentan, ¿cómo esperas traer una máquina y ponerla en la misma categoría?

Hoare: Bueno, la extraña paradoja de una inteligencia artificial es que resultó ser bastante fácil hacer lo que la gente considera algo altamente inteligente, como jugar al ajedrez, mientras que que es casi imposible de modelar en un ordenador la interacción de un calamar cuando ve amenazado. Parece que el calamar de alguna manera puede hacer cosas que las computadoras simplemente no tienen idea de cómo hacer.

Frana: La otra cara de la moneda es: ¿cómo acercamos las humanidades y la informática? Noté que siempre alentaste a los estudiantes de idiomas a inscribirse en ciencias de la computación. Supongo que eso también se aplica a los filósofos e historiadores, aunque hay muy pocas de estas personas en el personal de las principales compañías de software como Microsoft. 

Hoare: Bueno, obviamente ahora hay tantos graduados en ciencias de la computación que superarán en número a otras disciplinas en los mejores departamentos de computación. Si tomas números absolutos, probablemente tengas tantos filósofos como nunca antes. Creo que hay que considerar esto como excepcional. No pasó mucho tiempo enseñando un curso introductorio de programación en Belfast hasta que me dí cuenta de que en una clase de cuarenta había cuatro, o tal vez incluso más, que nunca escribirían un programa. Simplemente eran psicológicamente incapaces de escribir un programa. Uno de ellos era ciego izquierdo-derecho. No podía distinguir la izquierda de la derecha. Enseñarle que la variable que desea cambiar tiene que escribirse a la izquierda del signo igual y la expresión debe escribirse a la derecha, fue una tarea desesperada. Esta persona nunca podría escribir un programa. Pero podría haber sido un muy buen poeta, muy buen filósofo, historiador o lo que sea.

Frana: me acuerdo de la Iglesia Católica Romana. La Iglesia a menudo busca sacerdotes en lugares extraños. Les gusta encontrar personas con antecedentes "inusuales", tal vez buscan científicos informáticos, y luego los convierten en sacerdotes que pueden salir y explicar las cosas de una manera que atraiga a los informáticos. La informática también parece premiar las rutas no tradicionales para adquirir experiencia. Hay todo tipo de estereotipos de piratas informáticos que entran en el campo con un conjunto bastante extraño de experiencias pasadas. ¿Ha pasado el tiempo donde eso es posible? Usted mencionó las ventajas de mirar las operaciones bancarias en el momento.

Hoare: Bueno, como científico, estaba sugiriendo que de vez en cuando uno debería tener miradas quijotescas para experimentar. Como persona, creo que esto es muy gratificante. En lo que respecta a los programadores, como profesor de programación, investigador y teórico, espero que comencemos a construir un conjunto de conocimientos que se reconozca como una base esencial para las personas en el campo. Por otro lado, como usted señala, todavía hay un amplio margen para el llamémoslo genio no instruido. O lo puede llamar "hacker". De alguna manera pueden ver la forma en que funcionará la computadora y simplemente ir por ella. Tienen un papel que desempeñar. Creo que encontrarás una gran proporción de esas personas en las compañías de juegos de computadora. Pero entonces, ya ves, los juegos son obviamente un área donde se necesita algún tipo de talento artístico para que tengan éxito. Para proyectos de equipo, para equipos que trabajan en productos heredados, uno esperaría que podría ser más útil tener una base sólida en los conceptos básicos del tema. Desea atraer a personas que son quizás menos entusiastas, más meticulosas, más disciplinadas y que comparten una herencia cultural con sus colegas. Este todavía no es el caso. En Microsoft y en otros lugares, es perfectamente razonable que personas ajenas y sin experiencia vengan y hagan una contribución muy rápida al producto y a los programas. No deseo ser exclusivo. Por otro lado, desafía nuestro sentimiento de satisfacción por los logros de la enseñanza cuando esas personas sin supervisión nos hacen sentir que lo que enseñamos no es realmente necesario.


Frana: ¿Y por qué es eso?

Hoare: Bueno, creo que lo que sucedió en otras disciplinas es que se vuelve obligatorio, sea necesario o no. Los médicos tienen que aprender los nombres latinos de los huesos del cuerpo o tal vez no pueda obtener su licencia para practicar. El examen es lo que define su competencia. Con suerte, el examen está altamente correlacionado con la competencia: su competencia para hablar con sus colegas y su competencia para mantenerse al día con los desarrollos en el campo. Ahora, esas son dos competencias que transmite la educación. No están disponibles para el genio sin tutor, y que decaen cuando se enfrenta a problemas complejos donde otras habilidades son necesarias.

Frana: ¿Crees que la informática necesita un conjunto de exámenes muy pragmático?

Hoare: Mi mente está dividida: me gusta la emoción de hacer cosas nuevas. Me gusta el hecho de que las personas pueden entrar con nuevas ideas. Lamento el hecho de que tan pocas personas realmente tengan una base teórica que en otras profesiones sea obligatoria. Me temo que nuestro tema será más aburrido cuando las cosas estén estandarizadas.

Frana: Y los que estudian el código heredado encajan ...

Hoare: Sí, no es tan interesante. Tienes que obtener tu satisfacción de otras cosas además de '¡Caramba, mira lo que hice que haga la computadora!' Debes comenzar a obtener tu satisfacción escribiendo código ordenado y bien documentado, independientemente de si es realmente más rápido o más eficiente o más confiable que un código irregular y pésimo. Creo que una educación en informática puede hacerse interesante y fascinante. He conocido a muchos profesores que pueden hacerlo. Puede interesar no solo a los estudiantes de pregrado, sino que también puede interesar cada vez más a los programadores profesionales en la profundización su propio oficio desde un punto de vista académico, desde un punto de vista científico. Una de las razones por las que me mudé de Belfast a Oxford fue para tratar de establecer este principio: puedes enseñar informática teórica interesante y útil a programadores experimentados con cinco a quince años de experiencia. Me di cuenta de que en Belfast la población no era lo suficientemente grande como para impartir un curso de maestría como ese. Unos años antes de retirarme, tuvimos la oportunidad de comenzar un curso de este tipo en Oxford, y tuvimos algunos maestros muy buenos que lo habían estado haciendo durante varios años. Lo han estado haciendo con enorme éxito.

CINTA 4 (Lado A)

Hoare: Los programadores de IBM y muchas otras compañías han pasado y obtenido títulos de maestría en ingeniería de software gracias a este Instituto.

[pausa]

Frana: ¿Tienes un grupo bien definido aquí con el que trabajas?

Hoare: Actualmente, me he convertido en un consultor de investigación en lugar de un investigador activo. Enseñé bastante a los investigadores en Cambridge que están trabajando en temas teóricos o utilizando métodos teóricos para trabajar en temas prácticos. También enseñé a desarrolladores e investigadores en Redmond. Creo que es importante que no intente competir con ellos y que mantenga una visión amplia de lo que está sucediendo. Ocasionalmente, uno puede poner a una persona en contacto con otra persona que está trabajando en algo que es relevante.

Frana: ¿Y ese es el papel de un investigador senior en Microsoft?

Hoare: si. Es un papel que escuché cuando visité el Cambridge Research Laboratory hace un par de años, justo antes de unirme. De hecho, fue esta charla la que me inspiró a firmar en la línea punteada. Sí, aún queda mucho por hacer a medida que uno envejece. La informática ha prescindido de sus ciudadanos mayores, por así decirlo, y es un papel que la gente puede cumplir sin necesidad de retenerlos, gracias a una inteligencia tan práctica como la de los jóvenes, a los que todavía son muy buenos.

Frana: ¿Hay alguna conexión entre Oxford y Cambridge? ¿No es verdad?

Hoare: los departamentos de informática en Oxford y Cambridge tienen enfoques muy diferentes para todo. En general, las universidades se mantienen solas. Los departamentos universitarios no se vinculan con otros departamentos en el mismo tema, de ninguna manera muy fuerte. Hasta que Oxford reclute personas de Cambridge, y viceversa, veremos una cultura diferente en los dos lugares.

Frana: ¿Cuál es tu plan quinquenal para el futuro?

Hoare: Creo que tratar de mejorar la moral de la informática académica es muy importante.

Frana: Lo que percibes es, creo, bastante bajo en este punto.

Hoare: He sentido que era bajo, al menos en Gran Bretaña, más o menos cuando me retiraba. Microsoft está adoptando una visión a largo plazo de la investigación. Creo que estamos en una buena posición para alentar a las universidades a adoptar una visión aún más a largo plazo. Otra cosa que puede hacer la persona de la tercera edad es proponer desafíos para identificar áreas de investigación interesantes, áreas en las que quizás un poco de colaboración produzca resultados a largo plazo a mayor escala.

Frana: ¿Estás dispuesto a compartir los detalles de alguno de estos desafíos?

Hoare: Oh si. Mi desafío favorito se llama "compilador verificador". Es un compilador que toma un programa, junto con sus anotaciones y especificaciones, y utiliza técnicas matemáticas para garantizar que uno sea coherente con el otro.

Frana: Has escrito un poco sobre eso.

Hoare: si. McCarthy propuso originalmente la idea a principios de la década de 1960. Más tarde, Bob Floyd dio los primeros pasos hacia él cuando escribió sobre la asignación de significados a los programas. Tal vez ahora estamos por fin en un estado en el que uno puede comenzar a pensar en esto como un objetivo realista. Conozco a las personas en el mundo que podrían trabajar juntas, y acepto usar la palabra "compilador de verificación" para describir un objetivo de colaboración. Creo que es importante alentar otras áreas donde un gran desafío de este tipo podría ser productivo.

Frana: Finalmente, ¿puedo preguntarte por tu esposa Jill? ¿Cómo está ella y continúa sus intereses? ¿Ella también está afiliada de alguna manera con Microsoft?

Hoare: No, no Recientemente le compramos una computadora y ella disfruta enviando correos electrónicos y ocasionalmente buscando cosas en la red, almacenando fotografías y un catálogo de plantas de jardín.

Frana: ¿Y tú también eres jardinero?

Hoare: hago algunas excavaciones. Tenemos un gran jardín, así que de hecho le pago a la gente para que también haga la mayor parte de la excavación. Corto el césped y lo disfruto.

Frana: Muchas gracias Tony. He llegado al final de mi lista de preguntas. Aprecio tu tiempo.

Hoare: excelente.

FIN DE LA ENTREVISTA