Barbara Liskov - A.M. Turing Award 2008
From: https://amturing.acm.org/interviews/liskov_1108679.cfm
Transcription (english) pdf: https://amturing.acm.org/pdf/LiskovTuringTranscript.pdf
Traducción de la transcripción al Castellano:
Entrevista con Barbara Liskov: BL
Galardonada con el Premio A.M. Turing en 2008
Entrevista realizada en el MIT el 20 de Abril de 2016
Entrevistador: Tom Van Vleck: TVV
Hola, soy Tom Van Vleck, y hoy tengo el honor de entrevistar a la profesora Barbara Liskov, ganadora del Premio ACM Turing 2008. Hoy es 20 de abril de 2016.
- Para empezar, ¿por qué no nos cuenta un poco sobre su educación, dónde vivió y cómo ingresó al negocio?
Crecí en San Francisco. En realidad nací en Los Ángeles, así que soy nativa de California. Cuando era pequeña, definitivamente no se consideraban las matemáticas y las ciencias como algo pudiera interesar a una joven. De hecho, en esos días, el mensaje que se recibía era que se suponía que te ibas a casar y tener hijos y no tener un trabajo. Sin embargo, mis padres siempre me animaron a tomar en serio lo académico. Mi madre se graduó de la universidad al igual que mi padre, por lo que se esperaba que yo fuera a la universidad, lo que en aquellos tiempos no era tan común. Tal vez el 20% de la clase de secundaria iría a la universidad y el resto no. Siempre estuve muy interesada en las matemáticas y las ciencias, así que tomé todos los cursos que se ofrecían en mi escuela secundaria, que no era un número tremendo en comparación con lo que está disponible hoy. El curso más avanzado que se me ofreció fue un curso de pre-cálculo, que tomé en mi último año.
No había muchas chicas en estas clases. Realmente no recuerdo cuántas había. Podría haber sido la única. Pero eso no parecía importar mucho. Pero sentí por los estudiantes a mi alrededor que esto no era algo que yo debiera estar haciendo, así que mantuve un perfil bajo. Creo que probablemente me animó el profesor de matemáticas que tuve en mi último año, aunque no recuerdo nada específico. Pero ciertamente no recuerdo haber recibido nada negativo.
Mis padres definitivamente me alentaron a que me fuera bien en lo académico, aunque no tuviera nada que ver específicamente con las matemáticas y las ciencias. Por otro lado, tampoco hubo signos negativos. Creo que probablemente lo que fue particularmente importante fue mi padre, que tenía aspiraciones académicas muy altas, y mi madre que nunca dijo nada negativo sobre lo que yo estaba haciendo. Creo que a veces las madres pueden tener un gran impacto en las chicas jóvenes, y si ellas muestran signos de desaprobación del camino que estás tomando, eso podría ser un gran impulso en la dirección opuesta.
Mi padre insistió en que yo aprendiera latín porque dijo que me serviría de mucho, y ha sido así a lo largo de los años, pero también insistió en que yo aprendiera la mecanografía. La razón era que, que Dios mediante, si alguna vez tuviera que mantenerme a mí misma porque no me hubiera casado o le hubiera sucedido algo a mi esposo, entonces podría conseguir un trabajo como secretaria. Entonces secretaria o maestra eran profesiones aceptables para una mujer que necesitara trabajar para mantenerse.
En esos días, si habías ido a la escuela secundaria en California y habías tenido un promedio de B+, entonces te garantizaban un puesto en la Universidad de California. La pregunta era a cuál de los campus terminarías yendo. El mejor campus era UC Berkeley, y yo tenía un promedio muy alto, así que me metí en UC Berkeley. Fui allí para la universidad. Y comencé pensando que iba a especializarme en física. Creo que esta era la aspiración de muchos estudiantes porque se consideraba que la física era la especialidad más difícil. Pero rápidamente descubrí que no tenía mucha aptitud para la física y que me gustaban mucho las matemáticas, así que me cambié a una especialización mayor en matemáticas y una especialización menor en física. No sabía nada sobre computadoras. No recuerdo ninguna computadora como estudiante. Ellos estaban ahí. Quiero decir que he hablado con la gente después del hecho y sé que algunos de los hombres que estaban allí en ese momento los habían descubierto. Probablemente estaban en la Escuela de Ingeniería. Y Berkeley tiene un proceso de admisión separado para eso. No solicité la ingeniería. Nunca se me pasó por la cabeza hacer algo así.
Así que me especialicé en matemáticas en la Facultad de Letras y Ciencia. Nuevamente, mirando hacia atrás en estas clases, si había otra mujer en la clase, eso era todo, y a menudo yo era la única. Y diría que en Berkeley, definitivamente tuve un retroceso. Sabes, nunca fuí llamada en clase, nunca fuí invitada a hacer un proyecto de investigación con alguien. Por lo general, era el mejor o uno de los dos mejores alumnos de la clase, pero realmente no había ninguna diferencia. Por otro lado, nunca encontré ningún problema. O si ocurrió, no lo noté, porque tengo una tendencia a no prestar demasiada atención a las señales negativas, lo que creo que me ha servido de mucho.
Así que me especialicé principalmente en matemáticas, me especialicé menos en física, y cuando terminé en Berkeley, pensé en ir a la escuela de posgrado y en realidad me postulé tanto en UC Berkeley como en Princeton. Me metí en Berkeley. De Princeton recibí una postal que decía que no admitían mujeres en su programa de posgrado. Esto es 1961, por lo que fue antes de que las escuelas de hombres de la Ivy League se unieran con las escuelas de mujeres, y las mujeres no podían ingresar a estas escuelas. Pero estaba muy sorprendida. No tenía idea de que esto también se aplicaba a la escuela de posgrado y a los estudiantes de pregrado.
Pero decidí que no estaba lista para ir a la escuela de posgrado porque no sentía que estaba lista para trabajar tan intensamente en mis estudios. Así que decidí tomar un descanso. Y realmente no estaba pensando en ello como un descanso. Estaba pensando que no estaba listo para ir a la escuela de posgrado. No estaba pensando, "Bueno, en un par de años, iré a la escuela de posgrado". Simplemente pensé que esto no era lo que quería hacer en aquel momento.
Mi padre era originario del área de Boston. En realidad, él creció en Portland, Maine y luego fue a Harvard y su familia se mudó a Boston, así que tuve parientes en el área de Boston y pensé que sería bueno ir a Boston por un tiempo y ver cómo era. Tenía una amiga de la escuela secundaria que había ido a Stanford y estaba interesado en hacer esto también. Ella era una estudiante de biología. Entonces decidimos ir a Boston juntas.
Fuimos a Boston en el verano de 1961. No tenía un trabajo previsto. Decidí que simplemente iría y luego miraría a mi alrededor para ver qué podía encontrar. Llegué a Boston probablemente en agosto y envié currículums a varios lugares. No pude conseguir un trabajo interesante como matemático, pero me ofrecieron un trabajo como programador en la Mitre Corporation, y lo acepté. Ese fue mi primer indicio de que las computadoras existían. Y en ese momento, como no había cursos de ciencias de la computación y nadie salía de la universidad sabiendo algo del tema, o eran muy raros, contrataban a cualquiera que pensaran que podría tener alguna aptitud para la programación.
Conseguí un trabajo en Mitre y en mi primer día de trabajo, me entregaron un manual de FORTRAN y me dieron un problema. Dijeron: "Escribe un programa para hacer" algo. Olvidé lo que era "algo". Descubrí que realmente disfrutaba con esto. Así que soy totalmente autodidacta en lo que respecta a la programación. Tenía que hacer esto yo misma. Nadie me estaba entrenando. Si tuviera una pregunta, podría ir a preguntarle a alguien, pero básicamente lo estaba haciendo todo por mi cuenta. Descubrí que realmente me gustaba. Era realmente buena en eso. Tenía una aptitud para ello. Así que esa fue una gran puerta que se abrió para mí, para encontrar algo que pudiera hacer realmente bien y que realmente disfrutara.
- ¿Había otras mujeres en Mitre trabajando con usted en ese momento?
Definitivamente había otras mujeres allí. Había un gran porcentaje de mujeres porque, como dije, las tomaban si pensaban que podían hacerlo y tenían la capacidad de pensar lógicamente. Ni siquiera tenía que ser un experto en matemáticas, aunque las matemáticas serían un buen antecedente para esto. Pero tenía que ver con ser capaz de pensar lógicamente y ser organizado. Sí, así que definitivamente recuerdo mujeres que trabajaban allí.
Tenían diferentes niveles de empleados. Solo era un "programador", pero había un nivel superior conocido como "personal técnico". Mientras estuve allí, contrataron a un hombre y una mujer, y ambos tenían títulos de maestría. La mujer fue contratada como programadora y el hombre como personal técnico. Me di cuenta de esto y pensé "Hmm, eso realmente no me parece del todo correcto". Aunque en retrospectiva, el hombre tenía un título de MIT y la mujer lo tenía de otro lugar, por lo que podría haber sido justificable. Pero así eran las cosas en aquellos días. De hecho, para conseguir ese trabajo, tuve que decirles que estaba buscando un empleo profesional permanente. Esa era la forma en que se tenía que abordar estos trabajos, porque estaban preocupados de que las mujeres vinieran y se fueran, y habrían perdido su dinero o algo así.
Trabajé en Mitre durante un año y vivía en Cambridge. Vi un anuncio para un puesto en Harvard trabajando en el proyecto de traducción de idiomas y pensé que sería bueno no tener que viajar, así que solicité ese trabajo. Conseguí ese trabajo con un aumento salarial bastante bueno. No sabía nada acerca de cómo negociar un salario más alto al obtener una oferta competitiva. Mitre se ofreció a contrarrestar eso. Se ofrecieron a darme un puesto de personal técnico. Pero, por supuesto, no era por eso que lo estaba haciendo. Solo pensé que sería divertido hacer algo diferente durante un año. Así que fui a trabajar a Harvard en el proyecto de traducción de idiomas.
Resultó ser un buen movimiento. El proyecto utilizó un gran programa escrito en ensamblador, probablemente para el IBM 7094. Creo que en ambos lugares fue un 7094. Eso me dio la oportunidad de comprender realmente cómo funcionaba la máquina, y ya que estaba manteniendo programa grande, me enseñó mucho sobre la estructura del programa. Fue un programa bastante bueno a medida que avanzaban estos programas, y bastante bien modularizado, aunque no sabía nada sobre modularidad en aquellos días. Pero era un código no reentrante, por lo que cuando llamaba a un procedimiento, podrían modificar una instrucción en el procedimiento que estaban llamando para que cuando llegara al final volviera a la persona que llamaba sin tener que tener una pila donde ramificarse a través de algo. Por supuesto, esa era una forma de hacer las cosas muy propensa a errores. Así que ver eso fue una buena lección para mí.
- ¿Entonces esto estaba dirigido por Tony Oettinger?
Tony Oettinger y Susumu Kuno era un postdoc. Si. Pero yo solo era un programador, así que yo no estaba investigando. Encontraban un error en el programa y simplemente decían: "Rastrear esto y solucionarlo". Ese era mi trabajo.
Pero fue un buen entrenamiento. Me preocupan nuestros estudiantes actuales que quizás nunca entiendan realmente cómo funcionan las máquinas. Aunque, por supuesto, las máquinas son mucho más complicadas ahora de lo que eran entonces, ya que en esos días no estaban haciendo una ejecución especulativa, no tenían múltiples procesadores, todas esas cosas de las que tienes que preocuparte hoy. Sin embargo, comprender cuándo está utilizando un lenguaje de nivel superior lo que el compilador está produciendo realmente por debajo es muy útil para comprender lo que está sucediendo.
Trabajé en ese puesto y, a mitad del año, decidí postularme a la escuela de posgrado porque parecía que ya era hora. Estaba aprendiendo muchísimo, pero como dije, era autodidacta. Pensé: “Bueno, probablemente podría aprender mucho más si fuera a la escuela de posgrado. Aprendería más rápido ". Apliqué en Harvard y Stanford. Nunca se me ocurrió aplicar al MIT. Y fui a Stanford porque quería volver al Área de la Bahía. Había estado en Boston por un par de años y mi familia estaba en San Francisco, así que en 1963 fui a Stanford. No tenían una especialización en informática entonces. Tenían un programa. Fue entre, supongo, matemáticas e Ingeniería Electrica. Era una especie de cosa conjunta.
Fui allí sin ningún tipo de apoyo financiero. Ni siquiera sabía que había apoyo financiero. De todos modos, no estaba realmente preocupada porque había ahorrado todo mi dinero, así que tenía muchos ahorros. Pero recuerdo que el día que llegué conocí a John McCarthy. Subí los escalones con él, le pregunté si podía apoyarme y él dijo que sí. Es muy poco probable que esto sea lo que realmente sucedió, por lo que siempre pienso que este es un ejemplo de cómo la memoria no es tan fiable como parece. Creo que, en retrospectiva, probablemente esperaban que estuviera en Inteligencia Artificial porque había estado haciendo este trabajo en el proyecto de traducción de idiomas a pesar de que no sabía nada sobre IA en ese momento.
Probablemente ya habían pensado que iba a trabajar con McCarthy. Esa es mi suposición ahora. Era una facultad muy pequeña. Creo que además de John, solo estaba George Forsythe y Gene Golub. Había un gran proyecto en análisis numérico. Y llegó Niklaus Wirth, pero todavía no estaba allí. Entonces era una facultad bastante pequeña. No creo que hubiera tantas opciones en las que trabajar. No eramos muchos en mi clase tampoco. Creo que cinco tal vez. No estoy segura. Raj Reddy estaba en mi clase.
Así que me mudé a Stanford en el otoño de 1963 y comencé a trabajar con John y a tomar clases. Fue una buena cosa que hacer.
- ¿Qué tipo de clases eran?
Mientras tanto, trabajaba con John [McCarthy] y leía los papeles disponibles, etc. Y descubrí, probablemente en mi segundo año, que realmente preferiría estar con los sistemas. Creo que me gustó ese curso de compilación y me gustó esa forma de pensar. Pero decidí mantenerme en la IA e intentar sacar mi doctorado por el camino lo más rápido posible. Estaba muy interesada en lo que entonces era aprendizaje automático. Estaba realmente interesada en tratar de hacer que las máquinas planificaran y cosas así, pero era un problema muy difícil.
Como saben, esa es un área de IA que ha cambiado enormemente desde aquellos días. Entonces la idea era que el programa pensaría como una persona y que trataríamos de imitar la forma en que la gente piensa sobre las cosas. De hecho, eso fue lo que estaba sucediendo en mi tesis doctoral: el "Programa para Jugar Finales de Ajedrez". Allí estaba pensando en cuáles serían las estrategias que usaría como persona que jugara ese juego, y luego construí esas estrategias en mi programa. Pero lo que se podía lograr con esa forma de pensar sobre el aprendizaje automático quedaba muy limitado. Ahora que hemos cambiado a las técnicas modernas, parecen avanzar mucho más.
De todos modos, hice mi doctorado trabajando con John McCarthy. Y cuando estaba en mi último año, comencé a buscar trabajo, pero nadie me dio ninguna orientación. John no era una persona que hubiera hecho eso de todos modos y realmente no supe de ningún proceso de solicitud. Entonces no solicité ingreso a ninguna escuela de posgrado. Esperé a que la gente viniera a mí, que de alguna manera era lo que estaba sucediendo con los demás, me refiero a Raj Reddy y demás, porque la red de los viejos muchachos estaba en pleno juego en aquel momento.
Entonces, tenía que hacer ofertas... Debería haber solicitado plaza en algún lugar, porque no creo que hubieran salido de la nada, pero tuve una oferta en Hayward State, eso fue porque Harry Huskey, quien dirigía el departamento allí me conocía. Tuve una oferta en SRI, eso fue porque ... no puedo recordar su nombre en este momento, pero la persona que dirige los laboratorios de SRI me conocía. Luego recibí una oferta de Mitre donde me conocían, ¿verdad? [risas] Y sabía que el trabajo en Hayward State sería una muy mala idea, porque era una gran carga de enseñanza con muy poca investigación, y eso no parecía una buena idea. Y quería regresar al área de Boston. De hecho, vine y solicité el MIT, y creo que probablemente me habrían ofrecido un trabajo como personal técnico. No es un investigador asociado. No estoy segura exactamente. Decidí que probablemente no era una buena idea.
Entonces decidí ir a Mitre. Esa fue una buena idea porque también estaba cambiando del campo de la IA a los sistemas, y yo no sabía demasiado sobre sistemas. Creo que había tenido ese curso en compiladores más mi experiencia en arquitectura de computadoras tal como era. Entonces tenía mucho que aprender. Y esto era en el otoño de 1968. Me mudé al área de Boston. Para entonces ya había conocido a mi esposo. Todavía no nos habíamos casado, pero eso parecía algo bueno para continuar, así que me mudé al área de Boston y tomé el trabajo en Mitre.
Comencé en Mitre en septiembre de 1968, y el primer proyecto que me pasaron fue un proyecto de microprogramación. En aquellos días, la microprogramación se consideraba una dirección de investigación interesante. La idea era que le proporcionarían una memoria de solo lectura y un conjunto de instrucciones pequeño y muy simple, y luego podría implementar un conjunto de instrucciones más grandioso utilizando la memoria de solo lectura y este conjunto de instrucciones muy pequeño. Había leído el documento (Dijkstra, E.W., “The structure of the 'THE'--multiprogramming system,” Comm. ACM 11, 5 (May 1968), 341-346.) sobre EL sistema operativo y estaba muy intrigada con la noción de semáforos y estaba interesado en la computación paralela, así que decidí llevar el proyecto en esa dirección. Quiero decir, ¿por qué hacer un proyecto como ese si solo vas a implementar un conjunto de instrucciones estándar? Así que lo moví en esa dirección.
De hecho, tuve la oportunidad de conocer a [Edsger W.] Dijkstra. Llegó a Mitre. Tal vez fue la primavera del 69. No estoy realmente segura. Me reuní con él y hablamos sobre semáforos, y decidí implementarlos en el hardware. Había puesto en el hardware, utilizando el microprograma, una especie de base para la programación paralela. Era un único procesador, pero esta era una forma de compartir el tiempo. Cuando esa parte del proyecto se terminó, la siguiente parte del proyecto fue usarla para algo. Construí un pequeño sistema de multiprogramación sobre este hardware, aprovechando lo que me dieron los semáforos y algunas de las otras cosas que realmente he olvidado, cómo controlas las interrupciones en el sistema y cosas así.
- Así que este fue el Interdata 3 ...
Cuando ese proyecto terminó, Mitre me pidió que mirara la metodología de programación. Ese fue un proyecto exitoso. No estoy segura de cuáles son exactamente estas fechas. De hecho, tengo algunos de los informes técnicos, así que puedo volver y resolver esto.
Esa fue una oportunidad maravillosa para mí porque abrió un área completamente nueva de la que no sabía nada. Empecé a leer la literatura, que no era vasta, pero definitivamente había algo. Los autores eran el tipo de autores habituales si piensas en ... Quiero decir que estaban Tony Hoare, Niklaus Wirth, E.W. Dijkstra y otras personas que reconocerías de esos días. Creo que la mayoría de las conferencias fueron en Europa ahora que lo pienso.
En esos días, si habías ido a la escuela secundaria en California y habías tenido un promedio de B+, entonces te garantizaban un puesto en la Universidad de California. La pregunta era a cuál de los campus terminarías yendo. El mejor campus era UC Berkeley, y yo tenía un promedio muy alto, así que me metí en UC Berkeley. Fui allí para la universidad. Y comencé pensando que iba a especializarme en física. Creo que esta era la aspiración de muchos estudiantes porque se consideraba que la física era la especialidad más difícil. Pero rápidamente descubrí que no tenía mucha aptitud para la física y que me gustaban mucho las matemáticas, así que me cambié a una especialización mayor en matemáticas y una especialización menor en física. No sabía nada sobre computadoras. No recuerdo ninguna computadora como estudiante. Ellos estaban ahí. Quiero decir que he hablado con la gente después del hecho y sé que algunos de los hombres que estaban allí en ese momento los habían descubierto. Probablemente estaban en la Escuela de Ingeniería. Y Berkeley tiene un proceso de admisión separado para eso. No solicité la ingeniería. Nunca se me pasó por la cabeza hacer algo así.
Así que me especialicé en matemáticas en la Facultad de Letras y Ciencia. Nuevamente, mirando hacia atrás en estas clases, si había otra mujer en la clase, eso era todo, y a menudo yo era la única. Y diría que en Berkeley, definitivamente tuve un retroceso. Sabes, nunca fuí llamada en clase, nunca fuí invitada a hacer un proyecto de investigación con alguien. Por lo general, era el mejor o uno de los dos mejores alumnos de la clase, pero realmente no había ninguna diferencia. Por otro lado, nunca encontré ningún problema. O si ocurrió, no lo noté, porque tengo una tendencia a no prestar demasiada atención a las señales negativas, lo que creo que me ha servido de mucho.
Así que me especialicé principalmente en matemáticas, me especialicé menos en física, y cuando terminé en Berkeley, pensé en ir a la escuela de posgrado y en realidad me postulé tanto en UC Berkeley como en Princeton. Me metí en Berkeley. De Princeton recibí una postal que decía que no admitían mujeres en su programa de posgrado. Esto es 1961, por lo que fue antes de que las escuelas de hombres de la Ivy League se unieran con las escuelas de mujeres, y las mujeres no podían ingresar a estas escuelas. Pero estaba muy sorprendida. No tenía idea de que esto también se aplicaba a la escuela de posgrado y a los estudiantes de pregrado.
Pero decidí que no estaba lista para ir a la escuela de posgrado porque no sentía que estaba lista para trabajar tan intensamente en mis estudios. Así que decidí tomar un descanso. Y realmente no estaba pensando en ello como un descanso. Estaba pensando que no estaba listo para ir a la escuela de posgrado. No estaba pensando, "Bueno, en un par de años, iré a la escuela de posgrado". Simplemente pensé que esto no era lo que quería hacer en aquel momento.
Mi padre era originario del área de Boston. En realidad, él creció en Portland, Maine y luego fue a Harvard y su familia se mudó a Boston, así que tuve parientes en el área de Boston y pensé que sería bueno ir a Boston por un tiempo y ver cómo era. Tenía una amiga de la escuela secundaria que había ido a Stanford y estaba interesado en hacer esto también. Ella era una estudiante de biología. Entonces decidimos ir a Boston juntas.
Fuimos a Boston en el verano de 1961. No tenía un trabajo previsto. Decidí que simplemente iría y luego miraría a mi alrededor para ver qué podía encontrar. Llegué a Boston probablemente en agosto y envié currículums a varios lugares. No pude conseguir un trabajo interesante como matemático, pero me ofrecieron un trabajo como programador en la Mitre Corporation, y lo acepté. Ese fue mi primer indicio de que las computadoras existían. Y en ese momento, como no había cursos de ciencias de la computación y nadie salía de la universidad sabiendo algo del tema, o eran muy raros, contrataban a cualquiera que pensaran que podría tener alguna aptitud para la programación.
Conseguí un trabajo en Mitre y en mi primer día de trabajo, me entregaron un manual de FORTRAN y me dieron un problema. Dijeron: "Escribe un programa para hacer" algo. Olvidé lo que era "algo". Descubrí que realmente disfrutaba con esto. Así que soy totalmente autodidacta en lo que respecta a la programación. Tenía que hacer esto yo misma. Nadie me estaba entrenando. Si tuviera una pregunta, podría ir a preguntarle a alguien, pero básicamente lo estaba haciendo todo por mi cuenta. Descubrí que realmente me gustaba. Era realmente buena en eso. Tenía una aptitud para ello. Así que esa fue una gran puerta que se abrió para mí, para encontrar algo que pudiera hacer realmente bien y que realmente disfrutara.
- ¿Había otras mujeres en Mitre trabajando con usted en ese momento?
Definitivamente había otras mujeres allí. Había un gran porcentaje de mujeres porque, como dije, las tomaban si pensaban que podían hacerlo y tenían la capacidad de pensar lógicamente. Ni siquiera tenía que ser un experto en matemáticas, aunque las matemáticas serían un buen antecedente para esto. Pero tenía que ver con ser capaz de pensar lógicamente y ser organizado. Sí, así que definitivamente recuerdo mujeres que trabajaban allí.
Tenían diferentes niveles de empleados. Solo era un "programador", pero había un nivel superior conocido como "personal técnico". Mientras estuve allí, contrataron a un hombre y una mujer, y ambos tenían títulos de maestría. La mujer fue contratada como programadora y el hombre como personal técnico. Me di cuenta de esto y pensé "Hmm, eso realmente no me parece del todo correcto". Aunque en retrospectiva, el hombre tenía un título de MIT y la mujer lo tenía de otro lugar, por lo que podría haber sido justificable. Pero así eran las cosas en aquellos días. De hecho, para conseguir ese trabajo, tuve que decirles que estaba buscando un empleo profesional permanente. Esa era la forma en que se tenía que abordar estos trabajos, porque estaban preocupados de que las mujeres vinieran y se fueran, y habrían perdido su dinero o algo así.
Trabajé en Mitre durante un año y vivía en Cambridge. Vi un anuncio para un puesto en Harvard trabajando en el proyecto de traducción de idiomas y pensé que sería bueno no tener que viajar, así que solicité ese trabajo. Conseguí ese trabajo con un aumento salarial bastante bueno. No sabía nada acerca de cómo negociar un salario más alto al obtener una oferta competitiva. Mitre se ofreció a contrarrestar eso. Se ofrecieron a darme un puesto de personal técnico. Pero, por supuesto, no era por eso que lo estaba haciendo. Solo pensé que sería divertido hacer algo diferente durante un año. Así que fui a trabajar a Harvard en el proyecto de traducción de idiomas.
Resultó ser un buen movimiento. El proyecto utilizó un gran programa escrito en ensamblador, probablemente para el IBM 7094. Creo que en ambos lugares fue un 7094. Eso me dio la oportunidad de comprender realmente cómo funcionaba la máquina, y ya que estaba manteniendo programa grande, me enseñó mucho sobre la estructura del programa. Fue un programa bastante bueno a medida que avanzaban estos programas, y bastante bien modularizado, aunque no sabía nada sobre modularidad en aquellos días. Pero era un código no reentrante, por lo que cuando llamaba a un procedimiento, podrían modificar una instrucción en el procedimiento que estaban llamando para que cuando llegara al final volviera a la persona que llamaba sin tener que tener una pila donde ramificarse a través de algo. Por supuesto, esa era una forma de hacer las cosas muy propensa a errores. Así que ver eso fue una buena lección para mí.
- ¿Entonces esto estaba dirigido por Tony Oettinger?
Tony Oettinger y Susumu Kuno era un postdoc. Si. Pero yo solo era un programador, así que yo no estaba investigando. Encontraban un error en el programa y simplemente decían: "Rastrear esto y solucionarlo". Ese era mi trabajo.
Pero fue un buen entrenamiento. Me preocupan nuestros estudiantes actuales que quizás nunca entiendan realmente cómo funcionan las máquinas. Aunque, por supuesto, las máquinas son mucho más complicadas ahora de lo que eran entonces, ya que en esos días no estaban haciendo una ejecución especulativa, no tenían múltiples procesadores, todas esas cosas de las que tienes que preocuparte hoy. Sin embargo, comprender cuándo está utilizando un lenguaje de nivel superior lo que el compilador está produciendo realmente por debajo es muy útil para comprender lo que está sucediendo.
Trabajé en ese puesto y, a mitad del año, decidí postularme a la escuela de posgrado porque parecía que ya era hora. Estaba aprendiendo muchísimo, pero como dije, era autodidacta. Pensé: “Bueno, probablemente podría aprender mucho más si fuera a la escuela de posgrado. Aprendería más rápido ". Apliqué en Harvard y Stanford. Nunca se me ocurrió aplicar al MIT. Y fui a Stanford porque quería volver al Área de la Bahía. Había estado en Boston por un par de años y mi familia estaba en San Francisco, así que en 1963 fui a Stanford. No tenían una especialización en informática entonces. Tenían un programa. Fue entre, supongo, matemáticas e Ingeniería Electrica. Era una especie de cosa conjunta.
Fui allí sin ningún tipo de apoyo financiero. Ni siquiera sabía que había apoyo financiero. De todos modos, no estaba realmente preocupada porque había ahorrado todo mi dinero, así que tenía muchos ahorros. Pero recuerdo que el día que llegué conocí a John McCarthy. Subí los escalones con él, le pregunté si podía apoyarme y él dijo que sí. Es muy poco probable que esto sea lo que realmente sucedió, por lo que siempre pienso que este es un ejemplo de cómo la memoria no es tan fiable como parece. Creo que, en retrospectiva, probablemente esperaban que estuviera en Inteligencia Artificial porque había estado haciendo este trabajo en el proyecto de traducción de idiomas a pesar de que no sabía nada sobre IA en ese momento.
Probablemente ya habían pensado que iba a trabajar con McCarthy. Esa es mi suposición ahora. Era una facultad muy pequeña. Creo que además de John, solo estaba George Forsythe y Gene Golub. Había un gran proyecto en análisis numérico. Y llegó Niklaus Wirth, pero todavía no estaba allí. Entonces era una facultad bastante pequeña. No creo que hubiera tantas opciones en las que trabajar. No eramos muchos en mi clase tampoco. Creo que cinco tal vez. No estoy segura. Raj Reddy estaba en mi clase.
Así que me mudé a Stanford en el otoño de 1963 y comencé a trabajar con John y a tomar clases. Fue una buena cosa que hacer.
- ¿Qué tipo de clases eran?
Lo que sea que ofrecieran. Entonces tomé muchas clases con Dana Scott. Estaba en Stanford en ese momento y daba clases de lógica. Recuerdo una clase de compiladores. Recuerdo que tuvimos que escribir una especie de compilador. Realmente no recuerdo de qué se trataba, pero solíamos tomar el control de la máquina por la noche. Fue un B5500, creo. De esa forma, podríamos obtener una respuesta rápida, ya que todavía eran los días del procesamiento por lotes, y si no podías obtener la máquina, entonces tendrías que enviar tu programa y esperar un día más o menos antes de poder obtener sus resultados.
La programación claramente interactiva es una gran mejora con respecto al procesamiento por lotes, pero una ventaja del procesamiento por lotes es que se debe pensar detenidamente el experimento antes de enviarlo, de lo contrario, se está perdiendo todo un día de tiempo. Otra ventaja del procesamiento por lotes es que se debe aprender a multiplexar tu tiempo, ya que no puedes quedarte allí esperando. [risas] Creo que ambas eran habilidades muy valiosas que me sirvieron en gran medida con el paso del tiempo.
No sé qué más clases tomé. Ciertamente no había curso sobre sistemas operativos. Me negué a tomar el curso de análisis numérico porque realmente no me gustaban esas cosas. Así que no sé: tomé lo que sea, lo que la gente estaba tomando, lo que sea que me ofrecieran. Recuerdo que Jerry Feldman apareció tal vez mi tercer año. Probablemente Niklaus Wirth estaba dando el curso del compilador. Ese podría haber sido mi segundo año. Es dificil de recordar.
Mientras tanto, trabajaba con John [McCarthy] y leía los papeles disponibles, etc. Y descubrí, probablemente en mi segundo año, que realmente preferiría estar con los sistemas. Creo que me gustó ese curso de compilación y me gustó esa forma de pensar. Pero decidí mantenerme en la IA e intentar sacar mi doctorado por el camino lo más rápido posible. Estaba muy interesada en lo que entonces era aprendizaje automático. Estaba realmente interesada en tratar de hacer que las máquinas planificaran y cosas así, pero era un problema muy difícil.
Como saben, esa es un área de IA que ha cambiado enormemente desde aquellos días. Entonces la idea era que el programa pensaría como una persona y que trataríamos de imitar la forma en que la gente piensa sobre las cosas. De hecho, eso fue lo que estaba sucediendo en mi tesis doctoral: el "Programa para Jugar Finales de Ajedrez". Allí estaba pensando en cuáles serían las estrategias que usaría como persona que jugara ese juego, y luego construí esas estrategias en mi programa. Pero lo que se podía lograr con esa forma de pensar sobre el aprendizaje automático quedaba muy limitado. Ahora que hemos cambiado a las técnicas modernas, parecen avanzar mucho más.
De todos modos, hice mi doctorado trabajando con John McCarthy. Y cuando estaba en mi último año, comencé a buscar trabajo, pero nadie me dio ninguna orientación. John no era una persona que hubiera hecho eso de todos modos y realmente no supe de ningún proceso de solicitud. Entonces no solicité ingreso a ninguna escuela de posgrado. Esperé a que la gente viniera a mí, que de alguna manera era lo que estaba sucediendo con los demás, me refiero a Raj Reddy y demás, porque la red de los viejos muchachos estaba en pleno juego en aquel momento.
Entonces, tenía que hacer ofertas... Debería haber solicitado plaza en algún lugar, porque no creo que hubieran salido de la nada, pero tuve una oferta en Hayward State, eso fue porque Harry Huskey, quien dirigía el departamento allí me conocía. Tuve una oferta en SRI, eso fue porque ... no puedo recordar su nombre en este momento, pero la persona que dirige los laboratorios de SRI me conocía. Luego recibí una oferta de Mitre donde me conocían, ¿verdad? [risas] Y sabía que el trabajo en Hayward State sería una muy mala idea, porque era una gran carga de enseñanza con muy poca investigación, y eso no parecía una buena idea. Y quería regresar al área de Boston. De hecho, vine y solicité el MIT, y creo que probablemente me habrían ofrecido un trabajo como personal técnico. No es un investigador asociado. No estoy segura exactamente. Decidí que probablemente no era una buena idea.
Entonces decidí ir a Mitre. Esa fue una buena idea porque también estaba cambiando del campo de la IA a los sistemas, y yo no sabía demasiado sobre sistemas. Creo que había tenido ese curso en compiladores más mi experiencia en arquitectura de computadoras tal como era. Entonces tenía mucho que aprender. Y esto era en el otoño de 1968. Me mudé al área de Boston. Para entonces ya había conocido a mi esposo. Todavía no nos habíamos casado, pero eso parecía algo bueno para continuar, así que me mudé al área de Boston y tomé el trabajo en Mitre.
Comencé en Mitre en septiembre de 1968, y el primer proyecto que me pasaron fue un proyecto de microprogramación. En aquellos días, la microprogramación se consideraba una dirección de investigación interesante. La idea era que le proporcionarían una memoria de solo lectura y un conjunto de instrucciones pequeño y muy simple, y luego podría implementar un conjunto de instrucciones más grandioso utilizando la memoria de solo lectura y este conjunto de instrucciones muy pequeño. Había leído el documento (Dijkstra, E.W., “The structure of the 'THE'--multiprogramming system,” Comm. ACM 11, 5 (May 1968), 341-346.) sobre EL sistema operativo y estaba muy intrigada con la noción de semáforos y estaba interesado en la computación paralela, así que decidí llevar el proyecto en esa dirección. Quiero decir, ¿por qué hacer un proyecto como ese si solo vas a implementar un conjunto de instrucciones estándar? Así que lo moví en esa dirección.
De hecho, tuve la oportunidad de conocer a [Edsger W.] Dijkstra. Llegó a Mitre. Tal vez fue la primavera del 69. No estoy realmente segura. Me reuní con él y hablamos sobre semáforos, y decidí implementarlos en el hardware. Había puesto en el hardware, utilizando el microprograma, una especie de base para la programación paralela. Era un único procesador, pero esta era una forma de compartir el tiempo. Cuando esa parte del proyecto se terminó, la siguiente parte del proyecto fue usarla para algo. Construí un pequeño sistema de multiprogramación sobre este hardware, aprovechando lo que me dieron los semáforos y algunas de las otras cosas que realmente he olvidado, cómo controlas las interrupciones en el sistema y cosas así.
- Así que este fue el Interdata 3 ...
Esto sería Interdata 3. O tal vez fue el 4.
Sí. Creo que fue ... ¿Fue Interdata 3 o 4? He olvidado. Podría mirar en
mi ... ya sabes. Pero de todos modos, fue ...
- Fueron similares.
Sí. Creo que fue ... ¿Fue Interdata 3 o 4? He olvidado. Podría mirar en
mi ... ya sabes. Pero de todos modos, fue ...
- Fueron similares.
Sí. Probablemente terminé la primera parte de esa cosa en el primer año, y luego en la segunda parte del proyecto, que tal vez comenzó en el otoño de 1969, para entonces estaba trabajando con otra persona, alguien llamado Bob Curtis que era un personal técnico en Mitre. En realidad no recuerdo si Bob estuvo involucrado. No estoy segura exactamente de cuándo comenzamos a trabajar juntos. De todos modos, sin duda estuvo involucrado en los primeros trabajos sobre el sistema operativo Venus.
[risas] La pequeña computadora que desarrollé se llamaba "Venus" y luego desarrollamos el sistema operativo Venus. También tuve un par de personas trabajando como programadores. Hice la mayor parte del diseño y descubrimos cómo implementar esto. Era un pequeño sistema interesante. Ha pasado mucho tiempo, realmente no he pensado mucho en eso desde entonces, pero me metió en los sistemas operativos y aprendí sobre lo que estaba sucediendo, el tipo de abstracciones que se usaban en los sistemas operativos. Los semáforos resultaron ser útiles. Ese fue probablemente el segundo año en Mitre: 69 quizás en el otoño de 1970.
Cuando ese proyecto terminó, Mitre me pidió que mirara la metodología de programación. Ese fue un proyecto exitoso. No estoy segura de cuáles son exactamente estas fechas. De hecho, tengo algunos de los informes técnicos, así que puedo volver y resolver esto.
Eso me metió en la metodología de programación. Mitre, como saben, trabaja para el gobierno, y el gobierno presenta una solicitud de propuestas, y yo aún no estaba en una posición en la que fuera la persona que respondiera esas propuestas. Yo era alguien que estaban usando como persona a la que podían poner a cargo de un proyecto una vez que lo habían traído. Cuando llegué, este proyecto de Interdata 3 estaba allí esperando que trabajara, y luego, una vez hecho, ya habían ofertado la solicitud de propuesta sobre "crisis de software". Y cuando ya estaba terminando este proyecto, me pidieron que me encargara de eso.
Esa fue una oportunidad maravillosa para mí porque abrió un área completamente nueva de la que no sabía nada. Empecé a leer la literatura, que no era vasta, pero definitivamente había algo. Los autores eran el tipo de autores habituales si piensas en ... Quiero decir que estaban Tony Hoare, Niklaus Wirth, E.W. Dijkstra y otras personas que reconocerías de esos días. Creo que la mayoría de las conferencias fueron en Europa ahora que lo pienso.
- ¿Fuiste a la reunión de metodología del programa de la OTAN o lo que sea, la famosa?
No lo hice, no. No fui a muchas reuniones en este momento. Más tarde estuve trabajando
Grupo 2.3, 2.5, el grupo de trabajo de metodología. Pero nunca encontré ese tipo de
formato útil para mi. Tiendo a ser más "trabajo solo". Pero leí procedimientos de estas reuniones y aprendí sobre lo que estaba pasando, y Empecé a pensar en metodología. Como digo en mis conversaciones de Turing, también estaba mirando a varias personas, Dave Parnas, por supuesto, era otro gran gran jugador, y leí todos los papeles que pude conseguir y pensé en sus propuestas de metodología. En algún momento durante este proceso, me di cuenta de que yo había inventado una metodología propia mientras trabajaba en el sistema Venus, no porque estuviera pensando en sino solo porque quería una forma de organizar ese software, que nos dio una forma sensata de abordar el proceso de desarrollo de software.
La idea que tuve en Venus fue que ... me refiero a entender esta vez los antecedentes, tienes que entender que había esa escuela ALGOL de programación que tuvo una buena idea y una mala idea. La buena idea fue que tenías bloques y el bloque interno tenía datos privados y el bloque externo no podía acceder eso. La mala idea era que tenías bloques [risas] y el bloque interior podía libremente acceder a todas las cosas en el bloque exterior, por lo que hubo una tendencia natural a comunicarse a través de variables globales. Esa no fue una gran idea. Algunos de los documentos de Parnas hablaron un poco sobre por qué era una mala idea, aunque no lo quisiera decir que en general se entendiera que era una mala idea.
En cualquier caso, de alguna manera entendí que no era una gran idea, y creo que tiene que ver con el hecho de que si tienes muchas personas trabajando en diferentes piezas de la sistema y todos pueden comunicarse libremente a través de este conjunto de variables globales, vas a tener un gran desastre en tus manos. Y tal vez vi un desastre como eso en las cosas de Harvard. Realmente no estoy segura de dónde vino. Pero decidi no íbamos a compartir variables globales en el desarrollo del sistema de Venus. En su lugar, íbamos a dividir el espacio variable global en lo que llamé "particiones", y cada partición estaría a cargo de un módulo de programa particular, y ese módulo sería el único lugar donde podría acceder a esos datos. Y si otras partes del programa tuvieran que usarlo, ese módulo proporcionaría procedimientos que otras partes del programa podrían llamar. Esta es la metodología que utilizamos y funcionó extremadamente bien.
Otra cosa que estaba sucediendo en Venus, de la que generalmente no hablo en mi charla de Turing, es que también estábamos pensando en la pregunta "¿Cómo organizar un programa paralelo como un sistema operativo? ¿Y cómo controlas en particular los dispositivos, los recursos compartidos? ¿Cómo te comunicas entre los hilos que están haciendo el procesamiento concurrente? ”Y ya estaba usando tipos de datos abstractos. Estaba pensando en términos de la forma en que el subproceso hace uso del recurso compartido, que en realidad es un objeto con un montón de operaciones, y llamamos a ese objeto y tiene algunos recursos ocultos que utiliza para clasificar. ... está siendo compartido por todos los hilos y así es como sucede realmente el control.
Aunque no lo expliqué en el primer artículo que escribí sobre metodología de programación. Ni siquiera estaba pensando en eso hasta el Día de la Historia SOSP (ACM Symposium on Operating Systems Principles) donde di una charla sobre la historia de la estructura del programa en los sistemas operativos y volví a mirar el sistema THE (Dijkstra), miré el sistema Venus, y luego allí estaba Schroeder y Nelson, o Nelson y Birrell, el documento sobre las dos formas de organizar un programa paralelo, una donde tienes colas y la otra en la que envías mensajes. Estaba mirando algunos de esos documentos de metodología y me di cuenta de que Venus era en realidad uno de los que estaban en la mezcla y que tenían dos estructuras: una con recursos compartidos en el que los hilos solo llaman a operaciones y todo se soluciona bajo las sábanas, y esta otra estructura en la que proporcionas ... es una especie de estructura similar a CSP en el que tienes tu hilo y hay un montón de métodos que son llamados de forma remota. Es un modelo diferente de computación. Entonces Venus tenía ambas cosas. Estaba en el recurso compartido, en el que simplemente llamabs a sus operaciones. De alguna manera se deducía de forma natural de la idea de particiones y solo operaciones de llamada.
Bueno. Así que estaba pensando en la metodología y me di cuenta de que tenía una metodología, así que escribí un artículo sobre ella y que entró en la Junta de Otoño, creo que fue en 19 -... Creo que probablemente se publicó en el '71 o '72 . Pero mientras tanto, también había escrito [un] artículo sobre Venus, y lo presenté a SOSP. Fue el tercer SOSP. Y fue aceptado. [The Design of the Venus Operating System]
Por cierto, esa fue la primera experiencia de escritura que tuve en la que alguien leía mi artículo y me criticaba. Porque John [McCarthy] no hizo eso. Nunca había tenido esa experiencia. Como estudiante de posgrado, nunca tuve un asesor que trabajara conmigo y me dijera: "Oh, esto no tiene sentido. Reorganizar eso ", y así sucesivamente. Fue muy útil. Ese era mi jefe, Judy Clapp. Había sido personal técnico en Mitre incluso antes que yo, y tiene historias muy interesantes que contar. Ella estaba cumpliendo ese papel y fue muy valioso.
De todos modos, el documento sobre Venus fue aceptado. SOSP, como saben, es la mejor conferencia de sistemas. Fue incluso en esos días, a pesar de que era solo el tercero, porque era el único acto en la ciudad. Jerry Saltzer fue el ... Yo fui uno de los premios. Siempre han tenido esta tradición de los mejores artículos, los premios, y entran en ... solían ir a las Comunicaciones. Ahora entran en TOCS. [Transactions on Computer Systems (TOCS)]
Así que Jerry fue el presidente de mi sesión, y Corby estaba allí, el profesor Corbató. Y no estoy seguro de quién más del MIT estaba allí. Probablemente otras personas del grupo Multics. Y después de mi charla me invitaron a postular al MIT. Entonces creo que hablé con Jerry. Me animó a presentar una solicitud, así que lo hice. También solicité admisión en Berkeley, y probablemente podría haber ido a Berkeley, pero mi esposo no estaba dispuesto a mudarse. Estábamos casados para entonces y él trabajaba para Raytheon y no parecía que fuera fácil para él. Ciertamente no en el área de Berkeley. Podría haber sido capaz de hacer algo en la península. Así que me mudé al MIT en el otoño de 1972. Y al mismo tiempo, Mike Schroeder fue contratado, por lo que contrataron a dos personas en sistemas.
Creo que fue el Título IX el que abrió las cosas para las mujeres. Mi comprensión de lo que había sucedido fue que el paisaje había cambiado. De repente hubo más presión sobre las universidades para contratar mujeres. No creo que todas las universidades estuvieran prestando mucha atención a esto, pero el MIT estaba prestando atención. Creo que venía de Jerry Wiesner, quien era el presidente del MIT, porque este tipo de cosas tiene que venir desde arriba. Jerry estaba realmente interesado en aumentar el número de mujeres. El jefe del departamento de EE - no era EECS todavía, solo era EE - era Louis Smullin, y creo que Louis estaba interesado en hacer esto. Entonces Bob Fano era el jefe de ciencias de la computación, y Bob definitivamente estaba interesado en hacer esto. Estaban buscando una mujer y allí estaba yo. Por lo tanto, fue un intercambio mutuamente beneficioso. Tan pronto como recibí la oferta, supe que iba a dejar Mitre. Era algo que supongo que siempre pensé que sería divertido hacer, y decidí que lo haría.
Entonces llegué al MIT. Solo había 10 mujeres en la facultad de una facultad de mil. Como saben, desde que vas al MIT, el número de mujeres en la población de pregrado era muy, muy pequeño. Mi esposo es de la clase de 1960 y había 16 mujeres en su clase. Quiero decir, muy pequeño, es realmente, ya sabes ... MIT siempre admitió mujeres, pero nunca tuvieron muchas, en parte porque no tenían una vivienda para ellas y por eso no sabían qué hacer con ellas. Eso cambió cuando ... Olvidé el nombre de la mujer que dio dinero para un dormitorio para mujeres [McCormick Hall lleva el nombre de Stanley A. McCormick, el esposo de Katherine Dexter McCormick '04, quien fue el benefactor del edificio], y tan pronto como tuvieron más espacio, comenzaron a dejar entrar a más mujeres. Eso fue en los años 70 o tal vez tarde. 60s. No estoy seguro exactamente cuándo.
- ’60s.
¿Eran los años 60? Sí. Así que fui al MIT en el otoño de 1972 y fue un movimiento maravilloso para mí. La gloria de trabajar como profesor universitario es que puedes hacer lo que quieras, ¿verdad? Vas a un lugar como el MIT, tienes ciertas responsabilidades. El MIT está muy enfocado en la enseñanza y la enseñanza de calidad, y todos imparten dos cursos al año, y eso lleva tiempo y hay que prestar atención a eso. Pero en lo que respecta a la investigación, usted se da cuenta sobre qué está investigando.
Por supuesto, también hay un inconveniente en esto. En primer lugar, es mejor que tengas las ideas. Tienes que haber imaginado lo que vas a hacer. Puedes hacerlo, pero tienes que saber qué es y luego tienes que recaudar dinero. Pero recaudar dinero fue bastante fácil en esos días porque esos fueron los días en que DARPA estaba apoyando la investigación en ciencias de la computación y principalmente estaba poniendo su dinero en algunas instituciones. No recuerdo si todavía era Project MAC o Lab for Computer Science, pero solíamos enviar una propuesta para todo el laboratorio y solo tenía que escribir un par de páginas en esa propuesta para obtener dinero. También escribí propuestas de NSF solo para tener otra fuente de dinero y practicar cómo hacerlo. Pero en comparación con la situación actual, era mucho más fácil financiar tu investigación entonces.
Entonces vine al MIT. El primer curso que impartí fue lo que actualmente es 6.004. Entonces es un curso de arquitectura de computadoras. Esta fue una tarea extraña para mí porque no tenía antecedentes de EE[Ingeniero Eléctrico], y en realidad estaba en un departamento de EE. Todavía no era EECS [Ingeniero Eléctrico & Ciencias Computación]. No recuerdo cuándo se convirtió en EECS. Probablemente unos años más tarde. Eso fue un poco revuelto. Jack Dennis tenía un estudiante graduado, Clem Leung, quien también era un TA [Teaching Assistantship] para la clase, y él me ayudó. Sabes, me estaba quedando solo a una semana por delante de los estudiantes, aprendiendo cosas sobre circuitos y demás, en lo que yo realmente no tenía antecedentes. Y definitivamente tenía estudiantes que no estaban contentos de verme. No sentí que me discriminara la facultad, pero sentí que los estudiantes ... había unos pocos estudiantes en la clase que estaban ... tratarían de hacerme tropezar. Intentarían hacerme una pregunta que no podría responder. Por supuesto que estaba en una especie de posición vulnerable, enseñando un curso en un área que no conocía. Así que fue un pequeño bautismo de fuego, pero aprendí cómo ... estaba una semana por delante de ellos, y aprendí a decir: "Hablaré de eso en otro momento" [risas]. Mientras tanto comencé a investigar ...
Oh, el otro problema era que estaba en Project MAC o LCS, y decidieron que yo
era una persona de IA y me pusieron en el piso de IA. Creo que querían que yo
trabajar en IA Pero mientras tanto trabajaba metodología de programación. Jack
Dennis, en la primavera de 1963, me ayudó a trasladar mi oficina a la planta de sistemas, que era un lugar mucho más agradable, y que ayudó mucho. Entonces Jack me fue muy útil.
Mientras tanto, en investigación, me paré allí pensando en metodología de programación, y estaba realmente interesada en la metodología de programación. Y pensé que era un campo muy importante. Y lo que noté fue que aunque los documentos eran muy convincentes cuando los leías y siempre tenían un ejemplo y tu seguirías el ejemplo y dirías: "Oh sí, eso es muy Convincente. Esta es la forma correcta de hacer las cosas "... Y estoy pensando específicamente sobre los documentos de Parnas porque los suyos eran sobre cómo estructurar la programación. Si si piensas en los documentos de la época, había documentos sobre "Así es como se diseña software". Así que Niklaus Wirth escribió sobre la programación de arriba hacia abajo y Dijkstra envió esa maravillosa carta a las Comunicaciones de la ACM sobre "La Declaración GOTO es considerada dañina", y realmente la esencia de ese documento, si piensas detrás de escena de ese documento, el mensaje de Dijkstra trataba realmente de decir: "Deberíamos estar razonando sobre la corrección del código". El GOTO era malo porque dificultaba hacer ese razonamiento, pero la idea de que la programación es un problema intelectualmente difícil y debemos abordarlo de una forma matemática, eso fue en los primeros días y fue un paso bastante significativo hacia adelante para poder ver la forma de pensar sobre las cosas.
Pero Dave Parnas estaba escribiendo sobre modularidad, y decía: "Así es como deberíamos pensar acerca de los módulos". De hecho, dijo: "Los programas están formados por módulos, pero no sé cuáles son". Y así era como estaban las cosas en aquel momento. Pero tenía la idea de las especificaciones. Él decía: "Sean lo que sean, mejor describamos sus conexiones por completo". Así que quiso decir "Cualquiera que sea su interfaz, es mejor que tengamos una descripción completa".
Solía sentirme un poco celosa de los ingenieros eléctricos porque pensaba: "Al menos ellos tienen estos componentes y los conectan por cables, y eso te obliga a concentrarte realmente en cuáles son esos cables". Mientras que el software era tan plástico que la gente solía diseñar sin pensar mucho en esos cables, por lo que terminarían con este gran lío de interconexiones entre las piezas del programa, y eso fue un gran problema. Ese era el problema que estaba viendo en Venus cuando dije: "Vamos a tener particiones", pero fue solo un problema en general. Las variables globales fueron el gran problema. Solo la posibilidad y de que no hubiera nada que obligara a hacer las cosas de una manera concreta, llevaba a que pudieras hacer lo que quisieras.
De todos modos, estaba pensando en esto. Estaba pensando en el hecho de que, aunque la gente leyera el artículo de Parnas y estaba convencida de que la gente leería mi artículo y tendría la misma reacción, diría: "Sí, es una gran idea", pero cuando empezara a pensar sobre "¿Cómo lo aplico a mis propias cosas?" todo se vendría abajo, simplemente no tenía ni idea de cómo aplicarlo.
Estaba tratando de pensar en "¿Qué podemos hacer para mejorar las cosas?" Y en algún momento, y realmente no sé cuándo, pero probablemente el invierno de 1963-64 ... quiero decir ...
- El año 73
.72-73, [risas] Se me ocurrió la idea de la abstracción de datos. Y fue esta idea maravillosa. Vino de la nada. Pero una vez que la obtuve, pude ver que esto realmente iba a funcionar porque los programadores ya sabían sobre los tipos de datos abstractos. Quiero decir, incluso si no estaban pensando en ellos, porque sabían cuando usaron una matriz en su lenguaje Fortran que esto no era algo que tenía el hardware, era algo que usabas a través de un conjunto de operaciones y debajo de la superficie había un implementación en curso. Ciertamente, usted sabía esto con creces si estaba usando Lisp, que fue en lo que escribí mi tesis, porque allí se usan listas y estaba claro que había una implementación debajo y que las listas eran abstractas.
Entonces sentí que los programadores podrían entender la noción de abstracción de datos. Ya entendían sobre la abstracción de procedimientos, y la abstracción de datos era más poderosa porque un procedimiento ... Ah, por cierto, a veces implementaban una abstracción de datos con una abstracción de procedimiento al tener un montón de argumentos adicionales que controlaban las diferentes cosas que el procedimiento iba a hacer, pero eso también fue un desastre. Así que sentí que esto era algo por lo que los programadores sentirían afinidad y algo que podrían entender.
Tuve la suerte de tener el maravilloso momento en el que tuve esta idea, y tan pronto como tuve esa idea, supe que iba a ir a algún lado. Entonces comencé a trabajar en esa idea. Y comencé a trabajar conjuntamente con Steve Zilles. Y esto fue definitivamente en la primavera de 1973.
Steve era un estudiante graduado en el MIT y es empleado de IBM. IBM estaba en el mismo edificio de Tech Square en el que estaba el laboratorio. Era mayor. Tenía poco más de treinta años, así que había estado trabajando para IBM por un tiempo y luego regresó a la escuela, y creo que solo iba a la escuela a tiempo parcial porque todavía estaba trabajando para IBM. Y él había tenido algunas ideas similares, así que Steve y yo comenzamos a trabajar juntos. Creo que Jack Dennis organizó un pequeño taller en la primavera de 1963, y tal vez así es como me conecté con Steve. Creo que Tony Hoare estaba allí, pero podría estar confundida sobre esto. No he tratado de resolverlo. Pero Jack estaba interesado en estas ideas y me estaba animando a trabajar en ellas.
Steve y yo comenzamos a trabajar en esto. Tener una idea y descubrir de qué se trata esta idea son dos cosas diferentes, así que era solo "Aquí hay una dirección para ir". Así que comenzamos a tratar de desarrollarla, y sabíamos que probablemente íbamos a trabajar con un lenguaje de programación como resultado porque se necesita expresar una idea como esa en un lenguaje de programación para que las personas tengan a su alcance las características lingüísticas necesarias para que todo se mantenga unido. Estábamos interesados en "¿Cómo sería ese lenguaje de programación? ¿Cómo podría tener una verificación de tipo que abarcara esta noción de abstracción de datos? ”Y todo el asunto era un gran misterio, pero comenzamos a trabajar en esto.
Por supuesto, leíamos documentos, y ahora me estaba moviendo hacia lenguajes de programación desde un respaldo en el que conocía ya Lisp y Fortran, y por supuesto que había terminado de leer sobre otras cosas. Steve provenía de IBM, que era el gran protagonista de la programación en ese momento: tenían Fortran, tenían PL / I, tenían COBOL, así que cubríasmos una amplia gama de lenguajes de programación entre nosotros y leímos un montón de documentos. El que encontré más... Bueno, leímos el artículo sobre Simula 67, y eso no tenía la abstracción de datos a pesar de que se trataba de clases y subclases, y se podía ver cómo podía ser la abstracción de datos . No tenía encapsulación, que es un componente muy crítico si desea modularidad, y estaban interesados principalmente en la herencia, que vimos como una falacia, por lo que ignoramos eso.
Jim Morris hizo un documento maravilloso sobre “Protección en lenguajes de programación” [James H. Morris, Jr., Communications of the ACM, Volume 16 Issue 1, Jan. 1973, Pages 15-21 ] creo que se llamaba, donde hablaba sobre modularidad y cuáles son las reglas que debe seguir para obtener los beneficios de la modularidad. Entonces, los beneficios de la modularidad son el razonamiento local ... Eso es lo más importante. Y Jim dijo: “Bueno, un módulo tiene algún estado dentro y luego un montón de código. La primera regla es que el código exterior al módulo sea capaz de modificar ese estado. Y esto es claramente esencial, porque si el código en el exterior pudiera modificar ese estado, entonces nunca sería capaz de razonar sobre el buen estado de ese módulo porque todo el código en el programa sería sospechoso". Pero luego dijo: "Pero, además, desea modificabilidad, lo que significa que si no me gusta la forma en que se implementó ese módulo, me gustaría poder reemplazarlo con otro código implementado de una manera diferente". Y para obtener modificabilidad, el código en el exterior ni siquiera debería mirar el estado. Solo debería interactuar a través de su interfaz abstracta".
Esas son, de hecho, las dos piezas clave de la modularidad, aunque en esos días e incluso en la actualidad, otro componente muy importante sobre la modularidad es que es una herramienta de administración, porque le permite dividir el programa en piezas separadas. Si siguen estas reglas, entonces las personas pueden trabajar en estas piezas de forma independiente. En aquellos días, la gente no sabía qué eran los módulos, y se escribían documentos que decían cosas como: "Un módulo no debe tener más de mil líneas de código". Quiero decir, la gente realmente no entendía la noción de abstracción, la noción de encapsulación. En su mayoría solo entendieron que necesitaban una forma de controlar el proceso de desarrollo del programa para que las personas pudieran estar trabajando en cosas separadas.
De todos modos, Jim expuso esos dos principios, y Tony Hoare al mismo tiempo estaba escribiendo documentos sobre ... Él ya tenía la noción de abstraer desde una representación a un tipo de datos abstractos a pesar de que eran tipos existentes en lugar de ... Así que esta idea surgió en muchos lugares diferentes.
Pero Jim no tenía idea de cómo implementar esto. Entonces, después de decir: "Bueno, estas son las reglas", la pregunta es "Bueno, ¿puedo aplicarlas? En particular, ¿puedo incluirlas en el lenguaje de programación para que el compilador pueda garantizar que obtenga la encapsulación? Entonces, eso fue con lo que Steve y yo estábamos luchando. ¿Cómo implementaríamos esto? ¿Cómo lo haríamos funcionar? Jim tenía una propuesta que consistía básicamente en utilizar cifrado. Habló sobre "sellar" y "abrir". Y eso funcionaría. La idea es que el módulo tiene una clave. Encripta un objeto cuando sale, lo desencripta cuando entra. Si alguien ha estado manipulándolo, se nota. Eso ciertamente funciona, pero no es práctico. Así que estábamos buscando un ... Ya sabes, "No quiero hacerlo de esa manera. Quiero algo eficiente ".
Y para el verano de 1973, habíamos descubierto que era posible hacer esto con un compilador teniendo la noción de una estructura lingüística que implementara una abstracción de datos y el compilador solo aseguraría la barrera de abstracción y el código en el exterior solo podría llamar a las operaciones. Sin embargo, fue solo un boceto. Quiero decir que no teníamos un lenguaje. Acabamos de tener una propuesta para un lenguaje. Y en ese documento, hablamos sobre algunos problemas que no sabíamos manejar. En particular, genéricos y polimorfismo.
El polimorfismo fue descuidado por años. Creo que es relativamente fácil, cuando solo estás haciendo procedimientos, ignorar el hecho de que "no quiero una rutina de clasificación que funcione en una variedad de enteros". Quiero una rutina de clasificación que funcione en general ". Pero dado el limitado rango de tipos de datos que existían en ese momento, se puede entender por qué la gente no estaba pensando en eso. Tan pronto como se va a la abstracción de datos, se puede ver que se necesita algún mecanismo que permita definir una abstracción de datos como una lista o un conjunto o un mapa o algo que simplemente define una vez y no deba re-implementarlo cada vez que tenga otro tipo de elemento. Y claramente hubo polimorfismo en la implementación de los tipos ya incorporados. Por lo tanto, las matrices podrían tener numeros de coma flotante o enteros si estabas trabajando en Fortran. Entonces fue allí. Simplemente no fue mostrado como un mecanismo que los programadores pudieran tener en sus manos, y pudimos ver que iba a ser un componente importante.
Escribimos este documento sobre tipos de datos abstractos y fue un gran éxito. Quiero decir que lo enviamos a la Conferencia sobre idiomas de muy alto nivel - que ahora no sé cuándo se interrumpió, no existió durante muchos años - y tuvo mucha repercusión. Terminamos este artículo en el verano de 1973.
Luego, en el otoño de 1973, comencé a trabajar en lo que se llamó CLU. Así que aquí estaba esta propuesta para un lenguaje de programación con solo algunos indicios de lo que podría contener y algunas declaraciones sobre "Sería bueno si tuviera polimorfismo". Sería bueno si tuviera un manejo de excepciones ". El manejo de excepciones también fue ... la gente estaba tratando de averiguar qué significaba eso en esos días. Esa era otra área en los lenguajes de programación en la que la gente estaba pensando pero no tenía una idea real de lo que debía hacerse. Entonces, el siguiente paso fue llegar a lo esencial y descubrir qué era todo esto.
En el otoño de 1973, reuní a tres estudiantes de posgrado: Russ Atkinson, Larry Snyder ... o Alan Snyder y Craig Schaffert, y ellos junto conmigo se convirtieron en los diseñadores de CLU. Solíamos tener una reunión grupal semanal donde todos nos reuníamos y estábamos trabajando en algún tema en particular como "¿Cómo debería ser el mecanismo de excepción?" O lo que sea que fuera el tema de la semana. Escribimos notas de diseño. En esos días, no los escribíamos online. Los escribías. Mi asistente, Ann Rubin, los escribía a máquina. Tuvimos un proceso de diseño muy riguroso y tuvimos una reunión grupal a la que asistieron bastantes más personas que solo nosotros. Entonces Steve venía, Jack Dennis solía venir. Otra gente. Alumnos de Jack. Así que teníamos un grupo bastante grande y simplemente nos esforzábamos ... Todo lo que veíamos intentaríamos verlo desde todas las direcciones posibles y descubrir "De estos dos enfoques, ¿cuáles son los beneficios? ¿Cuales son las desventajas?"
CLU estaba muy adelantado a su tiempo. No era solo que tuviera abstracción de datos, que nadie más la tenía. El único otro proyecto que se estaba llevando a cabo en el momento en que se estaba analizando la abstracción de datos fue Bill Wulf y Mary Shaw trabajando en un lenguaje llamado Alphard en CMU. Entonces también estaban investigando la abstracción de datos. Una gran diferencia entre ellos y nosotros era que yo venía del Lisp, creía en el heap (pila). Ellos estaban mucho mas en el mundo de ALGOL o en ... Hubo muchas discusiones en aquellos días sobre "Los punteros son malos". Entonces querían que todo estuviera en la pila. Por supuesto se puede evitar la recolección de basura, pero hizo que todo fuera mucho más complicado para ellos. Así que creo que los ralentizó. Mientras que yo venía del campo de Lisp. Yo creía en la recolección de basura, creía en la pila. No pensaba que los punteros fueran malos siempre que pudieras gestionar la verificación del tipo. Sin embargo, estaba muy a favor de la verificación de tipo fuerte, y como digo en mi charla, esto es en parte una reacción a Lisp, porque me pareció tan molesto que no hiciera una verificación de tipo estática, y puede ahorrar mucho tiempo en el proceso de desarrollo del programa si se tiene un buen compilador haciendo análisis estático.
Lisp tenía otra cosa que me influyó mucho, que era una compilación separada. Eso también fue muy importante. Desde el primer día, CLU siempre se compiló por separado. De hecho, nuestra idea era que primero pusieras en la biblioteca del programa una descripción de la interfaz de un módulo, y luego pudieras compilar el código que usó el módulo aunque el módulo aún no se hubiera implementado. Y si quisiera, se podría proporcionar una especie de simulación ingeniosa de la implementación como su primera implementación para saber si se quisiera ir más allá. Así que llevamos esta noción de compilación separada, la llevamos tan lejos como creímos posible.
CLU tenía abstracción de datos. Sabíamos que necesitábamos polimorfismo. Y el polimorfismo fue un desafío para nosotros debido al hecho de que cuando escribe un tipo de datos o un procedimiento que está parametrizado por algún tipo arbitrario T, a veces no todos los tipos arbitrarios son parámetros legítimos. Entonces, si estás hablando de un conjunto ordenado de T, entonces tienes que tener alguna forma de comparar los elementos T. Y no todos los tipos tienen una forma deordenarlos. Y no sabíamos cómo ... Y queríamos capturar esto estáticamente. No queríamos que esto fuera una especie de cosa dinámica que se descubriera en tiempo de ejecución: "Oh, falta la operación que necesitamos". Queríamos asegurarnos en el momento de la compilación existía tal operación.
Finalmente, inventamos lo que llamamos "cláusulas where" [cláusulas dónde], donde simplemente enumeraríamos el conjunto de operaciones con sus firmas requeridas que tuviera el tipo, y luego el compilador podría verificar en tiempo de compilación un uso que el tipo de parámetro proporcionado tuvieran las operaciones que fueran requeridas. Por supuesto, capturamos solo la sintaxis, no la semántica. Ya sabes, dijimos: "Tiene que tener una operación con un nombre como mínimo que ..." Con dos Ts devolviendo un Booleano, no dijimos que fuera una relación de orden. Eso habría sido parte de su especificación. Habría tenido que razonar sobre esto afuera. Pero eso es lo más lejos que puede llegar con un compilador, porque un compilador no razona. Sabes, puede hacer partes simples del razonamiento, pero no el razonamiento completo.
Curiosamente, hay algo llamado clases de tipos en Haskell y están fuertemente relacionadas con las "cláusulas where". Están cumpliendo los requisitos para un módulo polimórfico, diciendo: "Aquí hay un conjunto de operaciones, aquí están sus firmas", y luego se les puede poner una especificación. Pero CLU tenía estos allí como cláusulas where. Esa fue nuestra solución para el polimorfismo.
Teníamos un mecanismo de manejo de excepciones. Pensamos que las excepciones son muy importantes, porque desde el punto de vista de la metodología de programación, nos gustaría que las especificaciones de las operaciones estuvieran completas si fuera posible. No parcialmente sino completamente. Cubriendo todo el rango de posibles entradas. Dado que si alguna vez tiene a: "todo menos verdadero" como condición previa para su llamada, existe una fuente potencial de errores allí porque si alguien que usara su módulo lo olvidara, aún cubriendo todas las bases, entonces debería estar seguro de que esos errores no son posibles . Pero cuando se intenta hacer un procedimiento total, entonces tiene el problema que no puede regresar de la misma manera al espacio de entrada de datos. Por lo tanto, necesita alguna forma, pensamos, de llamar la atención antes al procedimiento que llama.
La forma en que las personas manejan este problema hoy e incluso cuando no tienen un mecanismo de excepción o piensan que es demasiado costoso usarlo, es que juegan un juego. Entonces dirán: "Bueno, devuelves un valor y una parte especial de este valor te dice lo que está sucediendo". Como "devuelvo un puntero a un objeto, pero si el puntero es nulo, esto significa algo". Y El problema es que esto es muy propenso a errores. "Devolveré un entero si el entero es negativo". Esto tiene un significado especial, pero la gente se olvida de probar. En cierto sentido, es lo mismo que tener una especificación parcial. Es un poco mejor, pero también es muy propenso a errores. Así que queríamos un mecanismo que le dijera al usuario, realmente empujar esos resultados a otra parte del programa.
Todo esto parece tan común hoy en día porque así es como funciona el mecanismo de Java, pero en aquellos días, no existía. Entonces inventamos esas cosas. Y nos preocupamos por muchos de los problemas con el manejo de excepciones. Uno de los problemas con las excepciones marcadas en Java es que a las personas no les gusta tener que escribir el código para manejar las excepciones que no sucederán en su programa. “Acabo de comprobar que mi índice está dentro de los límites, entonces, ¿por qué tengo que escribir una cláusula catch cuando llamo a la búsqueda? Porque sé que no va a suceder ". Así que lo manejamos convirtiéndolos en una excepción especial de falla.
Y luego la tercera parte de nuestro diseño fueron los iteradores. Es algo que no previmos al iniciar el proyecto. Los otros dos, creo que ya estaban en el documento original, pero los iteradores no eran algo que estuviera en mi mapa mental. Pero nos dimos cuenta de que necesitábamos un mecanismo de iteración porque muchas abstracciones de datos son colecciones, como conjuntos y mapas y cosas así, y cuando haces recolectas, generalmente es porque quieres hacer algo con la colección, que a menudo se está iterando sobre ella. . Aunque se pueden encontrar formas de hacer iteraciones en ausencia de un mecanismo, parecía más elegante tener un mecanismo. Y tal como he contado la historia muchas veces, fuimos a Carnegie Mellon, visitamos a Bill Wulf y Mary Shaw y su grupo. Nos explicaron sobre algo llamado generadores, que en realidad estaba surgiendo de las ideas de IA. Así que escuchamos esto y los generadores eran como los iteradores en Java hoy en día. Eran objetos con un montón de operaciones para iniciar la iteración, y así.
Entonces pudimos ver que esta era una buena solución, pero pensamos que era poco elegante y excesiva. Y así, en el avión que regresaba a Boston, mi estudiante Russ Atkinson inventó los iteradores, y los iteradores están diseñados para usarse con un bucle 'for'. Llama al iterador para iniciar el ciclo. Cada vez que tiene un nuevo valor para proporcionarle, utiliza una instrucción de devolución especial llamada 'entrega' [yield]. Luego ejecutamos el cuerpo del bucle. Al final del cuerpo del bucle, volvemos al iterador exactamente donde entregó, por lo que simplemente continúa en su flujo de control. Cuando no tiene nada más que entregar, regresa, y eso termina el bucle.
Es una forma limitada de rutina, porque no tiene la capacidad de mantener en funcionamiento, múltiples de ellas y así. Por ejemplo, no puede explorar dos árboles y verificar la misma franja usando iteradores. Tendrían que estar anidados. Pero decidimos, y esta es una especie de regla del 90% para el diseño del lenguaje de programación, la mayoría de las veces, este uso algo limitado de iteradores es lo que se necesitaría. Entonces, en lugar de tener un mecanismo más complicado que lo llevara más lejos, pero no fuera tan conveniente de usar en el caso normal, optaríamos por el mecanismo más simple. Y también fue agradable porque tenía una implementación muy eficiente en la que simplemente pasabamos el cuerpo del bucle como una rutina oculta al iterador, que llamaba cada vez que entregaba. Todo muy sencillo.
Entonces eso fue CLU. Y para 1978, teníamos un compilador que funcionaba bien, teníamos un idioma, teníamos un manual de referencia, teníamos usuarios. Se estaba utilizando en más de 200 sitios concretos. Estaba siendo utilizado para construir software grande.
Debo decir que fue importante diseñar un lenguaje por varias razones. Una fue que la gente tiene que escribir programas en el idioma para poder saber si se han implementado los mecanismos correctos. A nuestros usuarios, si no les hubiera gustado algo, se habrían quejado y entonces pensaríamos si nuestros mecanismos habían sido lo suficientemente potentes.
Pero el rendimiento importa. Por lo tanto, se debe pensar en: "¿Qué coste tiene?". Por ejemplo, en nuestro mecanismo de excepción solo cuesta aproximadamente el doble de tiempo señalar una excepción que hacer un retorno normal. Si los mecanismos de excepción fueran costosos, que desafortunadamente es lo que acostumbra a ocurrir en los lenguajes modernos, la gente no hubioeran querido usarlos. Aunque pudieran estar muy equivocados. Quiero decir que podría ser que el hecho de saltar una excepción no ocurriera muy a menudo, por lo que si observara el rendimiento general del programa, el costo de la excepción no importaría mucho, tal vez. Pero consideramos que era importante contar con un mecanismo de excepción eficiente para que esa barrera de uso no existiera.
Y, por cierto, una vez que existen las características, ahora puede comenzar a simularlas en otros idiomas y la gente seguirá viendo que es una abstracción de datos. Entonces, durante muchos años en el 6.001, nuestro curso introductorio que desarrolló Gerry Sussman, enseñaban la abstracción de datos, pero básicamente usaban un registro de punteros para (proporcionar) los métodos del tipo de datos. Y cundo ya existe la abstracción de datos, entonces se puede ver que ese es el camino a seguir. Entonces todo va bien.
Esa es realmente la historia de CLU. Y llegó el 1977 o 1978 y CLU estaba casi terminado, y empecé a pensar qué hacer a continuación. En ese momento, ya había comenzado a enseñar 6.170.
- ¿Qué es eso?
6.170 durante muchos años fue el segundo curso de programación en nuestro plan de estudios. Y Corby y otras personas en el departamento me pidieron que desarrollara este curso y pensaron que lo necesitábamos. Entonces, nuestros estudiantes comenzarían con 6.001, que se impartió en Lisp, o Scheme en realidad, y aprendieron a construir pequeños programas. Y la idea en el curso 6.170 era: "Está bien. y ahora, ¿cómo se construyen buenos y grandes programas?"
Entonces desarrollé este curso. Todo se basó en ... Se trataba de metodología de programación, cómo se diseña, cómo se usa la abstracción de datos, cómo se hace el diseño modular. Realmente estaba en línea con mis intereses, y lo enseñé durante aproximadamente - déjame pensar, '77 - probablemente 20-25 años, algo así. Hasta en el día de hoy sigo haciendo que la gente me diga lo importante que fue para ellos, el impacto que tuvo en su carrera, porque realmente enseñó a los estudiantes cómo pensar sobre el diseño modular y cómo organizar un gran proyecto.
Y todavía lo enseñamos. Simplemente se transformó en otro curso, que ... Fue demasiado trabajo para los estudiantes. Este es un problema de MIT en general: los cursos dan demasiado trabajo a los estudiantes. Entonces intentaron dividirlo. No estoy segura de que esto haya sido terriblemente exitoso. Tengo la sensación de que estos cursos tienden a ... añadir más y más material que se acumula en el curso a medida que se desarrolla.
También pensé en la comercialización, pero decidí que ... En estos días, tal vez podría comercializar publicando cosas en la web y la gente comenzará a recogerlo y tal vez haya usuarios que contribuyan a la implementación, etc. Creo que todavía es muchísimo trabajo. Creo que las personas que lo publican terminan pasando la mayor parte de su tiempo enfocados en eso. Entonces no es realmente investigación. Es mucho más desarrollo. Así que no parecía una muy buena dirección para entrar.
Estaba mirando a mi alrededor pensando en qué hacer, y comencé a pensar en ARPANET. Y realmente no lo sé, no recuerdo qué fue lo que me hizo ver este problema que estaba al acecho en ARPANET. No fue un problema lo que inventé. Bob Kahn había estado escribiendo documentos sobre ARPANET. Entonces, en aquellos días, la gente enviaba correos electrónicos, la gente hacía FTP, la gente hacía un inicio de sesión remoto. Eso fue lo que se hacía en Internet, y ya se estaba usando el correo electrónico. Quiero decir que la gente me dice que el correo electrónico no existíó tan pronto, pero existió en los años 70 porque yo lo estaba usando. Pero había un sueño de escribir programas distribuidos donde tendrían componentes ejecutándose en diferentes computadoras y se comunicarían enviandose mensajes, y nadie sabía cómo hacerlo. Entonces pensé: "Ah, este es un gran problema", y entonces me lancé a la computación distribuida.
Esto fue a finales de los años 70. Acabo de cambiar de dirección. No cambié totalmente porque todavía estaba trabajando en el curso 6.170. Había estado pensando en "¿Cómo razonar sobre la validez de los tipos de datos abstractos? ¿Cómo se escriben especificaciones para tipos de datos abstractos? ”Mucho de esto fue enseñado a los estudiantes en mi curso. Yo también estaba...
- Si puedo, te detendré por un momento.
- [Mucho de esto estaba relacionado con tus alumnos ...]
Pensé que era irónico de una manera que decidí no investigar la concurrencia cuando estaba trabajando en CLU porque ya tenía suficiente en mi plato y eso hubiera sido una gran distracción. Cuando llegué a la informática distribuida, por supuesto, la concurrencia regresó, así que volví a pensar en la concurrencia nuevamente, ya que claramente tienes todas estas computadoras y todas están trabajando en paralelo, etc. En cierto modo, la informática distribuida es un gran lugar para pensar en términos de tipos de datos abstractos porque aspira a tener diferentes objetos ejecutándose en diferentes máquinas, se van a comunicar.
Una de las cosas en las que estaba pensando en los primeros días de este primer proyecto, que fue el proyecto Argus para desarrollar un lenguaje para implementar estos programas distribuidos, fue "¿Cuál es el mecanismo de comunicación?" Terminé fuertemente del lado del procedimiento de llamada remota. Es decir, en una máquina remota tengo un objeto, que proporciona operaciones, y desde aquí llamo a esas operaciones. Y luego, debajo de la tapa, las cosas pasan. Argus era un sistema de un solo lenguaje, por lo que hubiéramos podido ... Si está ejecutando en una máquina y tiene un lenguaje, puede hacer una llamada al procedimiento remoto de forma mucho más eficiente que si se preocupa por máquinas heterogéneas , diferentes lenguajes de programación, etc.
De todos modos, comencé a trabajar en informática distribuida y eso fue un largo recorrido. En los años 80 y 90 tuve algunos estudiantes estupendos. No estoy segura de qué hablar allí. Sus...
- Bien, veamos. ¿Quién te influyó? ¿Estabas ... ¿Qué tal Lampson? ¿Era él un ... sus cosas en Xerox? O...
Bueno, definitivamente en este punto estaba yendo a conferencias sobre sistemas operativos. Ciertamente, yo ... Otro curso que enseñé en el MIT fue 6.033, el curso de sistemas. Lo dí muchas veces. Y también Multics y varios sistemas operativos, todo eso.
- Correcto.
- Cierto. Y luego Lampson y Sturgis con el almacenamiento ...
El almacenamiento estable, pero eso fue realmente mucho más un tema de 6.033 que un tema de Argus. Entonces, lo que hicimos en Argus fue que trajimos transacciones al lenguaje de programación. Estábamos interesados en el punto de que cuando realiza una de estas llamadas a procedimientos remotos, no puede estar seguro de que obtendrá una respuesta porque está hablando con una máquina diferente y podría haber una razón por la cual la comunicación no funcione, y nunca sabrás cuál es esa razón porque es posible que no se haya esperado lo suficiente la respuesta o que realmente no esté disponible. De acuerdo? Esta es la belleza y lo horrible de la informática distribuida. Creo que era algo bueno para mí, que solo tienes que tener una mentalidad en la que la falta de respuesta no te diga nada, ¿vale?
El problema es que estoy en el lado de la llamada y no quiero esperar para siempre, ¿qué debo hacer? Bueno, lo que pensamos que ocurre es que estás ejecutando una pequeña subacción y la anulas, y eso significa que aunque sucediera allí, realmente no ha sucedido y, por lo tanto, no tienes que preocuparte por eso. Podrías probar una técnica alternativa o así.
Esa fue la gran originalidad del Argus. Funcionaba todo con transacciones. Así que teníamos objetos que eran instancias de tipos de datos. Corrían en máquinas individuales. Y luego ejecutábamos los cálculos como transacciones, y cada vez que realizábamos una llamada remota, la ejecutábamos como una subacción. Esa era forma de actuar de Argus. No creo que fuera necesariamente una buena idea porque era complicado y costoso. No estoy segura de que hiciera las cosas de la misma manera si lo hiciera hoy. Probablemente usaría un modelo de computación mucho más simple.
Sin embargo, una cosa interesante, una historia sobre Argus, es que X-Windows salió de Argus. Bob Scheifler estaba trabajando para mí. Fue uno de los dos miembros del personal que fueron grandes implementadores para nosotros. Es un implementador maravilloso. Necesitábamos una forma de depurar los programas distribuidos que estás ejecutando, y a él se le ocurrió X-Windows porque lo que era bueno era que podías tener una ventana aquí mirando eso ... los llamamos "guardianes", estos objetos por aquí y otro por allá mirando a este guardián. Por lo tanto, nos proporcionó un entorno de depuración muy agradable.
Entonces Jerry Saltzer había estado a cargo del Proyecto Athena y Kerberos había salido de eso. Ese fue un gran éxito porque era de dominio público, por lo que Mike Dertouzos pensó: "Bueno, intentemos convertir X en dominio público", así que formamos el Consorcio X. Esto fue algo así como el comienzo de Windows siendo la forma en que manejar tu sistema en un mundo distribuido. No fueron las primeras ventanas. Había algo llamado W, creo, que las precedieron. W, X - "X" está detrás de "W." Pero fue solo una pequeña luz interesante sobre lo que estaba sucediendo. No fue mi invento, fue de Bob.
Entonces implementamos Argus. Quiero decir, en este punto, estamos tratando de dar algo de sentido a "¿Qué son los sistemas distribuidos?" Y hay mucho trabajo en la comunidad de los sistemas operativos, la gente está pensando en "Tal vez solo tengo una gran pila, y los programas se ejecutan y comparten estos objetos en la pila ". No estoy segura de que este trabajo realmente hubiera tenido ninguna transcendencia en el sentido de: "la gente está creando programas utilizando Argus", porque lo que sucedió fue que apareció el gran modelo RPC. La idea era construir los componentes, que se comunicaran a través de una interfaz que se describe en la biblioteca, y el software los conecta para obtener heterogeneidad. El rendimiento no es excelente, pero esa fue la idea.
De todos modos, trabajé en Argus y luego los estudiantes que trabajaban para mí en ese momento, estábamos pensando en la abstracción de datos y la concurrencia. Entonces, Bill Weihl escribió una tesis sobre la conmutatividad y cómo puede usar la especificación de un tipo de datos abstractos para determinar cuánta concurrencia está permitida. En una base de datos en ese momento, utilizaron el bloqueo de dos fases. Ese es un mecanismo que no entiende de significados. Es solo una técnica que se puede usar y que garantizará la serializabilidad. También había un control de concurrencia optimista - no se usó tanto entonces, pero se usó mucho más tarde -. Pero la idea de Bill era: "Si entiendo la semántica de las operaciones, puedo obtener más concurrencia de la que permitirían estos mecanismos de control de concurrencia que no entendieran la semántica". Así que ese fue un trabajo inicial que surgió de ese grupo.
Luego, otra cosa que sucedió en los años 80 fue que inventamos lo que es esencialmente Paxos. Inventamos algo llamado "replicación con sello de vista" [viewstamped replication] , este fue otro de mis alumnos, Brian Oki, porque estábamos interesados en la fiabilidad y la disponibilidad. Quiero decir que pensé en la informática distribuida como una bendición y una maldición. Si su máquina se cae en un sistema no distribuido, no puede hacer nada hasta que vuelva. Con un sistema distribuido, podría tener cosas en otro lugar, así que tal vez podría continuar trabajando.
Por otro lado, si tienes cosas en otro lugar y no tienes una forma de controlarlas, entonces hay más de una falla que puede hacer que dejes de trabajar, así que ¿qué hacer al respecto? Se nos ocurrió una técnica de replicación para garantizar que todo funcionara correctamente, y siempre que f de 2f + 1 nodos funcionaran ... Entonces sí.
- Bueno. Entonces, ¿por qué no nos hablas sobre el: "Principio de sustitución de Liskov"?
Esto fue algo interesante que sucedió en los años 80. Al mismo tiempo que estaba desarrollando CLU y Bill y Mary estaban trabajando en Alphard, Alan Kay y Adele Goldberg estaban trabajando en Smalltalk en la costa oeste. Aunque puede parecer un poco extraño en estos días, en esos días era un largo camino desde la costa este hasta la costa oeste, y por supuesto, tampoco teníamos videollamadas de conferencia en esos días. Todo ese asunto relacionado con la programación orientada a objetos se estaba desarrollando en la costa oeste y en la costa este, estábamos trabajando principalmente en la abstracción de datos, y los dos mundos estaban algo separados. Entonces yo sabía el nombre, pero no nos encontramos en las conferencias y no había mucho diálogo [crosstalk].
En la década de 1980, me pidieron que diera una conferencia en OOPSLA, que creo que tal vez fue la segunda OOPSLA. No hacía mucho tiempo que existía. Así que decidí que esta era una buena oportunidad para aprender sobre lo que estaba sucediendo en los lenguajes orientados a objetos. Entonces comencé a leer todos los documentos y descubrí que la jerarquía se estaba utilizando para dos propósitos diferentes. Uno era simplemente herencia. Entonces, tengo una clase, implementa algo, puedo construir una subclase, puedo tomar prestada toda esa implementación, cambiarla como quiera, agregar algunos métodos adicionales, cambiar la representación. Lo que sea que quiera hacer, simplemente tomo prestado el código y sigo trabajando en ello.
La otra forma en que se usaba era para la jerarquía de tipos. Entonces, la idea era que la superclase definiría un supertipo, y luego una subclase lo ampliaría para convertirse en un subtipo. Pensé que esta idea de la jerarquía de tipos era muy interesante, pero también sentí que no la entendían muy bien. Recuerdo haber leído documentos en los que estaba claro que estaban muy confundidos al respecto, porque uno en particular que recuerdo dijo que una pila y una cola eran ambos subtipos entre sí. Esto claramente no es cierto porque si has escrito un programa que esperaba una pila y obtienes una cola, te sorprendería mucho su comportamiento. La diferencia entre LIFO y FIFO es un gran problema.
Esto me llevó a comenzar a pensar en "¿Qué significa realmente tener un supertipo y un subtipo?" Y se me ocurrió una regla, una regla informal que presenté en mi conferencia en OOPSLA que simplemente decía que un subtipo debería comportarse como un supertipo, por lo que puede ver, utilizando los métodos de supertipo. Entonces no era que no pudiera comportarse de manera diferente. Es solo que mientras limite su interacción con sus objetos a los métodos de supertipo, obtendrá el comportamiento que esperaba.
Esta definición informal aquí dada fue basada en la intuición. Es intuitivamente correcta en algún sentido. Puedes ver cómo entiender el supertipo, escribes un código en términos del supertipo, cualquier objeto que obtengas debe comportarse de la manera que esperas. De lo contrario, ¿cómo se puede hacer este razonamiento independientemente del comportamiento?
Más tarde, Jeannette Wing, quien en realidad había sido estudiante de mi maestría, y luego John Guttag, estudiante de doctorado, se acercaron a mí y me dijeron: "¿Por qué no tratamos de averiguar exactamente qué significa esto?". Así que trabajamos juntos en esto en unos artículos que se publicaron un poco más tarde.
Mientras tanto, estaba trabajando en computación distribuida, estaba particularmente interesada en la "replicación con sello de vista" [viewstamped replication] y algunos de los otros trabajos que se estaban realizando en mi grupo en ese momento, y realmente no estaba pensando en esto hasta que en algún momento en los años 90 recibí un correo electrónico de alguien que dijo: "¿Puede decirme si este es el significado correcto del Principio de Sustitución de Liskov?" Entonces, esa fue la primera vez que tuve alguna idea [risas] de que existía tal cosa, y que este nombre se había propagado. Técnicamente se llama "subtipo de comportamiento". Ya sabes, dice que los subtipos se comportan como supertipos. Entonces pensé que era muy divertido. Descubrí que había mucha gente en Internet discutiendo sobre el significado del principio de sustitución de Liskov. Así que fue bueno tener algo que tuviera un impacto como ese. Diría que combina la abstracción de datos con la jerarquía de tipos y así ya se tiene una programación moderna orientada a objetos.
Pero eso fue una pequeña desviación del trabajo que estaba haciendo, que era todo computación distribuida. Trabajé en informática distribuida durante los años 80 y 90. Y es un poco difícil recordar todos los diferentes proyectos que estaban en marcha. En algún momento, a principios de los años 90, comencé a trabajar en el proyecto Thor, que en cierto sentido era lo opuesto a Argus. Entonces Argus era un proyecto en el que los objetos eran los componentes del sistema distribuido. Thor era un proyecto en el que tenía un modelo cliente-servidor, los objetos se almacenaban en los servidores y los clientes interactuaban entre sí solo mediante el uso de los objetos.
Por lo tanto, era mucho más una vista de base de datos del mundo que Argus. Y todavía estábamos ejecutando transacciones, pero ahora eran transacciones ... no se distribuyeron transacciones como en Argus. Eran transacciones de una máquina en las que un cliente se ejecutaba contra los objetos en los servidores y al final confirmaba o cancelaba, y eso causaría un cambio en el estado global. Y creo que esa podría ser una forma más productiva de crear aplicaciones. Ese era realmente un sistema orientado a objetos en lugar de un sistema de base de datos. Utilizamos una forma muy interesante de control de concurrencia optimista e hicimos mucho trabajo en la gestión de caché y otras técnicas que hicieron que el sistema funcionara bien.
Como saben, el rendimiento está sobrevalorado en la mente de los informáticos. Por otro lado, el rendimiento es muy importante cuando construyes una plataforma sobre la que te gustaría que las personas crearan aplicaciones. Por lo tanto, importa mucho en un sistema operativo. E importaría mucho en un sistema como Thor o Argus porque se esperaría poder construir en la parte superior, y cualquier problema con el rendimiento que existiera en el nivel de implementación de la plataforma se multiplicaría cuando se acediera al nivel superior.
En los años 90, además del trabajo en Thor, mi grupo hizo otras dos cosas que pensé que eran notables. El primero fue la tolerancia a faltas bizantinas y el otro fue el control descentralizado del flujo de información. El primero ... No estoy seguro exactamente el orden en que sucedieron. Probablemente fueran simultáneos. El primero sucedió con mi alumno Miguel Castro. Lo que sucedió fue que vi una solicitud de propuesta de DARPA hablando de intrusos maliciosos en Internet y qué se podría hacer para contrarrestar su impacto. Y se lo di a Miguel. Le dije: "Piensa en esto. Mira si puedes pensar en algo interesante que podamos proponer hacer ". Y él pensó:" Bueno, tal vez deberíamos considerar esta cuestión de la replicación en presencia de ataques bizantinos ", y esto finalmente se convirtió en ese trabajo sobre tolerancia a fallas bizantinas.
- Entonces deberíamos decir qué significa "bizantino".
"Bizantino" significa faltas arbitrarias. El trabajo que hice en los años 80 en la 'replicación con sello de vista', también conocido como Paxos, asumió faltas benignas donde una computadora estaba funcionando o no. Ya sabes, llegó un mensaje o no llegó. No estaba distorsionado de alguna manera. La computadora falló al estrellarse o estaba funcionando correctamente. Ya sabes, el mensaje llegó intacto o no llegó en absoluto. O tal vez llegó y no estaba intacto, pero lo reconociste de inmediato y pudiste tirarlo.
Con faltas bizantinas, la computadora sigue funcionando. Ya no funciona correctamente, pero funciona de todas formas. Por supuesto, esto sucederá la mayor parte de las veces y se podrá saber que no se está ejecutando correctamente, porque hará cosas raras, pero una falla bizantina real es aquella en la que continúa funcionando y parece que está bien. Y hubo ejemplos de que esto sucedió. Por ejemplo, probablemente esté al tanto de las cosas que estaban sucediendo en la comunidad de redes donde un pequeño cambio en un mensaje causó todo tipo de problemas en el enrutamiento del mensaje y todo esto.
Y debería decir en este momento que, como todos los demás que conozco en el tipo de comunidad informática general, no lo vi venir. No tenía idea de que íbamos a pasar de estas computadoras que mis amigos estaban usando a algo donde todo el mundo comenzó a usarlo. Esa fue una transformación sorprendente.
De todos modos, cuando esto se convirtió en algo que todo el mundo estaba usando, entonces el problema de los malos actores que tratarían de lanzar ataques a las computadoras de las personas para fines que hoy conocemos haciendo cosas realmente malas, como cifrar sus archivos y luego exigir chantaje para darte la llave y cosas así.
Entonces Miguel y yo trabajamos en este problema, cómo hacer un protocolo práctico. Para una falta benigna, necesita réplicas 2f + 1. Entonces, para manejar una réplica incorrecta, necesita 3. Para Bizantino necesita 3f + 1. Por lo tanto, necesitaría cuatro. Y también necesitas un protocolo más complicado. Y estoy convencida de que una de las razones por las que pudimos descubrir cómo hacer esto fue porque habíamos hecho una 'replicación con sello de vista' en mi grupo antes, y mirando hacia atrás tal como sucedieron las cosas, veo la tolerancia a fallas bizantinas como la 'replicación con sello de vista' un poco extendida. Tiene una fase adicional en el protocolo, tiene una réplica adicional, pero está bastante relacionada. Así que creo que esto nos ayudó a Miguel y a mí cuando estábamos tratando de descubrir cómo hacer que esto funcionara, ya que teníamos esos antecedentes de los que dependíamos.
La otra derivación importante fue el control descentralizado del flujo de información. Este fue el trabajo que hice con mi alumno Andrew Myers. Para la seguridad en los sistemas, siempre ha habido dos enfoques diferentes. Control de acceso, que controlaba a qué programa se puede acceder o qué usuario estaba autorizado a acceder, pero una vez que se podría acceder a algo, se podía hacer lo que quisiera con él. El control del flujo de información no controló el acceso. Controlaba lo que podía pasar con la información después del hecho. Entonces, si tenía derecho a leer archivos secretos, y esto surgió de este tipo de trabajo en el ejército, entonces no se le permitiría exponer esa información, a no ser a donde la información secreta pudiera ir. Lo que importaba no era el control de lo que mirabas, sino el control de lo que hacías con ello.
Estos sistemas siempre se habían basado en una noción centralizada de quién tenía el control de las cosas. Había Top Secret, había Secret, había Confidential. Alguien clasificaba todo y luego el sistema simplemente seguía las reglas basadas en ese tipo de nociones centralizadas. Lo que hice con Andrew fue descentralizar esto para que los usuarios individuales pudieran poner etiquetas en sus datos en función de sus propios deseos para el control y luego hacer que todo funcionara de la misma manera, controlando el acceso. Y eso llevó bastante trabajo en lenguajes de programación y sistemas operativos después del hecho. Trabajamos en Thor y trabajamos en estas dos interesantes direcciones, e hicimos un trabajo de lenguaje de programación también, especialmente con Andrew, que era una persona de lenguajes de programación que trabajaba en mi grupo.
Eso nos llevó a finales de los 90. Luego me tomé un par de años libres y trabajé para una startup solo para ver cómo era. Era una startup llamada SightPath en la que trabajé y poco tiempo despues de haber entrado fue comprada por Cisco, y acabé trabajando allí durante dos años. Diría que trabajar en una empresa no era lo que mas me interesaba, así que regresé al MIT y me convertí en jefa de la parte de informática de nuestro departamento. Continué trabajando en computación distribuida, desarrollé un sistema llamado Aeolus, que era un sistema descentralizado de control de flujo de información con un componente de lenguaje de programación. Luego comencé a trabajar en la administración en el MIT. Fui Rector Asociado de Equidad de Facultad. Eso fue lo que sucedió en la década de 2000.
Entonces decidí retirarme, y me retiré hace un par de años. Pero en 2012 dejé de trabajar en informática distribuida y desde entonces he estado trabajando en lenguajes de programación y máquinas multinúcleo solo para continuar ... Me gusta moverme y decidí que era hora de moverme alrededor por un tiempo, mientras que he estado haciendo esto.
Así que eso es lo que he hecho.
Creo que me ayudó cuando estaba en el puesto. Creo que este es el tipo de cosas a las que debes prestar atención, tiene que venir desde arriba, y si dejas de prestarle atención, creo que las cosas se deslizarán. Así que no ... hice mi parte y ahora se la he pasado a otros.
Bueno, tengo una familia, así que me casé. Se puede tener una carrera y una familia. Ese es un mensaje que siempre trato de transmitir a las mujeres jóvenes. Tengo un hijo. Tengo una nieta Tuve a mi hijo antes de ser titular. Sentí que "encontraré una manera de hacer que esto funcione". Creo que, de hecho, es una muy buena manera de manejar tu vida. En lugar de pensar detenidamente en todas las cosas que podrían salir mal y preocuparse por ello, simplemente imagina que lo podras hacer funcionar de alguna manera. No lo sé. Mi hijo es un informático. [risas] Aunque él está más en el lado teórico que yo.
- Interesante
- Bien, veamos. Has ganado muchos otros premios.
Sí. Bueno, gané la Medalla von Neumann del IEEE en realidad unos años antes de recibir el Turing, y también obtuve algo de honor ... Sabes, tengo ... Sí. Creo que hay una tendencia una vez que obtienes un premio, más o menos vienen más.
- Tienes un título honorífico de ETH.
Si, es así. Ese fue el primer título honorario que obtuve. Entonces, como saben, ETH es una de las mejores escuelas de Europa y una buena escuela de ciencia y tecnología, así que sí.
Y la otra cosa sobre el Premio Turing es que te llaman para viajar mucho. Entonces, en la pareja, dos o tres años después, viajé y viajé y viajé por todo el mundo. Y todavía sucede, aunque no tanto como antes. Así que ha sido muy divertido. Y mi esposo vino conmigo, así que hemos podido experimentar eso juntos.
- Entonces, ¿cuales fueron los lugares más importantes que fuiste?
China. India. Estaba pensando ... Así que hemos estado en el Lejano Oriente varias veces. Por supuesto, hemos estado en Europa en muchos lugares. El único lugar donde no he estado al que me gustaría ir es África. Pero sí, parece que hubo un tiempo en el que viajé mucho. Creo que es en parte, que cuando obtienes el Premio Turing, esperas que esto suceda y realmente necesitas hacer ese viaje. Es una especie algo incluído en él. Sí.
- Bueno, ¿hay otras cosas que no cubrimos que deberíamos tener?
[risas] Me parece que hemos hecho un buen trabajo cubriendo cosas.
- Bueno, entonces ... Gracias. Muchísimas gracias por su tiempo.
Gracias por tu tiempo. Ha sido divertido. Gracias.
Twitter: https://twitter.com/macajo/status/1195693508457316353?s=20https://twitter.com/macajo/status/1195693508457316353?s=20https://twitter.com/macajo/status/1195693508457316353?s=20ttps://twitter.com/macajo/status/1195693508457316353?s=20
No lo hice, no. No fui a muchas reuniones en este momento. Más tarde estuve trabajando
Grupo 2.3, 2.5, el grupo de trabajo de metodología. Pero nunca encontré ese tipo de
formato útil para mi. Tiendo a ser más "trabajo solo". Pero leí procedimientos de estas reuniones y aprendí sobre lo que estaba pasando, y Empecé a pensar en metodología. Como digo en mis conversaciones de Turing, también estaba mirando a varias personas, Dave Parnas, por supuesto, era otro gran gran jugador, y leí todos los papeles que pude conseguir y pensé en sus propuestas de metodología. En algún momento durante este proceso, me di cuenta de que yo había inventado una metodología propia mientras trabajaba en el sistema Venus, no porque estuviera pensando en sino solo porque quería una forma de organizar ese software, que nos dio una forma sensata de abordar el proceso de desarrollo de software.
La idea que tuve en Venus fue que ... me refiero a entender esta vez los antecedentes, tienes que entender que había esa escuela ALGOL de programación que tuvo una buena idea y una mala idea. La buena idea fue que tenías bloques y el bloque interno tenía datos privados y el bloque externo no podía acceder eso. La mala idea era que tenías bloques [risas] y el bloque interior podía libremente acceder a todas las cosas en el bloque exterior, por lo que hubo una tendencia natural a comunicarse a través de variables globales. Esa no fue una gran idea. Algunos de los documentos de Parnas hablaron un poco sobre por qué era una mala idea, aunque no lo quisiera decir que en general se entendiera que era una mala idea.
En cualquier caso, de alguna manera entendí que no era una gran idea, y creo que tiene que ver con el hecho de que si tienes muchas personas trabajando en diferentes piezas de la sistema y todos pueden comunicarse libremente a través de este conjunto de variables globales, vas a tener un gran desastre en tus manos. Y tal vez vi un desastre como eso en las cosas de Harvard. Realmente no estoy segura de dónde vino. Pero decidi no íbamos a compartir variables globales en el desarrollo del sistema de Venus. En su lugar, íbamos a dividir el espacio variable global en lo que llamé "particiones", y cada partición estaría a cargo de un módulo de programa particular, y ese módulo sería el único lugar donde podría acceder a esos datos. Y si otras partes del programa tuvieran que usarlo, ese módulo proporcionaría procedimientos que otras partes del programa podrían llamar. Esta es la metodología que utilizamos y funcionó extremadamente bien.
Otra cosa que estaba sucediendo en Venus, de la que generalmente no hablo en mi charla de Turing, es que también estábamos pensando en la pregunta "¿Cómo organizar un programa paralelo como un sistema operativo? ¿Y cómo controlas en particular los dispositivos, los recursos compartidos? ¿Cómo te comunicas entre los hilos que están haciendo el procesamiento concurrente? ”Y ya estaba usando tipos de datos abstractos. Estaba pensando en términos de la forma en que el subproceso hace uso del recurso compartido, que en realidad es un objeto con un montón de operaciones, y llamamos a ese objeto y tiene algunos recursos ocultos que utiliza para clasificar. ... está siendo compartido por todos los hilos y así es como sucede realmente el control.
Aunque no lo expliqué en el primer artículo que escribí sobre metodología de programación. Ni siquiera estaba pensando en eso hasta el Día de la Historia SOSP (ACM Symposium on Operating Systems Principles) donde di una charla sobre la historia de la estructura del programa en los sistemas operativos y volví a mirar el sistema THE (Dijkstra), miré el sistema Venus, y luego allí estaba Schroeder y Nelson, o Nelson y Birrell, el documento sobre las dos formas de organizar un programa paralelo, una donde tienes colas y la otra en la que envías mensajes. Estaba mirando algunos de esos documentos de metodología y me di cuenta de que Venus era en realidad uno de los que estaban en la mezcla y que tenían dos estructuras: una con recursos compartidos en el que los hilos solo llaman a operaciones y todo se soluciona bajo las sábanas, y esta otra estructura en la que proporcionas ... es una especie de estructura similar a CSP en el que tienes tu hilo y hay un montón de métodos que son llamados de forma remota. Es un modelo diferente de computación. Entonces Venus tenía ambas cosas. Estaba en el recurso compartido, en el que simplemente llamabs a sus operaciones. De alguna manera se deducía de forma natural de la idea de particiones y solo operaciones de llamada.
Bueno. Así que estaba pensando en la metodología y me di cuenta de que tenía una metodología, así que escribí un artículo sobre ella y que entró en la Junta de Otoño, creo que fue en 19 -... Creo que probablemente se publicó en el '71 o '72 . Pero mientras tanto, también había escrito [un] artículo sobre Venus, y lo presenté a SOSP. Fue el tercer SOSP. Y fue aceptado. [The Design of the Venus Operating System]
Por cierto, esa fue la primera experiencia de escritura que tuve en la que alguien leía mi artículo y me criticaba. Porque John [McCarthy] no hizo eso. Nunca había tenido esa experiencia. Como estudiante de posgrado, nunca tuve un asesor que trabajara conmigo y me dijera: "Oh, esto no tiene sentido. Reorganizar eso ", y así sucesivamente. Fue muy útil. Ese era mi jefe, Judy Clapp. Había sido personal técnico en Mitre incluso antes que yo, y tiene historias muy interesantes que contar. Ella estaba cumpliendo ese papel y fue muy valioso.
De todos modos, el documento sobre Venus fue aceptado. SOSP, como saben, es la mejor conferencia de sistemas. Fue incluso en esos días, a pesar de que era solo el tercero, porque era el único acto en la ciudad. Jerry Saltzer fue el ... Yo fui uno de los premios. Siempre han tenido esta tradición de los mejores artículos, los premios, y entran en ... solían ir a las Comunicaciones. Ahora entran en TOCS. [Transactions on Computer Systems (TOCS)]
Así que Jerry fue el presidente de mi sesión, y Corby estaba allí, el profesor Corbató. Y no estoy seguro de quién más del MIT estaba allí. Probablemente otras personas del grupo Multics. Y después de mi charla me invitaron a postular al MIT. Entonces creo que hablé con Jerry. Me animó a presentar una solicitud, así que lo hice. También solicité admisión en Berkeley, y probablemente podría haber ido a Berkeley, pero mi esposo no estaba dispuesto a mudarse. Estábamos casados para entonces y él trabajaba para Raytheon y no parecía que fuera fácil para él. Ciertamente no en el área de Berkeley. Podría haber sido capaz de hacer algo en la península. Así que me mudé al MIT en el otoño de 1972. Y al mismo tiempo, Mike Schroeder fue contratado, por lo que contrataron a dos personas en sistemas.
Creo que fue el Título IX el que abrió las cosas para las mujeres. Mi comprensión de lo que había sucedido fue que el paisaje había cambiado. De repente hubo más presión sobre las universidades para contratar mujeres. No creo que todas las universidades estuvieran prestando mucha atención a esto, pero el MIT estaba prestando atención. Creo que venía de Jerry Wiesner, quien era el presidente del MIT, porque este tipo de cosas tiene que venir desde arriba. Jerry estaba realmente interesado en aumentar el número de mujeres. El jefe del departamento de EE - no era EECS todavía, solo era EE - era Louis Smullin, y creo que Louis estaba interesado en hacer esto. Entonces Bob Fano era el jefe de ciencias de la computación, y Bob definitivamente estaba interesado en hacer esto. Estaban buscando una mujer y allí estaba yo. Por lo tanto, fue un intercambio mutuamente beneficioso. Tan pronto como recibí la oferta, supe que iba a dejar Mitre. Era algo que supongo que siempre pensé que sería divertido hacer, y decidí que lo haría.
Entonces llegué al MIT. Solo había 10 mujeres en la facultad de una facultad de mil. Como saben, desde que vas al MIT, el número de mujeres en la población de pregrado era muy, muy pequeño. Mi esposo es de la clase de 1960 y había 16 mujeres en su clase. Quiero decir, muy pequeño, es realmente, ya sabes ... MIT siempre admitió mujeres, pero nunca tuvieron muchas, en parte porque no tenían una vivienda para ellas y por eso no sabían qué hacer con ellas. Eso cambió cuando ... Olvidé el nombre de la mujer que dio dinero para un dormitorio para mujeres [McCormick Hall lleva el nombre de Stanley A. McCormick, el esposo de Katherine Dexter McCormick '04, quien fue el benefactor del edificio], y tan pronto como tuvieron más espacio, comenzaron a dejar entrar a más mujeres. Eso fue en los años 70 o tal vez tarde. 60s. No estoy seguro exactamente cuándo.
- ’60s.
¿Eran los años 60? Sí. Así que fui al MIT en el otoño de 1972 y fue un movimiento maravilloso para mí. La gloria de trabajar como profesor universitario es que puedes hacer lo que quieras, ¿verdad? Vas a un lugar como el MIT, tienes ciertas responsabilidades. El MIT está muy enfocado en la enseñanza y la enseñanza de calidad, y todos imparten dos cursos al año, y eso lleva tiempo y hay que prestar atención a eso. Pero en lo que respecta a la investigación, usted se da cuenta sobre qué está investigando.
Por supuesto, también hay un inconveniente en esto. En primer lugar, es mejor que tengas las ideas. Tienes que haber imaginado lo que vas a hacer. Puedes hacerlo, pero tienes que saber qué es y luego tienes que recaudar dinero. Pero recaudar dinero fue bastante fácil en esos días porque esos fueron los días en que DARPA estaba apoyando la investigación en ciencias de la computación y principalmente estaba poniendo su dinero en algunas instituciones. No recuerdo si todavía era Project MAC o Lab for Computer Science, pero solíamos enviar una propuesta para todo el laboratorio y solo tenía que escribir un par de páginas en esa propuesta para obtener dinero. También escribí propuestas de NSF solo para tener otra fuente de dinero y practicar cómo hacerlo. Pero en comparación con la situación actual, era mucho más fácil financiar tu investigación entonces.
Entonces vine al MIT. El primer curso que impartí fue lo que actualmente es 6.004. Entonces es un curso de arquitectura de computadoras. Esta fue una tarea extraña para mí porque no tenía antecedentes de EE[Ingeniero Eléctrico], y en realidad estaba en un departamento de EE. Todavía no era EECS [Ingeniero Eléctrico & Ciencias Computación]. No recuerdo cuándo se convirtió en EECS. Probablemente unos años más tarde. Eso fue un poco revuelto. Jack Dennis tenía un estudiante graduado, Clem Leung, quien también era un TA [Teaching Assistantship] para la clase, y él me ayudó. Sabes, me estaba quedando solo a una semana por delante de los estudiantes, aprendiendo cosas sobre circuitos y demás, en lo que yo realmente no tenía antecedentes. Y definitivamente tenía estudiantes que no estaban contentos de verme. No sentí que me discriminara la facultad, pero sentí que los estudiantes ... había unos pocos estudiantes en la clase que estaban ... tratarían de hacerme tropezar. Intentarían hacerme una pregunta que no podría responder. Por supuesto que estaba en una especie de posición vulnerable, enseñando un curso en un área que no conocía. Así que fue un pequeño bautismo de fuego, pero aprendí cómo ... estaba una semana por delante de ellos, y aprendí a decir: "Hablaré de eso en otro momento" [risas]. Mientras tanto comencé a investigar ...
Oh, el otro problema era que estaba en Project MAC o LCS, y decidieron que yo
era una persona de IA y me pusieron en el piso de IA. Creo que querían que yo
trabajar en IA Pero mientras tanto trabajaba metodología de programación. Jack
Dennis, en la primavera de 1963, me ayudó a trasladar mi oficina a la planta de sistemas, que era un lugar mucho más agradable, y que ayudó mucho. Entonces Jack me fue muy útil.
Mientras tanto, en investigación, me paré allí pensando en metodología de programación, y estaba realmente interesada en la metodología de programación. Y pensé que era un campo muy importante. Y lo que noté fue que aunque los documentos eran muy convincentes cuando los leías y siempre tenían un ejemplo y tu seguirías el ejemplo y dirías: "Oh sí, eso es muy Convincente. Esta es la forma correcta de hacer las cosas "... Y estoy pensando específicamente sobre los documentos de Parnas porque los suyos eran sobre cómo estructurar la programación. Si si piensas en los documentos de la época, había documentos sobre "Así es como se diseña software". Así que Niklaus Wirth escribió sobre la programación de arriba hacia abajo y Dijkstra envió esa maravillosa carta a las Comunicaciones de la ACM sobre "La Declaración GOTO es considerada dañina", y realmente la esencia de ese documento, si piensas detrás de escena de ese documento, el mensaje de Dijkstra trataba realmente de decir: "Deberíamos estar razonando sobre la corrección del código". El GOTO era malo porque dificultaba hacer ese razonamiento, pero la idea de que la programación es un problema intelectualmente difícil y debemos abordarlo de una forma matemática, eso fue en los primeros días y fue un paso bastante significativo hacia adelante para poder ver la forma de pensar sobre las cosas.
Pero Dave Parnas estaba escribiendo sobre modularidad, y decía: "Así es como deberíamos pensar acerca de los módulos". De hecho, dijo: "Los programas están formados por módulos, pero no sé cuáles son". Y así era como estaban las cosas en aquel momento. Pero tenía la idea de las especificaciones. Él decía: "Sean lo que sean, mejor describamos sus conexiones por completo". Así que quiso decir "Cualquiera que sea su interfaz, es mejor que tengamos una descripción completa".
Solía sentirme un poco celosa de los ingenieros eléctricos porque pensaba: "Al menos ellos tienen estos componentes y los conectan por cables, y eso te obliga a concentrarte realmente en cuáles son esos cables". Mientras que el software era tan plástico que la gente solía diseñar sin pensar mucho en esos cables, por lo que terminarían con este gran lío de interconexiones entre las piezas del programa, y eso fue un gran problema. Ese era el problema que estaba viendo en Venus cuando dije: "Vamos a tener particiones", pero fue solo un problema en general. Las variables globales fueron el gran problema. Solo la posibilidad y de que no hubiera nada que obligara a hacer las cosas de una manera concreta, llevaba a que pudieras hacer lo que quisieras.
De todos modos, estaba pensando en esto. Estaba pensando en el hecho de que, aunque la gente leyera el artículo de Parnas y estaba convencida de que la gente leería mi artículo y tendría la misma reacción, diría: "Sí, es una gran idea", pero cuando empezara a pensar sobre "¿Cómo lo aplico a mis propias cosas?" todo se vendría abajo, simplemente no tenía ni idea de cómo aplicarlo.
Estaba tratando de pensar en "¿Qué podemos hacer para mejorar las cosas?" Y en algún momento, y realmente no sé cuándo, pero probablemente el invierno de 1963-64 ... quiero decir ...
- El año 73
.72-73, [risas] Se me ocurrió la idea de la abstracción de datos. Y fue esta idea maravillosa. Vino de la nada. Pero una vez que la obtuve, pude ver que esto realmente iba a funcionar porque los programadores ya sabían sobre los tipos de datos abstractos. Quiero decir, incluso si no estaban pensando en ellos, porque sabían cuando usaron una matriz en su lenguaje Fortran que esto no era algo que tenía el hardware, era algo que usabas a través de un conjunto de operaciones y debajo de la superficie había un implementación en curso. Ciertamente, usted sabía esto con creces si estaba usando Lisp, que fue en lo que escribí mi tesis, porque allí se usan listas y estaba claro que había una implementación debajo y que las listas eran abstractas.
Entonces sentí que los programadores podrían entender la noción de abstracción de datos. Ya entendían sobre la abstracción de procedimientos, y la abstracción de datos era más poderosa porque un procedimiento ... Ah, por cierto, a veces implementaban una abstracción de datos con una abstracción de procedimiento al tener un montón de argumentos adicionales que controlaban las diferentes cosas que el procedimiento iba a hacer, pero eso también fue un desastre. Así que sentí que esto era algo por lo que los programadores sentirían afinidad y algo que podrían entender.
Y creo que otra cosa importante era ... Así que había un módulo más grande, se ajustaba a una idea de modularidad: necesitabas algo más grande que un procedimiento para realmente progresar, y también era una abstracción. Y eso también fue importante porque cuando diseñas, necesitas pensar de manera abstracta, y tener algo que coincida con el pensamiento abstracto, que te ayude en tu diseño. Entonces, ¿puedo pensar en términos de: “¿Qué abstracción de datos quiero en este lugar? ¿Qué procedimiento de abstracción quiero para allí? ”Este es un enfoque de diseño. Por lo tanto, también fue útil desde esa perspectiva.
Tuve la suerte de tener el maravilloso momento en el que tuve esta idea, y tan pronto como tuve esa idea, supe que iba a ir a algún lado. Entonces comencé a trabajar en esa idea. Y comencé a trabajar conjuntamente con Steve Zilles. Y esto fue definitivamente en la primavera de 1973.
Steve era un estudiante graduado en el MIT y es empleado de IBM. IBM estaba en el mismo edificio de Tech Square en el que estaba el laboratorio. Era mayor. Tenía poco más de treinta años, así que había estado trabajando para IBM por un tiempo y luego regresó a la escuela, y creo que solo iba a la escuela a tiempo parcial porque todavía estaba trabajando para IBM. Y él había tenido algunas ideas similares, así que Steve y yo comenzamos a trabajar juntos. Creo que Jack Dennis organizó un pequeño taller en la primavera de 1963, y tal vez así es como me conecté con Steve. Creo que Tony Hoare estaba allí, pero podría estar confundida sobre esto. No he tratado de resolverlo. Pero Jack estaba interesado en estas ideas y me estaba animando a trabajar en ellas.
Steve y yo comenzamos a trabajar en esto. Tener una idea y descubrir de qué se trata esta idea son dos cosas diferentes, así que era solo "Aquí hay una dirección para ir". Así que comenzamos a tratar de desarrollarla, y sabíamos que probablemente íbamos a trabajar con un lenguaje de programación como resultado porque se necesita expresar una idea como esa en un lenguaje de programación para que las personas tengan a su alcance las características lingüísticas necesarias para que todo se mantenga unido. Estábamos interesados en "¿Cómo sería ese lenguaje de programación? ¿Cómo podría tener una verificación de tipo que abarcara esta noción de abstracción de datos? ”Y todo el asunto era un gran misterio, pero comenzamos a trabajar en esto.
Por supuesto, leíamos documentos, y ahora me estaba moviendo hacia lenguajes de programación desde un respaldo en el que conocía ya Lisp y Fortran, y por supuesto que había terminado de leer sobre otras cosas. Steve provenía de IBM, que era el gran protagonista de la programación en ese momento: tenían Fortran, tenían PL / I, tenían COBOL, así que cubríasmos una amplia gama de lenguajes de programación entre nosotros y leímos un montón de documentos. El que encontré más... Bueno, leímos el artículo sobre Simula 67, y eso no tenía la abstracción de datos a pesar de que se trataba de clases y subclases, y se podía ver cómo podía ser la abstracción de datos . No tenía encapsulación, que es un componente muy crítico si desea modularidad, y estaban interesados principalmente en la herencia, que vimos como una falacia, por lo que ignoramos eso.
Jim Morris hizo un documento maravilloso sobre “Protección en lenguajes de programación” [James H. Morris, Jr., Communications of the ACM, Volume 16 Issue 1, Jan. 1973, Pages 15-21 ] creo que se llamaba, donde hablaba sobre modularidad y cuáles son las reglas que debe seguir para obtener los beneficios de la modularidad. Entonces, los beneficios de la modularidad son el razonamiento local ... Eso es lo más importante. Y Jim dijo: “Bueno, un módulo tiene algún estado dentro y luego un montón de código. La primera regla es que el código exterior al módulo sea capaz de modificar ese estado. Y esto es claramente esencial, porque si el código en el exterior pudiera modificar ese estado, entonces nunca sería capaz de razonar sobre el buen estado de ese módulo porque todo el código en el programa sería sospechoso". Pero luego dijo: "Pero, además, desea modificabilidad, lo que significa que si no me gusta la forma en que se implementó ese módulo, me gustaría poder reemplazarlo con otro código implementado de una manera diferente". Y para obtener modificabilidad, el código en el exterior ni siquiera debería mirar el estado. Solo debería interactuar a través de su interfaz abstracta".
Esas son, de hecho, las dos piezas clave de la modularidad, aunque en esos días e incluso en la actualidad, otro componente muy importante sobre la modularidad es que es una herramienta de administración, porque le permite dividir el programa en piezas separadas. Si siguen estas reglas, entonces las personas pueden trabajar en estas piezas de forma independiente. En aquellos días, la gente no sabía qué eran los módulos, y se escribían documentos que decían cosas como: "Un módulo no debe tener más de mil líneas de código". Quiero decir, la gente realmente no entendía la noción de abstracción, la noción de encapsulación. En su mayoría solo entendieron que necesitaban una forma de controlar el proceso de desarrollo del programa para que las personas pudieran estar trabajando en cosas separadas.
De todos modos, Jim expuso esos dos principios, y Tony Hoare al mismo tiempo estaba escribiendo documentos sobre ... Él ya tenía la noción de abstraer desde una representación a un tipo de datos abstractos a pesar de que eran tipos existentes en lugar de ... Así que esta idea surgió en muchos lugares diferentes.
Pero Jim no tenía idea de cómo implementar esto. Entonces, después de decir: "Bueno, estas son las reglas", la pregunta es "Bueno, ¿puedo aplicarlas? En particular, ¿puedo incluirlas en el lenguaje de programación para que el compilador pueda garantizar que obtenga la encapsulación? Entonces, eso fue con lo que Steve y yo estábamos luchando. ¿Cómo implementaríamos esto? ¿Cómo lo haríamos funcionar? Jim tenía una propuesta que consistía básicamente en utilizar cifrado. Habló sobre "sellar" y "abrir". Y eso funcionaría. La idea es que el módulo tiene una clave. Encripta un objeto cuando sale, lo desencripta cuando entra. Si alguien ha estado manipulándolo, se nota. Eso ciertamente funciona, pero no es práctico. Así que estábamos buscando un ... Ya sabes, "No quiero hacerlo de esa manera. Quiero algo eficiente ".
Y para el verano de 1973, habíamos descubierto que era posible hacer esto con un compilador teniendo la noción de una estructura lingüística que implementara una abstracción de datos y el compilador solo aseguraría la barrera de abstracción y el código en el exterior solo podría llamar a las operaciones. Sin embargo, fue solo un boceto. Quiero decir que no teníamos un lenguaje. Acabamos de tener una propuesta para un lenguaje. Y en ese documento, hablamos sobre algunos problemas que no sabíamos manejar. En particular, genéricos y polimorfismo.
El polimorfismo fue descuidado por años. Creo que es relativamente fácil, cuando solo estás haciendo procedimientos, ignorar el hecho de que "no quiero una rutina de clasificación que funcione en una variedad de enteros". Quiero una rutina de clasificación que funcione en general ". Pero dado el limitado rango de tipos de datos que existían en ese momento, se puede entender por qué la gente no estaba pensando en eso. Tan pronto como se va a la abstracción de datos, se puede ver que se necesita algún mecanismo que permita definir una abstracción de datos como una lista o un conjunto o un mapa o algo que simplemente define una vez y no deba re-implementarlo cada vez que tenga otro tipo de elemento. Y claramente hubo polimorfismo en la implementación de los tipos ya incorporados. Por lo tanto, las matrices podrían tener numeros de coma flotante o enteros si estabas trabajando en Fortran. Entonces fue allí. Simplemente no fue mostrado como un mecanismo que los programadores pudieran tener en sus manos, y pudimos ver que iba a ser un componente importante.
Escribimos este documento sobre tipos de datos abstractos y fue un gran éxito. Quiero decir que lo enviamos a la Conferencia sobre idiomas de muy alto nivel - que ahora no sé cuándo se interrumpió, no existió durante muchos años - y tuvo mucha repercusión. Terminamos este artículo en el verano de 1973.
Luego, en el otoño de 1973, comencé a trabajar en lo que se llamó CLU. Así que aquí estaba esta propuesta para un lenguaje de programación con solo algunos indicios de lo que podría contener y algunas declaraciones sobre "Sería bueno si tuviera polimorfismo". Sería bueno si tuviera un manejo de excepciones ". El manejo de excepciones también fue ... la gente estaba tratando de averiguar qué significaba eso en esos días. Esa era otra área en los lenguajes de programación en la que la gente estaba pensando pero no tenía una idea real de lo que debía hacerse. Entonces, el siguiente paso fue llegar a lo esencial y descubrir qué era todo esto.
En el otoño de 1973, reuní a tres estudiantes de posgrado: Russ Atkinson, Larry Snyder ... o Alan Snyder y Craig Schaffert, y ellos junto conmigo se convirtieron en los diseñadores de CLU. Solíamos tener una reunión grupal semanal donde todos nos reuníamos y estábamos trabajando en algún tema en particular como "¿Cómo debería ser el mecanismo de excepción?" O lo que sea que fuera el tema de la semana. Escribimos notas de diseño. En esos días, no los escribíamos online. Los escribías. Mi asistente, Ann Rubin, los escribía a máquina. Tuvimos un proceso de diseño muy riguroso y tuvimos una reunión grupal a la que asistieron bastantes más personas que solo nosotros. Entonces Steve venía, Jack Dennis solía venir. Otra gente. Alumnos de Jack. Así que teníamos un grupo bastante grande y simplemente nos esforzábamos ... Todo lo que veíamos intentaríamos verlo desde todas las direcciones posibles y descubrir "De estos dos enfoques, ¿cuáles son los beneficios? ¿Cuales son las desventajas?"
Tuvimos un proceso de diseño muy racional, y así es como hicimos CLU entre todos. Y los estudiantes implementaron, y nosotros implementamos a medida que avanzábamos. Comenzamos con un compilador escrito en un lenguaje llamado MDL - M-D-L - que era una variante de Lisp, y un subconjunto muy pequeño de CLU, y luego arrancamos. Ya sabes, lo usamos para implementar en CLU. Y, por supuesto, la propia CLU fue una prueba de fuego de la metodología, porque un compilador es un programa bastante grande, por lo que si puedes construir un compilador, especialmente cuando se está trabajando en programación secuencial, ese es una buena prueba de fuego. Por lo tanto, fue muy útil para nosotros implementar nuestro propio compilador, ya que nos obligaba a asegurarnos de que los mecanismos lingüísticos que proporcionábamos fueran lo suficientemente potentes incluso como para desarrollar un compilador.
Entonces estábamos implementando CLU, estábamos diseñando CLU. Habíamos descubierto ... Llamamos a estas cosas "grupos". Creo que la palabra "grupo" incluso se usó en ese documento con Steve. No supimos pensar en un buen nombre. Eventualmente, usamos CLU, CLU, las primeras tres letras de "cluster". Y supongo que ... No voy a hablar sobre las características reales de CLU, pero sí quiero hablar de eso en términos más generales.
CLU estaba muy adelantado a su tiempo. No era solo que tuviera abstracción de datos, que nadie más la tenía. El único otro proyecto que se estaba llevando a cabo en el momento en que se estaba analizando la abstracción de datos fue Bill Wulf y Mary Shaw trabajando en un lenguaje llamado Alphard en CMU. Entonces también estaban investigando la abstracción de datos. Una gran diferencia entre ellos y nosotros era que yo venía del Lisp, creía en el heap (pila). Ellos estaban mucho mas en el mundo de ALGOL o en ... Hubo muchas discusiones en aquellos días sobre "Los punteros son malos". Entonces querían que todo estuviera en la pila. Por supuesto se puede evitar la recolección de basura, pero hizo que todo fuera mucho más complicado para ellos. Así que creo que los ralentizó. Mientras que yo venía del campo de Lisp. Yo creía en la recolección de basura, creía en la pila. No pensaba que los punteros fueran malos siempre que pudieras gestionar la verificación del tipo. Sin embargo, estaba muy a favor de la verificación de tipo fuerte, y como digo en mi charla, esto es en parte una reacción a Lisp, porque me pareció tan molesto que no hiciera una verificación de tipo estática, y puede ahorrar mucho tiempo en el proceso de desarrollo del programa si se tiene un buen compilador haciendo análisis estático.
Lisp tenía otra cosa que me influyó mucho, que era una compilación separada. Eso también fue muy importante. Desde el primer día, CLU siempre se compiló por separado. De hecho, nuestra idea era que primero pusieras en la biblioteca del programa una descripción de la interfaz de un módulo, y luego pudieras compilar el código que usó el módulo aunque el módulo aún no se hubiera implementado. Y si quisiera, se podría proporcionar una especie de simulación ingeniosa de la implementación como su primera implementación para saber si se quisiera ir más allá. Así que llevamos esta noción de compilación separada, la llevamos tan lejos como creímos posible.
CLU tenía abstracción de datos. Sabíamos que necesitábamos polimorfismo. Y el polimorfismo fue un desafío para nosotros debido al hecho de que cuando escribe un tipo de datos o un procedimiento que está parametrizado por algún tipo arbitrario T, a veces no todos los tipos arbitrarios son parámetros legítimos. Entonces, si estás hablando de un conjunto ordenado de T, entonces tienes que tener alguna forma de comparar los elementos T. Y no todos los tipos tienen una forma deordenarlos. Y no sabíamos cómo ... Y queríamos capturar esto estáticamente. No queríamos que esto fuera una especie de cosa dinámica que se descubriera en tiempo de ejecución: "Oh, falta la operación que necesitamos". Queríamos asegurarnos en el momento de la compilación existía tal operación.
Finalmente, inventamos lo que llamamos "cláusulas where" [cláusulas dónde], donde simplemente enumeraríamos el conjunto de operaciones con sus firmas requeridas que tuviera el tipo, y luego el compilador podría verificar en tiempo de compilación un uso que el tipo de parámetro proporcionado tuvieran las operaciones que fueran requeridas. Por supuesto, capturamos solo la sintaxis, no la semántica. Ya sabes, dijimos: "Tiene que tener una operación con un nombre como mínimo que ..." Con dos Ts devolviendo un Booleano, no dijimos que fuera una relación de orden. Eso habría sido parte de su especificación. Habría tenido que razonar sobre esto afuera. Pero eso es lo más lejos que puede llegar con un compilador, porque un compilador no razona. Sabes, puede hacer partes simples del razonamiento, pero no el razonamiento completo.
Curiosamente, hay algo llamado clases de tipos en Haskell y están fuertemente relacionadas con las "cláusulas where". Están cumpliendo los requisitos para un módulo polimórfico, diciendo: "Aquí hay un conjunto de operaciones, aquí están sus firmas", y luego se les puede poner una especificación. Pero CLU tenía estos allí como cláusulas where. Esa fue nuestra solución para el polimorfismo.
Teníamos un mecanismo de manejo de excepciones. Pensamos que las excepciones son muy importantes, porque desde el punto de vista de la metodología de programación, nos gustaría que las especificaciones de las operaciones estuvieran completas si fuera posible. No parcialmente sino completamente. Cubriendo todo el rango de posibles entradas. Dado que si alguna vez tiene a: "todo menos verdadero" como condición previa para su llamada, existe una fuente potencial de errores allí porque si alguien que usara su módulo lo olvidara, aún cubriendo todas las bases, entonces debería estar seguro de que esos errores no son posibles . Pero cuando se intenta hacer un procedimiento total, entonces tiene el problema que no puede regresar de la misma manera al espacio de entrada de datos. Por lo tanto, necesita alguna forma, pensamos, de llamar la atención antes al procedimiento que llama.
La forma en que las personas manejan este problema hoy e incluso cuando no tienen un mecanismo de excepción o piensan que es demasiado costoso usarlo, es que juegan un juego. Entonces dirán: "Bueno, devuelves un valor y una parte especial de este valor te dice lo que está sucediendo". Como "devuelvo un puntero a un objeto, pero si el puntero es nulo, esto significa algo". Y El problema es que esto es muy propenso a errores. "Devolveré un entero si el entero es negativo". Esto tiene un significado especial, pero la gente se olvida de probar. En cierto sentido, es lo mismo que tener una especificación parcial. Es un poco mejor, pero también es muy propenso a errores. Así que queríamos un mecanismo que le dijera al usuario, realmente empujar esos resultados a otra parte del programa.
Todo esto parece tan común hoy en día porque así es como funciona el mecanismo de Java, pero en aquellos días, no existía. Entonces inventamos esas cosas. Y nos preocupamos por muchos de los problemas con el manejo de excepciones. Uno de los problemas con las excepciones marcadas en Java es que a las personas no les gusta tener que escribir el código para manejar las excepciones que no sucederán en su programa. “Acabo de comprobar que mi índice está dentro de los límites, entonces, ¿por qué tengo que escribir una cláusula catch cuando llamo a la búsqueda? Porque sé que no va a suceder ". Así que lo manejamos convirtiéndolos en una excepción especial de falla.
Entonces CLU tenía un mecanismo de excepción. Esa fue otra gran parte de nuestro diseño, resolver todos los detalles de cómo funcionaría.
Y luego la tercera parte de nuestro diseño fueron los iteradores. Es algo que no previmos al iniciar el proyecto. Los otros dos, creo que ya estaban en el documento original, pero los iteradores no eran algo que estuviera en mi mapa mental. Pero nos dimos cuenta de que necesitábamos un mecanismo de iteración porque muchas abstracciones de datos son colecciones, como conjuntos y mapas y cosas así, y cuando haces recolectas, generalmente es porque quieres hacer algo con la colección, que a menudo se está iterando sobre ella. . Aunque se pueden encontrar formas de hacer iteraciones en ausencia de un mecanismo, parecía más elegante tener un mecanismo. Y tal como he contado la historia muchas veces, fuimos a Carnegie Mellon, visitamos a Bill Wulf y Mary Shaw y su grupo. Nos explicaron sobre algo llamado generadores, que en realidad estaba surgiendo de las ideas de IA. Así que escuchamos esto y los generadores eran como los iteradores en Java hoy en día. Eran objetos con un montón de operaciones para iniciar la iteración, y así.
Entonces pudimos ver que esta era una buena solución, pero pensamos que era poco elegante y excesiva. Y así, en el avión que regresaba a Boston, mi estudiante Russ Atkinson inventó los iteradores, y los iteradores están diseñados para usarse con un bucle 'for'. Llama al iterador para iniciar el ciclo. Cada vez que tiene un nuevo valor para proporcionarle, utiliza una instrucción de devolución especial llamada 'entrega' [yield]. Luego ejecutamos el cuerpo del bucle. Al final del cuerpo del bucle, volvemos al iterador exactamente donde entregó, por lo que simplemente continúa en su flujo de control. Cuando no tiene nada más que entregar, regresa, y eso termina el bucle.
Es una forma limitada de rutina, porque no tiene la capacidad de mantener en funcionamiento, múltiples de ellas y así. Por ejemplo, no puede explorar dos árboles y verificar la misma franja usando iteradores. Tendrían que estar anidados. Pero decidimos, y esta es una especie de regla del 90% para el diseño del lenguaje de programación, la mayoría de las veces, este uso algo limitado de iteradores es lo que se necesitaría. Entonces, en lugar de tener un mecanismo más complicado que lo llevara más lejos, pero no fuera tan conveniente de usar en el caso normal, optaríamos por el mecanismo más simple. Y también fue agradable porque tenía una implementación muy eficiente en la que simplemente pasabamos el cuerpo del bucle como una rutina oculta al iterador, que llamaba cada vez que entregaba. Todo muy sencillo.
Entonces eso fue CLU. Y para 1978, teníamos un compilador que funcionaba bien, teníamos un idioma, teníamos un manual de referencia, teníamos usuarios. Se estaba utilizando en más de 200 sitios concretos. Estaba siendo utilizado para construir software grande.
Debo decir que fue importante diseñar un lenguaje por varias razones. Una fue que la gente tiene que escribir programas en el idioma para poder saber si se han implementado los mecanismos correctos. A nuestros usuarios, si no les hubiera gustado algo, se habrían quejado y entonces pensaríamos si nuestros mecanismos habían sido lo suficientemente potentes.
Pero el rendimiento importa. Por lo tanto, se debe pensar en: "¿Qué coste tiene?". Por ejemplo, en nuestro mecanismo de excepción solo cuesta aproximadamente el doble de tiempo señalar una excepción que hacer un retorno normal. Si los mecanismos de excepción fueran costosos, que desafortunadamente es lo que acostumbra a ocurrir en los lenguajes modernos, la gente no hubioeran querido usarlos. Aunque pudieran estar muy equivocados. Quiero decir que podría ser que el hecho de saltar una excepción no ocurriera muy a menudo, por lo que si observara el rendimiento general del programa, el costo de la excepción no importaría mucho, tal vez. Pero consideramos que era importante contar con un mecanismo de excepción eficiente para que esa barrera de uso no existiera.
Entonces se necesita una definición matemática. Un objeto matemático real del que las personas puedan entender su significado. Esa fue otra razón por la que era importante construir lenguajes de programación. Entonces queríamos un lenguaje porque la gente piensa en términos de ... Los programadores piensan en términos de lenguajes de programación, por lo que mostrar esas características prepara el terreno para que ellos imaginen qué pueden hacer.
Y, por cierto, una vez que existen las características, ahora puede comenzar a simularlas en otros idiomas y la gente seguirá viendo que es una abstracción de datos. Entonces, durante muchos años en el 6.001, nuestro curso introductorio que desarrolló Gerry Sussman, enseñaban la abstracción de datos, pero básicamente usaban un registro de punteros para (proporcionar) los métodos del tipo de datos. Y cundo ya existe la abstracción de datos, entonces se puede ver que ese es el camino a seguir. Entonces todo va bien.
Esa es realmente la historia de CLU. Y llegó el 1977 o 1978 y CLU estaba casi terminado, y empecé a pensar qué hacer a continuación. En ese momento, ya había comenzado a enseñar 6.170.
- ¿Qué es eso?
6.170 durante muchos años fue el segundo curso de programación en nuestro plan de estudios. Y Corby y otras personas en el departamento me pidieron que desarrollara este curso y pensaron que lo necesitábamos. Entonces, nuestros estudiantes comenzarían con 6.001, que se impartió en Lisp, o Scheme en realidad, y aprendieron a construir pequeños programas. Y la idea en el curso 6.170 era: "Está bien. y ahora, ¿cómo se construyen buenos y grandes programas?"
Entonces desarrollé este curso. Todo se basó en ... Se trataba de metodología de programación, cómo se diseña, cómo se usa la abstracción de datos, cómo se hace el diseño modular. Realmente estaba en línea con mis intereses, y lo enseñé durante aproximadamente - déjame pensar, '77 - probablemente 20-25 años, algo así. Hasta en el día de hoy sigo haciendo que la gente me diga lo importante que fue para ellos, el impacto que tuvo en su carrera, porque realmente enseñó a los estudiantes cómo pensar sobre el diseño modular y cómo organizar un gran proyecto.
Y todavía lo enseñamos. Simplemente se transformó en otro curso, que ... Fue demasiado trabajo para los estudiantes. Este es un problema de MIT en general: los cursos dan demasiado trabajo a los estudiantes. Entonces intentaron dividirlo. No estoy segura de que esto haya sido terriblemente exitoso. Tengo la sensación de que estos cursos tienden a ... añadir más y más material que se acumula en el curso a medida que se desarrolla.
De todos modos, estaba pensando qué hacer a continuación. Podría haber seguido trabajando en el lenguaje de programación, pero no sentía que tuviera grandes ideas. No vi otro mecanismo de abstracción. No vi una forma en la que pudiera tener un gran impacto. Me refiero a CLU, este trabajo había tenido un gran impacto, por lo que estaba buscando un impacto como ese. Y los iteradores también fueron muy importantes. Pero en computación paralela, no tenía grandes ideas sobre qué hacer al respecto. Entonces pensé: "Bueno, no" [risas].
También pensé en la comercialización, pero decidí que ... En estos días, tal vez podría comercializar publicando cosas en la web y la gente comenzará a recogerlo y tal vez haya usuarios que contribuyan a la implementación, etc. Creo que todavía es muchísimo trabajo. Creo que las personas que lo publican terminan pasando la mayor parte de su tiempo enfocados en eso. Entonces no es realmente investigación. Es mucho más desarrollo. Así que no parecía una muy buena dirección para entrar.
Estaba mirando a mi alrededor pensando en qué hacer, y comencé a pensar en ARPANET. Y realmente no lo sé, no recuerdo qué fue lo que me hizo ver este problema que estaba al acecho en ARPANET. No fue un problema lo que inventé. Bob Kahn había estado escribiendo documentos sobre ARPANET. Entonces, en aquellos días, la gente enviaba correos electrónicos, la gente hacía FTP, la gente hacía un inicio de sesión remoto. Eso fue lo que se hacía en Internet, y ya se estaba usando el correo electrónico. Quiero decir que la gente me dice que el correo electrónico no existíó tan pronto, pero existió en los años 70 porque yo lo estaba usando. Pero había un sueño de escribir programas distribuidos donde tendrían componentes ejecutándose en diferentes computadoras y se comunicarían enviandose mensajes, y nadie sabía cómo hacerlo. Entonces pensé: "Ah, este es un gran problema", y entonces me lancé a la computación distribuida.
Esto fue a finales de los años 70. Acabo de cambiar de dirección. No cambié totalmente porque todavía estaba trabajando en el curso 6.170. Había estado pensando en "¿Cómo razonar sobre la validez de los tipos de datos abstractos? ¿Cómo se escriben especificaciones para tipos de datos abstractos? ”Mucho de esto fue enseñado a los estudiantes en mi curso. Yo también estaba...
- Si puedo, te detendré por un momento.
Bueno. Entonces, ¿dónde estabamos ...? [risas]
- [Mucho de esto estaba relacionado con tus alumnos ...]
.....6.170, sí. Yo estaba trabajando con John Guttag. Olvidé cuando John vino al MIT. Había hecho su tesis sobre especificaciones de tipos de datos abstractos. Steve Zilles había hecho algo similar ... no terminó su tesis, pero sí una investigación similar. Entonces John y yo estábamos trabajando juntos. Comenzamos a trabajar juntos en el curso 6.170. Nosotros escribimos un libro. Yo todavía estaba interesada en la metodología de programación. No tanto en las cosas del lenguaje de programación, sino las cosas de la metodología de programación. Pero salté a la investigación en computación distribuida, y realmente me quedé en esa área después de eso, con algunas disgresiones en otras cosas, y pasé una buena época.
Pensé que era irónico de una manera que decidí no investigar la concurrencia cuando estaba trabajando en CLU porque ya tenía suficiente en mi plato y eso hubiera sido una gran distracción. Cuando llegué a la informática distribuida, por supuesto, la concurrencia regresó, así que volví a pensar en la concurrencia nuevamente, ya que claramente tienes todas estas computadoras y todas están trabajando en paralelo, etc. En cierto modo, la informática distribuida es un gran lugar para pensar en términos de tipos de datos abstractos porque aspira a tener diferentes objetos ejecutándose en diferentes máquinas, se van a comunicar.
Una de las cosas en las que estaba pensando en los primeros días de este primer proyecto, que fue el proyecto Argus para desarrollar un lenguaje para implementar estos programas distribuidos, fue "¿Cuál es el mecanismo de comunicación?" Terminé fuertemente del lado del procedimiento de llamada remota. Es decir, en una máquina remota tengo un objeto, que proporciona operaciones, y desde aquí llamo a esas operaciones. Y luego, debajo de la tapa, las cosas pasan. Argus era un sistema de un solo lenguaje, por lo que hubiéramos podido ... Si está ejecutando en una máquina y tiene un lenguaje, puede hacer una llamada al procedimiento remoto de forma mucho más eficiente que si se preocupa por máquinas heterogéneas , diferentes lenguajes de programación, etc.
De todos modos, comencé a trabajar en informática distribuida y eso fue un largo recorrido. En los años 80 y 90 tuve algunos estudiantes estupendos. No estoy segura de qué hablar allí. Sus...
- Bien, veamos. ¿Quién te influyó? ¿Estabas ... ¿Qué tal Lampson? ¿Era él un ... sus cosas en Xerox? O...
No quisiera decir ... Ya sabes, es difícil de responder. No diría que el trabajo de Butler me influyera particularmente. En los años 70, había un grupo de contratistas de DARPA que se reunían un par de veces al año para hablar sobre lenguajes de programación y metodología de programación. Entonces Butler [Lampson] estaba en ese grupo, Bill Wulf y Mary Shaw también estaban en ese grupo, y yo estaba en ese grupo, Jim Horning, los desarrolladores de Euclid. Entonces, solía ir a esa reunión cada seis meses más o menos, y había mucho intercambio de ideas. Miras un lenguaje como Euclid y puedes ver la abstracción de datos, las especificaciones, tods estas cosas tiraban adelante. Pero cuando me mudé a ... No, lo que me influyó fueron las transacciones.
- Correcto.
Sí es cierto.
- Cierto. Y luego Lampson y Sturgis con el almacenamiento ...
El problema es que estoy en el lado de la llamada y no quiero esperar para siempre, ¿qué debo hacer? Bueno, lo que pensamos que ocurre es que estás ejecutando una pequeña subacción y la anulas, y eso significa que aunque sucediera allí, realmente no ha sucedido y, por lo tanto, no tienes que preocuparte por eso. Podrías probar una técnica alternativa o así.
Esa fue la gran originalidad del Argus. Funcionaba todo con transacciones. Así que teníamos objetos que eran instancias de tipos de datos. Corrían en máquinas individuales. Y luego ejecutábamos los cálculos como transacciones, y cada vez que realizábamos una llamada remota, la ejecutábamos como una subacción. Esa era forma de actuar de Argus. No creo que fuera necesariamente una buena idea porque era complicado y costoso. No estoy segura de que hiciera las cosas de la misma manera si lo hiciera hoy. Probablemente usaría un modelo de computación mucho más simple.
Sin embargo, una cosa interesante, una historia sobre Argus, es que X-Windows salió de Argus. Bob Scheifler estaba trabajando para mí. Fue uno de los dos miembros del personal que fueron grandes implementadores para nosotros. Es un implementador maravilloso. Necesitábamos una forma de depurar los programas distribuidos que estás ejecutando, y a él se le ocurrió X-Windows porque lo que era bueno era que podías tener una ventana aquí mirando eso ... los llamamos "guardianes", estos objetos por aquí y otro por allá mirando a este guardián. Por lo tanto, nos proporcionó un entorno de depuración muy agradable.
Entonces Jerry Saltzer había estado a cargo del Proyecto Athena y Kerberos había salido de eso. Ese fue un gran éxito porque era de dominio público, por lo que Mike Dertouzos pensó: "Bueno, intentemos convertir X en dominio público", así que formamos el Consorcio X. Esto fue algo así como el comienzo de Windows siendo la forma en que manejar tu sistema en un mundo distribuido. No fueron las primeras ventanas. Había algo llamado W, creo, que las precedieron. W, X - "X" está detrás de "W." Pero fue solo una pequeña luz interesante sobre lo que estaba sucediendo. No fue mi invento, fue de Bob.
Entonces implementamos Argus. Quiero decir, en este punto, estamos tratando de dar algo de sentido a "¿Qué son los sistemas distribuidos?" Y hay mucho trabajo en la comunidad de los sistemas operativos, la gente está pensando en "Tal vez solo tengo una gran pila, y los programas se ejecutan y comparten estos objetos en la pila ". No estoy segura de que este trabajo realmente hubiera tenido ninguna transcendencia en el sentido de: "la gente está creando programas utilizando Argus", porque lo que sucedió fue que apareció el gran modelo RPC. La idea era construir los componentes, que se comunicaran a través de una interfaz que se describe en la biblioteca, y el software los conecta para obtener heterogeneidad. El rendimiento no es excelente, pero esa fue la idea.
De todos modos, trabajé en Argus y luego los estudiantes que trabajaban para mí en ese momento, estábamos pensando en la abstracción de datos y la concurrencia. Entonces, Bill Weihl escribió una tesis sobre la conmutatividad y cómo puede usar la especificación de un tipo de datos abstractos para determinar cuánta concurrencia está permitida. En una base de datos en ese momento, utilizaron el bloqueo de dos fases. Ese es un mecanismo que no entiende de significados. Es solo una técnica que se puede usar y que garantizará la serializabilidad. También había un control de concurrencia optimista - no se usó tanto entonces, pero se usó mucho más tarde -. Pero la idea de Bill era: "Si entiendo la semántica de las operaciones, puedo obtener más concurrencia de la que permitirían estos mecanismos de control de concurrencia que no entendieran la semántica". Así que ese fue un trabajo inicial que surgió de ese grupo.
Luego, otra cosa que sucedió en los años 80 fue que inventamos lo que es esencialmente Paxos. Inventamos algo llamado "replicación con sello de vista" [viewstamped replication] , este fue otro de mis alumnos, Brian Oki, porque estábamos interesados en la fiabilidad y la disponibilidad. Quiero decir que pensé en la informática distribuida como una bendición y una maldición. Si su máquina se cae en un sistema no distribuido, no puede hacer nada hasta que vuelva. Con un sistema distribuido, podría tener cosas en otro lugar, así que tal vez podría continuar trabajando.
Por otro lado, si tienes cosas en otro lugar y no tienes una forma de controlarlas, entonces hay más de una falla que puede hacer que dejes de trabajar, así que ¿qué hacer al respecto? Se nos ocurrió una técnica de replicación para garantizar que todo funcionara correctamente, y siempre que f de 2f + 1 nodos funcionaran ... Entonces sí.
- Bueno. Entonces, ¿por qué no nos hablas sobre el: "Principio de sustitución de Liskov"?
Esto fue algo interesante que sucedió en los años 80. Al mismo tiempo que estaba desarrollando CLU y Bill y Mary estaban trabajando en Alphard, Alan Kay y Adele Goldberg estaban trabajando en Smalltalk en la costa oeste. Aunque puede parecer un poco extraño en estos días, en esos días era un largo camino desde la costa este hasta la costa oeste, y por supuesto, tampoco teníamos videollamadas de conferencia en esos días. Todo ese asunto relacionado con la programación orientada a objetos se estaba desarrollando en la costa oeste y en la costa este, estábamos trabajando principalmente en la abstracción de datos, y los dos mundos estaban algo separados. Entonces yo sabía el nombre, pero no nos encontramos en las conferencias y no había mucho diálogo [crosstalk].
En la década de 1980, me pidieron que diera una conferencia en OOPSLA, que creo que tal vez fue la segunda OOPSLA. No hacía mucho tiempo que existía. Así que decidí que esta era una buena oportunidad para aprender sobre lo que estaba sucediendo en los lenguajes orientados a objetos. Entonces comencé a leer todos los documentos y descubrí que la jerarquía se estaba utilizando para dos propósitos diferentes. Uno era simplemente herencia. Entonces, tengo una clase, implementa algo, puedo construir una subclase, puedo tomar prestada toda esa implementación, cambiarla como quiera, agregar algunos métodos adicionales, cambiar la representación. Lo que sea que quiera hacer, simplemente tomo prestado el código y sigo trabajando en ello.
La otra forma en que se usaba era para la jerarquía de tipos. Entonces, la idea era que la superclase definiría un supertipo, y luego una subclase lo ampliaría para convertirse en un subtipo. Pensé que esta idea de la jerarquía de tipos era muy interesante, pero también sentí que no la entendían muy bien. Recuerdo haber leído documentos en los que estaba claro que estaban muy confundidos al respecto, porque uno en particular que recuerdo dijo que una pila y una cola eran ambos subtipos entre sí. Esto claramente no es cierto porque si has escrito un programa que esperaba una pila y obtienes una cola, te sorprendería mucho su comportamiento. La diferencia entre LIFO y FIFO es un gran problema.
Esto me llevó a comenzar a pensar en "¿Qué significa realmente tener un supertipo y un subtipo?" Y se me ocurrió una regla, una regla informal que presenté en mi conferencia en OOPSLA que simplemente decía que un subtipo debería comportarse como un supertipo, por lo que puede ver, utilizando los métodos de supertipo. Entonces no era que no pudiera comportarse de manera diferente. Es solo que mientras limite su interacción con sus objetos a los métodos de supertipo, obtendrá el comportamiento que esperaba.
Esta definición informal aquí dada fue basada en la intuición. Es intuitivamente correcta en algún sentido. Puedes ver cómo entiender el supertipo, escribes un código en términos del supertipo, cualquier objeto que obtengas debe comportarse de la manera que esperas. De lo contrario, ¿cómo se puede hacer este razonamiento independientemente del comportamiento?
Más tarde, Jeannette Wing, quien en realidad había sido estudiante de mi maestría, y luego John Guttag, estudiante de doctorado, se acercaron a mí y me dijeron: "¿Por qué no tratamos de averiguar exactamente qué significa esto?". Así que trabajamos juntos en esto en unos artículos que se publicaron un poco más tarde.
Mientras tanto, estaba trabajando en computación distribuida, estaba particularmente interesada en la "replicación con sello de vista" [viewstamped replication] y algunos de los otros trabajos que se estaban realizando en mi grupo en ese momento, y realmente no estaba pensando en esto hasta que en algún momento en los años 90 recibí un correo electrónico de alguien que dijo: "¿Puede decirme si este es el significado correcto del Principio de Sustitución de Liskov?" Entonces, esa fue la primera vez que tuve alguna idea [risas] de que existía tal cosa, y que este nombre se había propagado. Técnicamente se llama "subtipo de comportamiento". Ya sabes, dice que los subtipos se comportan como supertipos. Entonces pensé que era muy divertido. Descubrí que había mucha gente en Internet discutiendo sobre el significado del principio de sustitución de Liskov. Así que fue bueno tener algo que tuviera un impacto como ese. Diría que combina la abstracción de datos con la jerarquía de tipos y así ya se tiene una programación moderna orientada a objetos.
Pero eso fue una pequeña desviación del trabajo que estaba haciendo, que era todo computación distribuida. Trabajé en informática distribuida durante los años 80 y 90. Y es un poco difícil recordar todos los diferentes proyectos que estaban en marcha. En algún momento, a principios de los años 90, comencé a trabajar en el proyecto Thor, que en cierto sentido era lo opuesto a Argus. Entonces Argus era un proyecto en el que los objetos eran los componentes del sistema distribuido. Thor era un proyecto en el que tenía un modelo cliente-servidor, los objetos se almacenaban en los servidores y los clientes interactuaban entre sí solo mediante el uso de los objetos.
Por lo tanto, era mucho más una vista de base de datos del mundo que Argus. Y todavía estábamos ejecutando transacciones, pero ahora eran transacciones ... no se distribuyeron transacciones como en Argus. Eran transacciones de una máquina en las que un cliente se ejecutaba contra los objetos en los servidores y al final confirmaba o cancelaba, y eso causaría un cambio en el estado global. Y creo que esa podría ser una forma más productiva de crear aplicaciones. Ese era realmente un sistema orientado a objetos en lugar de un sistema de base de datos. Utilizamos una forma muy interesante de control de concurrencia optimista e hicimos mucho trabajo en la gestión de caché y otras técnicas que hicieron que el sistema funcionara bien.
Como saben, el rendimiento está sobrevalorado en la mente de los informáticos. Por otro lado, el rendimiento es muy importante cuando construyes una plataforma sobre la que te gustaría que las personas crearan aplicaciones. Por lo tanto, importa mucho en un sistema operativo. E importaría mucho en un sistema como Thor o Argus porque se esperaría poder construir en la parte superior, y cualquier problema con el rendimiento que existiera en el nivel de implementación de la plataforma se multiplicaría cuando se acediera al nivel superior.
En los años 90, además del trabajo en Thor, mi grupo hizo otras dos cosas que pensé que eran notables. El primero fue la tolerancia a faltas bizantinas y el otro fue el control descentralizado del flujo de información. El primero ... No estoy seguro exactamente el orden en que sucedieron. Probablemente fueran simultáneos. El primero sucedió con mi alumno Miguel Castro. Lo que sucedió fue que vi una solicitud de propuesta de DARPA hablando de intrusos maliciosos en Internet y qué se podría hacer para contrarrestar su impacto. Y se lo di a Miguel. Le dije: "Piensa en esto. Mira si puedes pensar en algo interesante que podamos proponer hacer ". Y él pensó:" Bueno, tal vez deberíamos considerar esta cuestión de la replicación en presencia de ataques bizantinos ", y esto finalmente se convirtió en ese trabajo sobre tolerancia a fallas bizantinas.
No era que la gente no hubiera trabajado en eso antes, sino que en su mayoría habían sido teóricos, por lo que no estaban pensando en una técnica práctica, una que tuviera un costo bajo o tan bajo como usted pudiera manejar, y realmente pudiera usarse en la práctica.
- Entonces deberíamos decir qué significa "bizantino".
"Bizantino" significa faltas arbitrarias. El trabajo que hice en los años 80 en la 'replicación con sello de vista', también conocido como Paxos, asumió faltas benignas donde una computadora estaba funcionando o no. Ya sabes, llegó un mensaje o no llegó. No estaba distorsionado de alguna manera. La computadora falló al estrellarse o estaba funcionando correctamente. Ya sabes, el mensaje llegó intacto o no llegó en absoluto. O tal vez llegó y no estaba intacto, pero lo reconociste de inmediato y pudiste tirarlo.
Con faltas bizantinas, la computadora sigue funcionando. Ya no funciona correctamente, pero funciona de todas formas. Por supuesto, esto sucederá la mayor parte de las veces y se podrá saber que no se está ejecutando correctamente, porque hará cosas raras, pero una falla bizantina real es aquella en la que continúa funcionando y parece que está bien. Y hubo ejemplos de que esto sucedió. Por ejemplo, probablemente esté al tanto de las cosas que estaban sucediendo en la comunidad de redes donde un pequeño cambio en un mensaje causó todo tipo de problemas en el enrutamiento del mensaje y todo esto.
En el caso de fallas bizantinas en la ejecución de una computadora, estos fueron principalmente el resultado de ataques. Y es interesante, cuando comencé a trabajar en Internet en los años 80, solo éramos un grupo de colegas. Todos eran amigos. Comenzó como un grupo de universidades conectadas por ARPANET, y realmente no nos preocupamos por los ataques porque nadie estaba interesado en hacer ataques. Simplemente estábamos interesados en "¿Cómo hacer que las cosas funcionen?" A medida que nos mudamos a los años 90, esto ya no era una suposición válida. Pero una vez apareció la World Wide Web ...
Y debería decir en este momento que, como todos los demás que conozco en el tipo de comunidad informática general, no lo vi venir. No tenía idea de que íbamos a pasar de estas computadoras que mis amigos estaban usando a algo donde todo el mundo comenzó a usarlo. Esa fue una transformación sorprendente.
De todos modos, cuando esto se convirtió en algo que todo el mundo estaba usando, entonces el problema de los malos actores que tratarían de lanzar ataques a las computadoras de las personas para fines que hoy conocemos haciendo cosas realmente malas, como cifrar sus archivos y luego exigir chantaje para darte la llave y cosas así.
Entonces, en los años 90, estábamos en un período de transición en el que comenzamos a pensar que tal vez estos ataques realmente importaban. Entonces, la cuestión de cómo hacer una técnica de replicación que manejara los ataques bizantinos donde una de las réplicas se comportara de manera maliciosa y pareciera comportarse correctamente, pero en realidad no se comportara correctamente. Por ejemplo, diría: "Ejecute esta operación por mí", y volvería y diría: "Está bien, y aquí está su respuesta", pero en realidad hubiera hecho algo completamente diferente. Ese fue un ejemplo de un ataque bizantino [realmente "fracaso"].
Entonces Miguel y yo trabajamos en este problema, cómo hacer un protocolo práctico. Para una falta benigna, necesita réplicas 2f + 1. Entonces, para manejar una réplica incorrecta, necesita 3. Para Bizantino necesita 3f + 1. Por lo tanto, necesitaría cuatro. Y también necesitas un protocolo más complicado. Y estoy convencida de que una de las razones por las que pudimos descubrir cómo hacer esto fue porque habíamos hecho una 'replicación con sello de vista' en mi grupo antes, y mirando hacia atrás tal como sucedieron las cosas, veo la tolerancia a fallas bizantinas como la 'replicación con sello de vista' un poco extendida. Tiene una fase adicional en el protocolo, tiene una réplica adicional, pero está bastante relacionada. Así que creo que esto nos ayudó a Miguel y a mí cuando estábamos tratando de descubrir cómo hacer que esto funcionara, ya que teníamos esos antecedentes de los que dependíamos.
La otra derivación importante fue el control descentralizado del flujo de información. Este fue el trabajo que hice con mi alumno Andrew Myers. Para la seguridad en los sistemas, siempre ha habido dos enfoques diferentes. Control de acceso, que controlaba a qué programa se puede acceder o qué usuario estaba autorizado a acceder, pero una vez que se podría acceder a algo, se podía hacer lo que quisiera con él. El control del flujo de información no controló el acceso. Controlaba lo que podía pasar con la información después del hecho. Entonces, si tenía derecho a leer archivos secretos, y esto surgió de este tipo de trabajo en el ejército, entonces no se le permitiría exponer esa información, a no ser a donde la información secreta pudiera ir. Lo que importaba no era el control de lo que mirabas, sino el control de lo que hacías con ello.
Estos sistemas siempre se habían basado en una noción centralizada de quién tenía el control de las cosas. Había Top Secret, había Secret, había Confidential. Alguien clasificaba todo y luego el sistema simplemente seguía las reglas basadas en ese tipo de nociones centralizadas. Lo que hice con Andrew fue descentralizar esto para que los usuarios individuales pudieran poner etiquetas en sus datos en función de sus propios deseos para el control y luego hacer que todo funcionara de la misma manera, controlando el acceso. Y eso llevó bastante trabajo en lenguajes de programación y sistemas operativos después del hecho. Trabajamos en Thor y trabajamos en estas dos interesantes direcciones, e hicimos un trabajo de lenguaje de programación también, especialmente con Andrew, que era una persona de lenguajes de programación que trabajaba en mi grupo.
Eso nos llevó a finales de los 90. Luego me tomé un par de años libres y trabajé para una startup solo para ver cómo era. Era una startup llamada SightPath en la que trabajé y poco tiempo despues de haber entrado fue comprada por Cisco, y acabé trabajando allí durante dos años. Diría que trabajar en una empresa no era lo que mas me interesaba, así que regresé al MIT y me convertí en jefa de la parte de informática de nuestro departamento. Continué trabajando en computación distribuida, desarrollé un sistema llamado Aeolus, que era un sistema descentralizado de control de flujo de información con un componente de lenguaje de programación. Luego comencé a trabajar en la administración en el MIT. Fui Rector Asociado de Equidad de Facultad. Eso fue lo que sucedió en la década de 2000.
Entonces decidí retirarme, y me retiré hace un par de años. Pero en 2012 dejé de trabajar en informática distribuida y desde entonces he estado trabajando en lenguajes de programación y máquinas multinúcleo solo para continuar ... Me gusta moverme y decidí que era hora de moverme alrededor por un tiempo, mientras que he estado haciendo esto.
Así que eso es lo que he hecho.
- Veamos. Un par de cosas Cuando estabas haciendo lo de 'Rector Asociado de Equidad de Facultad', ¿qué fue eso y cómo funcionó?
Bueno, cuando era Jefe Asociado de Ciencias de la Computación, estuve en ese puesto durante tres años y contraté a cinco mujeres en tres años después de un largo período en el que de alguna manera u otra nunca habíamos podido encontrar mujeres que pudieran ser contratadas. Y a todas estas mujeres les ha ido extremadamente bien, así que no era como si estuviera comprometiéndome por contratarlas. Me las arreglé para encontrarlas donde otras personas no podían verlas.
Entonces, la persona que ... Es una historia larga y complicada. Pero de todos modos, era este tipo de cosas, como tratar de asegurarse de que los departamentos de todo el Instituto estuvieran haciendo lo correcto en lo que respecta a las mujeres y las minorías subrepresentadas. Principalmente tenía que ver con que lo primero de todo que quiere son los datos. Entonces quieres saber lo que esta pasando. Entonces tu ... Hay muchos ... Deseas asegurarte de que la búsqueda se realiza correctamente y quieres asegurarte de que los jefes de departamento entiendan ciertas cosas básicas. Como, por ejemplo, es su responsabilidad asegurarse de que no se les pida a sus jóvenes de facultad hacer trabajos equivocados. Por ejemplo, muchas personas no entienden que las mujeres están mucho más dispuestas a decir que sí a las cosas que los hombres. Entonces, si dices: “¿Enseñarías este curso de laboratorio? Y, por cierto, debes tener en cuenta que es un trabajo realmente difícil ", es mucho más probable que una profesora asistente joven diga que sí que un hombre, por lo que hay que tener en cuenta este tipo de cosas. Así que fue solo ese tipo de cosas. Tratando de mejorar el Instituto asegurándonos de que estábamos haciendo un buen trabajo al respecto.
- ¿Y crees que has marcado la diferencia?
- Entonces, en general, ¿cómo te sientes respecto al MIT?
Oh, me encanta el MIT. Creo que ha sido un excelente lugar para trabajar. Quiero decir que el laboratorio también es un gran lugar. El MIT tiene este tipo peculiar de organización matricial donde hay departamentos y luego hacemos nuestra investigación en un laboratorio. Así que he estado en ... fue el Proyecto MAC, luego fue el Laboratorio de Ciencias de la Computación, luego nos fusionamos con el laboratorio de IA. Ahora es CSAIL - Laboratorio de Ciencias de la Computación e IA.
Pero el MIT ha sido maravilloso: la calidad de los estudiantes, la calidad del profesorado, el interés en investigar y comprender realmente las cosas desde los primeros principios. Quiero decir, creo que esto es cierto incluso en nuestros estudiantes universitarios. Quieren entender realmente las cosas y, por lo tanto, es un ambiente maravilloso. También he encontrado a mis colegas muy colaborativos. Me encanta venir a trabajar todos los días. Ha sido genial.
- Veamos. Un par de otras cosas que quería asegurarme de que cubrimos. Cuéntanos un poco sobre el propio Premio Turing. ¿Cuándo escuchaste que recibías el premio? ¿Cómo ha sido?
Recibí el premio ... Es el Premio Turing 2008. Lo recibí en 2009. Esto ha sido un misterio para mí por qué tienen este desplazamiento en años. Es algo histórico.
Me enteré porque recibí una llamada telefónica de Brian Randell. Él era el jefe del comité de Turing de ese año y lo conocía de los viejos tiempos. Era otra de las personas que trabajaba en metodología de programación en los días en que yo estaba en ese campo. Esa fue una gran sorpresa. Me dice que levanté el teléfono, "Soy Brian Randell". No lo había visto en años. Él dijo: "Será mejor que te sientes". [Risas] Así que fue genial.
Es maravilloso recibir el Premio Turing porque es una validación de lo que hiciste. Y lo que fue interesante para mí fue que, debido a la forma en que me he movido, había dejado de trabajar en abstracción de datos, lenguajes de programación, metodología. Acababa de trabajar en informática distribuida y ni siquiera estaba pensando en eso. Así que obtuve el premio y me hizo volver y pensar en cómo eran las cosas en los viejos tiempos.
La primera sorpresa fue que descubrí que mis alumnos realmente no sabían que había una vida antes de la abstracción de datos. Y en realidad ni siquiera conocían algunos de estos viejos documentos. Estaba bastante sorprendida por eso. Así que volví y releí todos esos papeles viejos. Fue muy interesante mirar hacia atrás. Y estos también son documentos extremadamente buenos. Es realmente una parte de nuestra historia que no debe olvidarse.
Como me gusta decirle a la gente, cuando recibí el premio, había mucho ruido en Internet, y mi esposo estaba en línea todos los días para ver qué era. Y, por supuesto, no todo lo que ves es agradable. De hecho, [risas] muchas cosas no son tan agradables. Entonces hay cosas buenas, hay cosas no tan buenas. Pero de todos modos, una cosa que descubrió un día fue una cita que decía más o menos “¿Por qué obtuvo el premio? Todo el mundo lo sabe de todos modos". Y pensé que era el cumplido más sorprendente, aunque no creo que fuera así. Pero para darme cuenta de que estas primeras ideas, no solo mías, sino por supuesto todo el trabajo que se había llevado a cabo en esos primeros años para comprender la abstracción de datos y las especificaciones y el lenguaje de programación, etc., para comprender que se habían trasladado de tal forma a la corriente principal que todos la conocían y eran la base de cómo se escriben todos los programas, quiero decir que fue algo notable de hacer entender.
- ¿Quieres decir algo sobre Java, que ciertamente muestra muchas señales de herramientas de tu ...
Bueno, entonces Java, me alegré mucho de ver a venir a Java porque era el primer lenguaje de programación convencional que realmente tenía estas ideas. Realmente tenía abstracción de datos y programación orientada a objetos. Realmente existía la noción de que las superclases deberían ser supertipos, la noción de interfaces define un tipo de comportamiento. Aplican el principio de sustitución de Liskov en el sentido de que un subtipo, una subclase, debe proporcionar a los métodos las firmas correctas que tiene la superclase.
Lo hubiera hecho de otra manera si hubiéramos sido yo, y Andrew y yo, Andrew Myers y yo intentamos convencerlos de que pusieran el polimorfismo en el idioma. Cuando salió por primera vez, no estaba allí. Por supuesto, cuando diseñas un lenguaje como este, debes decidir en qué es importante concentrarte, y qué vas a a dejar para más adelante. Entonces no es que esto sea necesariamente lo incorrecto. Simplemente no es lo que hubiera hecho. Creo que de alguna manera abrió las puertas para que esto se convirtiera ... En cierto modo, la razón por la que forma parte de la corriente principal es porque ahora está allí entre los lenguajes que las personas usan a diario.
Y se trasladó a C ++ en el tipo de forma de C ++. Desearía que la gente aplicara mejor la encapsulación. Creo que hacen un mejor trabajo en C #. A veces tienes que violar la encapsulación, como cuando estás construyendo una plataforma, por ejemplo una plataforma de depuración. Pero es mejor si pudieras limitar eso a las personas que tienen derecho a hacerlo en lugar de que sea algo que cualquier viejo programador pueda hacer.
Sabes, había muchas cosas, una especie de sabiduría en los viejos tiempos que las personas tal vez han perdido. Entonces, una cosa que aprendimos fue que leer código importaba mucho más que escribir código, porque el código se escribe una vez pero se lee muchas veces, primero por el autor y luego por otros. Había otra de la que te iba a hablar. Bueno, vendrá a mí. De todos modos, siento que algunas de estas lecciones del pasado han sido olvidadas, y tal vez sea igual porque a lo mejor significa que hemos progresado.
- Bueno, otra cosa de la que deberíamos hablar para grabar es la gente de la que has aprendido y que te ha influenciado.
Bueno, trabajé con John McCarthy. No diría que John fuese un asesor muy práctico, pero también sentí que John era una persona imparcial y ciertamente nunca sentí ningún tipo de comentario negativo como "Eres una mujer, no puedes hacerlo" o cosas así. Así que fue bueno y me entregó el tema de mi tesis cuando no pude avanzar en el aprendizaje automático, este "Programa para jugar finales de ajedrez", en el que pensó que sería bueno trabajar porque yo no jugaba al ajedrez. Y quería que lo abordara desde el punto de vista de "solo soy alguien que está aprendiendo y veo lo que dicen los libros y pienso en eso desde un punto de vista heurístico", lo que resultó ser bastante efectivo.
Creo que Niklaus Wirth también fue importante. Lo conocí como estudiante. Trató de convencerme de cambiar a lenguajes de programación y compiladores, y tenía razón en que era mucho más mi campo. No lo hice porque sentí que terminaría con el doctorado más rápido si me mantenía con la IA, lo que creo que también era correcto.
Por supuesto, he aprendido mucho de muchas personas cuyos documentos he leído y con quienes he hablado, técnicamente. Me refiero a Jerry Saltzer, todos esos años estuve enseñando 6.033, que era su curso, nuestro curso de sistemas y su forma de pensar sobre los sistemas. Corby, otro. Bob Fano, otro. Bob Fano es una persona maravillosa. Él es quien me contrató. Me dijo que era ingeniero. En realidad no me había dado cuenta de eso, y tenía razón. [risas] Creo que no sabía qué era un ingeniero. Y luego Jack Dennis fue de gran ayuda. Jack fue el que me sacó del piso de inteligencia artificial y me puso en el piso de sistemas y, en general, fue alentador y útil, especialmente en aquellos primeros años cuando estaba encontrando mi camino. Entonces diría que esas son las personas en las que pienso y creo que fueron útiles.
- Y a ver. Oh si. Entonces, ¿cómo ha sido esta experiencia para su familia?
- Él es profesor, ¿verdad?
No, no lo es. Estuvo en William and Mary por un tiempo, pero ahora trabaja para Mitre y realiza investigaciones de seguridad.
- Interesante
Sí, genial. Y mi esposo ha sido muy solidario y servicial. No creo que pueda hacerlo sin ... Necesitas un cónyuge servicial. Así que creo que es ... No sé cómo ha sido para mi familia, pero tengo una familia y todo salió bien.
- Bien, veamos. Has ganado muchos otros premios.
Sí. Bueno, gané la Medalla von Neumann del IEEE en realidad unos años antes de recibir el Turing, y también obtuve algo de honor ... Sabes, tengo ... Sí. Creo que hay una tendencia una vez que obtienes un premio, más o menos vienen más.
- Tienes un título honorífico de ETH.
Si, es así. Ese fue el primer título honorario que obtuve. Entonces, como saben, ETH es una de las mejores escuelas de Europa y una buena escuela de ciencia y tecnología, así que sí.
Y la otra cosa sobre el Premio Turing es que te llaman para viajar mucho. Entonces, en la pareja, dos o tres años después, viajé y viajé y viajé por todo el mundo. Y todavía sucede, aunque no tanto como antes. Así que ha sido muy divertido. Y mi esposo vino conmigo, así que hemos podido experimentar eso juntos.
- Entonces, ¿cuales fueron los lugares más importantes que fuiste?
- Bueno, ¿hay otras cosas que no cubrimos que deberíamos tener?
[risas] Me parece que hemos hecho un buen trabajo cubriendo cosas.
- Bueno, entonces ... Gracias. Muchísimas gracias por su tiempo.
Gracias por tu tiempo. Ha sido divertido. Gracias.
Twitter: https://twitter.com/macajo/status/1195693508457316353?s=20https://twitter.com/macajo/status/1195693508457316353?s=20https://twitter.com/macajo/status/1195693508457316353?s=20ttps://twitter.com/macajo/status/1195693508457316353?s=20
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.