El tema del libro es cómo usar la IA generativa con criterio. Parece evidente, pero no lo es. Hay libros que te enseñan a escribir prompts, otros a usar la herramienta de moda (ChatGPT o Claude). Pero ¿acaso no hay principios de uso subyacentes a toda herramienta de IA generativa? Los que me han leído sabrán, con razón, que esa pregunta siempre ronda todos mis libros: conceptos sobre herramientas, aunque sin caer en la pura teoría. Si las ideas no compilan de alguna forma, no me interesa.

Así pues, este librito, corto y conciso, busca enseñar algo más simple: cómo pensar antes de preguntarle a la IA; quizá, más preciso: cómo dialogar con la IA para que usted la use y no ella a usted.

Volviendo al segundo punto. Mis libros anteriores partían de la idea de proyectos de investigación. Para mí escribir es aprender, investigar y, en el camino, ir escribiendo, siempre escribiendo. El caso más evidente fue cuando me puse a investigar sobre cómo se originó la escritura humana para poder escribir mi libro Palabras y Algoritmos. Cómo la IA transformará la escritura (2025); sin esa investigación, ese libro no hubiese existido. Este libro, en cambio, es diferente. Al hacerlo más amplio en cuanto al público, el tema es más general y exige un lenguaje simple y directo; la prosa —o sea, la forma— pasa a un segundo plano. Y mi deber fue plasmar lo que hago en mi investigación científica en un lenguaje llano, cercano y amigable, sin engordarlo de referencias y notas a pie de página. Es decir, que usted lo pueda leer en una tarde, camino a la playa o en el metro; que saque ideas sin exigencia.

Fue un experimento divertidísimo. Que aún no termina, ya que este año saldrán otros tres libritos sobre temas similares.

¡Nos vemos!1

Lo pueden conseguir tanto en Amazon.es como en Marcombo:

En mi faceta de investigador, he estado trabajando en incorporar los LLM a mi área: diseño e implementación de metaheurísticas para problemas de optimización. Hemos tenido buenos resultados, y al mismo tiempo mantengo un pie en la industria, asesorando a empresas de minería chilenas para incorporar IA en sus productos.

Pero hay más: hoy he iniciado la aventura de escribir mi primer libro de investigación en inglés, para Springer, en coautoría con mi director de tesis y una gran investigadora, sobre Search Trajectory Networks, mi segunda línea de investigación doctoral.2 Ah, mi tesis doctoral: mañana la deposito y debería defenderla pronto. Son 279 páginas.

Mi vida está sufriendo muchos cambios. Dejaré las penurias de sobrevivir con una beca doctoral para pasar a una nueva etapa, mejor, acaso. Me ofrecieron un postdoc en Barcelona y las asesorías se afianzan, mientras sigo dando clases y charlas, aunque con menos frecuencia que antes. Todo esto refleja lo que sospecho que ustedes ya intuyen: me gusta estar en varios frentes: la ciencia, la filosofía,3 la ingeniería y la enseñanza. Con un hilo en común: la informática.

Sin embargo, debía pausar la divulgación, porque la mejor forma de divulgar es primero estar en el «campo de batalla» y después retirarse a compartir. Todo el conocimiento y la experiencia que estoy adquiriendo, tanto en la academia como en la industria, se transformarán en nuevos episodios de pódcast, nuevas entradas en este blog y, por supuesto, en nuevos libros en español.

¿Me esperarán?

Suscríbete ahora

William Faulkner, el famoso escritor estadounidense, escribió: «Nunca pierdas el tiempo lamentando errores. Basta con que no los olvides». Un destino común entre todos los programadores es la vivencia de los errores. Errores de código. Todos han cometido errores en su carrera. Unos más evidentes, obvios, absurdos, simplones; y otros, más sofisticados e inverosímiles, que llevaron horas y horas de depuración hasta encontrar su causa. Los errores son instructivos pero no iguales. Lo que cambia es la forma de percibirlos, de vivirlos, de incluso corregirlos. Una vivencia subjetiva. De ahí nace una diferencia que radica en la experiencia y personalidad del programador.

Un error emerge de una arquitectura. Sí, una arquitectura. Una estructura que impone límites: podemos moldearla, pero no reestructurarla por completo. Los humanos tenemos una arquitectura cognitiva basada en procesos mentales y sistemas de mecanismos —producto de la evolución— que nos permite generar código, pero no exento de errores. Un error de tipeo, una confusión al entender el requerimiento de un cliente, la elección equivocada de una tecnología, o código que funciona (verificación) pero que no cumple lo requerido (validación). Todo ello puede deberse al cansancio, a sesgos cognitivos, a limitaciones de nuestra memoria de trabajo. Somos tan falibles como el software.

Puesto frente a nosotros, cara a cara, la IA generativa también genera código. Y si genera código, también genera errores. Al igual que los humanos, la IA generativa cuenta con una Arquitectura de Error —no biológica ni cognitiva sino artificial— que se basa en capacidades estocásticas y en patrones estadísticos. Sus errores suelen ser semánticos, producto de la ausencia de contexto y del peso y calidad de su conjunto de entrenamiento.

Lo que hace verdaderamente experto a un programador es la capacidad de conocer su propia Arquitectura de Error: sus propios límites. No sus aciertos ni la cantidad de proyectos exitosos que haya conseguido. Esos límites son los que marcan las decisiones de diseño e implementación. Y, a su vez, conocer otras Arquitectura de Error —como la de la IA generativa—, sus similitudes y diferencias en cuanto a errores, es esencial para construir ese nuevo territorio compartido: software híbrido, tejido por errores humanos y errores artificiales.

Quizá, hoy, convenga más aprender del origen de nuestros errores que de sus soluciones.

Si te interesa este tema, te invito a leer mi artículo en inglés:

Architectures of Error: A Philosophical Inquiry into AI-Generated and Human-Generated Code

Suscríbete ahora

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Jeffrey Ullman ganó, junto a Alfred Aho, el Premio Turing de la ACM en 2020 por sus aportes fundamentales a los compiladores y a la teoría de los lenguajes de programación.

Autor de multiples libros que, con el paso de los años, se han consolidados como clásicos de la ciencias de la computación. El «libro del dragón», como se conoce a Compilers: Principles, Techniques and Tools (1985), hoy, más de tres décadas de su publicación, se considera la «biblia» de los compiladores y ha marcado a una generación de entusiastas de la computación. También es autor de libros sobre bases de datos, teoría de la computación, mineria de datos y de algoritmos y estructuras de datos.1

Y, como se puede ver en esta entrevista, nada relacionado con la computación le es ajeno. Conversamos sobre el origen de la icónica portada del «libro del dragón» —donde aparece un guerrero enfrentando a un dragón—, sobre sus reflexiones en torno a la Inteligencia Artificial Generativa, e incluso sobre qué estrategias recomienda para hacer investigación. Deja, además, consejos que merecen ser recordados.

Le estoy profundamente agradecido a Jeffrey por su generosidad a la hora de responder a mis preguntas.

¡Espero la disfruten!2

Versión traducida

(1) Me gustaría empezar con una curiosidad. Cuando entrevisté a Alfred Aho, no pude evitar preguntarle cómo surgió la idea del dragón de la portada de «Principles of Compiler Design», y me respondió: «La idea del dragón de la portada de nuestro libro de 1977, 'Principles of Compiler Design', se debe a Jeff Ullman. La portada es una alegoría basada en 'Don Quijote', la novela épica de Miguel de Cervantes publicada en 1605». Así que me gustaría preguntarle a usted cómo se le ocurrió la conexión con Don Quijote, ya que resuena profundamente entre los lectores de habla hispana.

A decir verdad, no estaba seguro de que la teoría que promovíamos en el Libro del Dragón (Dragon Book) fuera realmente a ser eficaz. Así que en la portada puse un dibujo que sugería que los métodos que promovíamos, como el análisis sintáctico LR(k) o la traducción dirigida por sintaxis, eran realmente eficaces para «matar al dragón», que era el objetivo de facilitar la escritura de compiladores. Pero luego, para reconocer mi preocupación de que la teoría en realidad no iba a ser tan eficaz, sugerí que en realidad solo estábamos «luchando contra molinos de viento», como dice la expresión (sin duda derivada del libro de Don Quijote). Irónicamente, las herramientas específicas que mencionamos sí resultaron ser muy eficaces, aunque otras partes de un compilador nunca se doblegaron realmente a la teoría en gran medida.

(2) En su artículo de la conferencia del Premio Turing de 2020, «Abstractions, Their Algorithms, and Their Compilers» (Las abstracciones, sus algoritmos y sus compiladores), termina con la siguiente frase: «Sería muy beneficioso contar con abstracciones que orienten la creación eficiente de aplicaciones robustas mediante aprendizaje automático». Ahora, en 2025, con la adopción generalizada de la IA generativa, ¿cómo ve el futuro de la abstracción, considerando que el código es generado cada vez más no solo por humanos sino también por sistemas de IA?

En todo caso, la situación es peor. Todavía no tenemos ninguna teoría útil para responder a muchas preguntas sobre las redes profundas (deep nets), por ejemplo, que tan propensa es a clasificar erróneamente ante pequeños cambios en la entrada (p. ej., una foto de un gato se clasifica como un perro cuando cambias 10 píxeles). Y los LLM (Modelos de Lenguajes Colosales) son aún más opacos. No tenemos ni idea de cómo prevenir los «jailbreaks», por ejemplo, casos en los que un LLM revela información para la que fue específicamente entrenado para no divulgar.

También menciona el código generado por LLM. Creo que las abstracciones son especialmente importantes cuando quieres dar al LLM una instrucción (prompt) que te consiga el código correcto. Necesitas poder describir lo que quieres que haga el código, pero de una manera abstracta que transmita la idea en mucho menos espacio que el código que se va a generar.

(3) Ser autor de libros de informática tan populares es bastante poco común. ¿Cómo fue la experiencia de escribir tantos libros influyentes y verlos alcanzar una difusión tan amplia? ¿Qué significa escribir para usted?

Cuando empecé a trabajar en Bell Labs, y John Hopcroft estaba de año sabático en nuestro grupo, me dijo: «Ullman, si queremos ser famosos, tenemos que escribir un libro». Así que acordamos trabajar sobre teoría de autómatas, porque ambos habíamos estudiado el tema y el libro existente era, en nuestra opinión, demasiado difícil de leer para los estudiantes. El primer libro que hicimos fue un desastre. No sabíamos escribir y cometimos muchos errores que no se corrigieron hasta que estuvimos en las pruebas de imprenta (galeradas), cuya corrección fue muy cara para el editor; no estaban contentos con nosotros. Ahora, no solo la tecnología es más simple, por lo que las correcciones son fáciles, sino que, como con cualquier cosa, cuando la practicas lo suficiente, acabas haciéndolo bien. Así que producir libros en serie se volvió para mí más rápido y fácil.

(4) En su larga carrera en ciencias de la computación, ha trabajado en lo que podría llamarse el «núcleo» de la disciplina: compiladores, algoritmos, lenguajes de programación, bases de datos. ¿Qué —o quién— le inspiró en su juventud a abordar estos desafíos fundamentales? Le pregunto esto porque vivimos en un mundo cada vez más especializado donde a menudo se pasan por alto los fundamentos.

En los primeros días de la ciencias de la computación, había muy poco contenido y muy pocos tipos diferentes de software que fueran significativos. Incluso las bases de datos no eran realmente «algo» establecido hasta mediados de la década de 1970. Así que podías saber algo de casi todo lo que se consideraba «ciencia de la computación». Dicho de otro modo, todo lo que teníamos disponible como desafíos estaba en un área que ahora consideramos «fundamental».

(5) Durante décadas, la informática ha oscilado entre la búsqueda de fundamentos formales y la presión por soluciones pragmáticas. ¿Cómo ha vivido usted esa tensión entre la elegancia teórica y la utilidad práctica? ¿Cree que ahora estamos más cerca de reconciliar estas dos dimensiones, o más lejos?

Diría que ligeramente más cerca. No es que la teoría y la práctica tengan que reconciliarse, sino que los líderes en muchos campos han reconocido que la teoría tiene un papel que desempeñar en el desarrollo de software útil. Al principio, realmente no teníamos idea de qué tipo de teoría sería útil, así que la gente hacía prácticamente lo que quería y lo llamaba «teoría de las ciencias de la computación». Irónicamente, fue el éxito de cosas como la teoría del análisis sintáctico (parsing), donde matemáticas sofisticadas realmente redujeron el tiempo necesario para diseñar e implementar un analizador sintáctico (parser) de meses a horas, lo que hizo creer a la gente que todo iba a someterse a una teoría. Llevó un tiempo darse cuenta de que eso era falso. Algunas cosas son realmente mejores porque a alguien se le ocurrió la abstracción correcta o el enfoque matemático adecuado, pero otras cosas simplemente no parecen tener una teoría útil.

(6) A lo largo de su carrera, ha abordado algunos de los problemas más fundamentales de la informática. ¿Cuál diría que ha sido el problema técnicamente más desafiante al que se ha enfrentado y cómo lo abordó para resolverlo, tanto intelectual como prácticamente?

Bueno, nunca tuve la paciencia para trabajar en algo durante más de una semana. Pero déjeme hablarle del desafío que finalmente se llamó «Datalog». Alrededor de 1983, noté que la comunidad de IA trataba los datos de forma muy parecida a la comunidad de bases de datos, pero en lugar de usar lenguajes como SQL que eran tanto tratables (las consultas podían ejecutarse en tiempo polinómico) como optimizables (SQL, al menos en su núcleo, es lo suficientemente simple como para saber si dos consultas eran equivalentes en lo que hacían), la IA buscaba formas de lógica cada vez más complejas que, si bien podían expresar más que SQL, no eran ni tratables ni optimizables. Así que me propuse plantear una versión de la lógica —colecciones de cláusulas de Horn de primer orden («si esto y esto y... entonces aquello»)— que pudiera hacer lo esencial de SQL, pero que también pudiera hacer recursión, algo que el SQL de la época no podía. Este lenguaje, «Datalog», también era tratable y, como demostró la investigación posterior, bastante bien optimizable.

Pero el gran desafío fue político y se extendió durante décadas. A la gente de IA no le gustó porque era demasiado débil, y a la gente de bases de datos no le gustó porque no veían la necesidad de la recursión. Una forma de recursión inspirada en Datalog finalmente se incorporó al estándar SQL98 y ahora es implementada por los principales proveedores. Uno de los algoritmos de optimización que surgió de la investigación de Datalog —los «conjuntos mágicos» («magic sets»)— se implementó, pero en otro contexto inesperado, en el compilador SQL de IBM incluso antes de eso. Fue implementado a escala por LogicBlox y se ha utilizado de diversas formas inesperadas, p. ej., el uso de Joe Hellerstein en el análisis de sistemas distribuidos o el uso de Monica Lam en la optimización de código.

(7) Espero que esto no suene a cliché, pero es una pregunta que despierta curiosidad. ¿Qué consejo le daría a un joven investigador que espera hacer contribuciones significativas a la informática en esta era de cambios rápidos, donde tendencias como la IA y los enfoques basados en datos a menudo acaparan la atención?

Aquí va una sugerencia con la que pocos están de acuerdo, pero que en la práctica es bastante buena. La gente asume que la forma de investigar es leer todo sobre un campo y luego abordar uno de los problemas abiertos que encuentras al final de algunos artículos. Creo que eso es un error por la siguiente razón. Alguien puede ver un problema real, uno que realmente necesita una solución. Intenta resolverlo, avanza algo, pero no lo resuelve del todo. Así que escriben un artículo y, al final, sugieren que alguien complete la solución. Otra persona lee ese artículo. Tampoco puede resolverlo, pero realmente no conoce la necesidad práctica que abordaba el artículo. Para ellos era solo una cuestión abstracta. Así que juguetean con ello, encuentran algo cercano a lo que es el problema abierto, pero que quizás no aborda realmente el problema central, y escriben un artículo al respecto y lanzan algo que no pudieron hacer como un «problema abierto». Una tercera persona toma ese artículo, tiene menos comprensión del problema real, pero resuelve una parte del «problema abierto» y plantea otra cosa como abierta. A medida que este proceso continúa, los artículos se alejan cada vez más del problema real, y la gente simplemente escribe artículos cuyos resultados no son realmente útiles. La conclusión es: «no confíes en que valga la pena resolver un problema solo porque alguien más diga que está 'abierto'».

Lo que solía decir a mis estudiantes es que lean lo suficiente para entender la terminología y las abstracciones o modelos básicos que tiene un campo, pero que luego sigan su propio camino. Elijan un problema cuya solución sea útil y vean si pueden resolverlo. Luego tienen que revisar la bibliografía para asegurarse de que lo que han hecho es verdaderamente original. Ocasionalmente, su búsqueda descubrirá algo que está incómodamente cerca de lo que han hecho, y tienen que reconocerlo. He visto esfuerzos perdidos por ese efecto. Pero es raro. Más a menudo, lo que tienen es nuevo. Y como empezaron con un problema cuya utilidad identificaron ustedes mismos, saben que lo que tienen merece la pena.

Suscríbete ahora

Original

(1) I'd like to start with a curiosity. When I interviewed Alfred Aho, I couldn't help but ask about how the idea for the dragon on the cover of "Principles of Compiler Design" came about, and he replied: "The idea for the dragon on the cover of our 1977 book 'Principles of Compiler Design' is due to Jeff Ullman. The cover is an allegory based on 'Don Quixote', Miguel de Cervantes' epic novel published in 1605." So I’d like to ask you how the connection with Don Quixote came to you, as it resonates deeply with Spanish-speaking readers.

To tell the truth, I was not confident that the theory we were promoting in the Dragon Book was really going to be effective. So on the front I put a drawing that suggested the methods we were promoting, like LR(k) parsing or syntax-directed translation were really effective in "slaying the dragon," which was the goal of making it easier to write compilers. But then, to acknowledge my concern that the theory wasn't actually going to be that effective, i suggested that we were really just "tilting with windmills," as the expression goes (undoubtedly derived from the don Quixote book). Ironically, the specific tools we mentioned did turn out to be very effective, although other parts of a compiler never really yielded to theory to any great extent.

(2) In your 2020 Turing Award lecture article "Abstractions, Their Algorithms, and Their Compilers", you end with the following sentence: "Abstractions that could guide the efficient creation of robust applications using machine learning would be very beneficial." Now, in 2025, with the widespread adoption of generative AI, how do you see the future of abstraction, considering that code is increasingly being generated not only by humans but also by AI systems?

If anything, the situation is worse. We still have no theory that is useful for answering a lot of questions about deep nets, e.g., how prone is it to misclassifying under small input changes (e.g., a cat picture gets classified as a dog when you change 10 pixels). And LLMs are even more opaque. We have no idea about how to prevent "jailbreaks," for example, where an LLM will give out information that it was specifically trained not to do.

You also mention LLM-generated code. I think abstractions are especially important when you want to give the LLM a prompt that will get you the right code. You need to be able to describe what you want the code to do, but in an abstract way that gets the point across in much less space than the code to be generated.

(3) Being the author of widely popular computer science books is quite uncommon. What was the experience like of writing so many influential books, and seeing them become so widely read? What does writing mean to you?

When I started working at Bell Labs, and John Hopcroft was on sabbatical in our group, he said to me "Ullman, if we want to be famous people, we have to write a book." So we agreed to work on automata theory, because we both had studied the subject and the existing book was, we felt, way too hard for students to read. The first book we did was a mess. We didn't know how to write, and we messed up a lot that didn't get fixed until we were in page proofs (which were very expensive for the publisher to fix -- they were not happy with us). Now, not only is the technology simpler, so corrections are easy, but like anything, when you practice it enough, you eventually get good at it. So churning out books for me became both quicker and easier.

(4) In your long career in computer science, you have worked on what might be called the "core" of the discipline: compilers, algorithms, programming languages, databases. What —or who— inspired you in your younger days to take on these foundational challenges? I ask this because we are living in an increasingly specialized world where the fundamentals are often overlooked.

In the early days of CS, there was very little content, and very few different kinds of software that were significant. Even databases were not really a thing until the mid-1970s. So you could pretty much know something about everything that was considered "computer science." Put another way, everything we had available as challenges was in an area we now consider "core."

(5) For decades, computer science has oscillated between the pursuit of formal foundations and the pressure for pragmatic solutions. How have you experienced that tension between theoretical elegance and practical usefulness? Do you think we are now closer to reconciling these two dimensions—or further apart?

I would say slightly closer. It's not that theory and practice have to be reconciled, but the leaders in many fields have recognized that theory has a role to play in developing useful software. In the early days, we really had no idea what sorts of theory would be useful, so people did pretty much anything they wanted and called it "CS theory." Ironically, it was the success of things like theory of parsing, where some sophisticated mathematics really did reduce the time it took to design and implement a parser from months to hours, that made people believe everything was going to yield to a theory. It took a while to realize that was false. Some things really are better because someone came up with the right abstraction or the right mathematical approach, but other things just don't seem to have a useful theory.

(6) Over the course of your career, you’ve tackled some of the most fundamental problems in computer science. What would you say has been the most technically challenging problem you’ve faced, and how did you go about solving it—both intellectually and practically?

Well I never had the patience to work on something for more than a week. But let me talk about the challenge that eventually was called "Datalog." Around 1983, I noticed that the AI community was dealing with data much like the database community was, but instead of using languages like SQL that were both tranctable (queries could be executed in polynomial time) and optimizable (SQL, at least its core, is sufficiently simple that you can tell if two queries were equivalent in what they did), AI was looking at more and more complex forms of logic that, while they could express more than SQL, were neither tractable nor optimizable. So I set out to propose a version of logic -- collections of first-order Horn clauses (if this and this and... then that), that could do the core of SQL, but also could do recursion, which the SQL of the day could not. This language, "Datalog," was also tractable and, as research later showed, pretty well optimizable.

But the big challenge was political, and extended over decades. AI folks didn't like it because it was too weak, and database people didn't like it because they saw no need for recursion. A form of recursion that was inspired by Datalog eventually found it into the SQL98 standard and is now implemented by major vendors. One of optimization algorithms that came out of the Datalog research -- "magic sets" -- was implemented, but in another, unexpected context, in IBM's SQL compiler before that. It was implemented at scale by LogicBlox, and it has been used in various unexpected ways, e.g., Joe Hellerstein's use in analysis of distributed systems, or Monica Lam's use in code optimization.

(7) I hope this doesn’t sound like a cliché, but it’s a question that sparks curiosity. What advice would you give to a young researcher who hopes to make meaningful contributions to computer science in this era of rapid change, where trends like AI and data-driven approaches often dominate the spotlight?

Here's one suggestion that few agree with, but in practice is pretty good. People assume the way you do research is you read everything in a field, and then tackle one of the open problems that you find at the end of some papers. I think that is a mistake for the following reason. Someone may see a real problem -- one that really needs a solution. They try to solve it, get somewhere, but don't really solve it. So they write a paper and at the end, they suggest someone complete the solution. Someone else reads that paper. They can't solve it either, but they really don't know the practical need the paper was addressing. To them it was just some abstract question. So they fiddle around with it, find something that is close to what the open problem is, but perhaps not really addressing the core problem, and they write a paper about it and throw out something they were unable to do as an "open problem." A third person, picks up that paper, has less understanding of the real problem, but solves a part of the "open problem" and poses something else as open. As this process continues, the papers get further and further away from the real problem, and people are just writing papers whose results are not really useful. The bottom line is "don't trust that a problem is worth solving just because someone else says it is "open."

What I used to tell my students is to read enough that you understand the terminology and basic abstractions or models that a field has, but then go off on your own. Pick a problem whose solution would be useful, and see if you can solve it. You then have to check the literature to make sure that what you have done is truly original. Occasionally, your search will uncover something that is uncomfortably close to what you have done, and you have to acknowledge that. I've seen effort lost because of that effect. But it is rare. More often, what you have is new. And because you started with a problem whose use you yourself identified, you know that what you have is worthwhile.

Cuando comencé a escribir Palabras y Algoritmos quería, por una parte, presentar la importancia que ha tenido la escritura, como tecnología, en el desarrollo de nuestras sociedades y, por otro, como la inteligencia artificial cambiará nuestra manera de interactuar con ella. Antes de la escritura, la oralidad era el mecanismo predominante para transmitir información, y se tenían que hacer grandes esfuerzos para entrenar la memoria para pasar un mensaje de un lugar a otro. Las limitaciones eran muchas. Con la escritura éramos capaces, por primera vez en la historia, poder revivir las experiencias de hombres y mujeres en la antigüedad, conocer tanto sus alegrías como sus temores. A su vez, podíamos dejar registro de intercambio de bienes y de compra y ventas de productos. Pero la escritura no es matemática, está a merced de las interpretaciones, de las emociones, de los sesgos de sus autores. O, como diría Wittgenstein: «de los juegos de lenguajes». Y replicarla se vuelve un desafío sumamente complejo.

En 2022, cuando se lanzó ChatGPT sentí que, por primera vez, una máquina era capaz de entender el lenguaje escrito, y no solo eso, sino de analizarlo y proponer mejoras, detectando sutilezas en el juego de palabras: como la ironía, el sarcasmo, y diferentes figuras retóricas como las metáforas o las anáforas. Estos modelos generativos —como ChatGPT— no son «loros estocásticos» como algunos investigadores afirmaron con rotundidad, sino que cuenta con sorprendentes capacidades de detectar patrones en los textos, «loros estocásticos hábiles en la conversación». Acercándonos a una nueva etapa en la creación de tecnología, donde no solo seremos capaces de generar textos, sino también imágenes y contenido audiovisual. Contenido a nuestra medida. Y para el escritor será una ayuda, una suerte de editor en las sombras alertándonos de cuando nos desviemos del camino, no un reemplazo.

Palabras y Algoritmos es un ensayo que narra mi amor por las humanidades y la informática. Una invitación hacia los sucesos y personas que dieron forma a la escritura humana; mientras conocemos el sueño de algunos informáticos que pensaron, con cierta ingenuidad, que aquellas máquinas —algún día— podrían ser capaces de desafiar una de las actividades creativas que nos diferencian de otras especies.

El libro se encuentra en preventa. Y estará disponible oficialmente el 23 de enero del 2025.

Además, contiene el prólogo de mi buen amigo David Sanchez Molina, Investigador de la Universitat Politècnica de Catalunya.

Pueden leer un extracto aquí:

https://www.researchgate.net/publication/386334083_Palabras_y_Algoritmos

Suscríbete ahora

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Grady Booch es uno de los pioneros en el campo de la ingeniería de software. Es principalmente conocido por ser uno de los creadores del Lenguaje Unificado de Modelado (UML) junto con Ivar Jacobson y James Rumbaugh, y por desarrollar el Método Booch, una metodología para el desarrollo de software orientado a objetos.

Nacido en 1955, Booch ha dedicado su carrera a avanzar las prácticas de desarrollo de software. Actualmente es Científico Jefe y miembro de IBM Research, donde continúa investigando en áreas como arquitectura de software, inteligencia artificial y desarrollo de software. En su lado «menos polémico» lo podemos leer con frecuencia en su cuenta de Twitter/X, donde se mantiene implicado en cómo la informática se integra a la sociedad.

Sus contribuciones al campo incluyen:

• El desarrollo del Método Booch para diseño orientado a objetos.

• La cocreación de UML, que se convirtió en el estándar de facto para el modelado de software.

• La autoría de varios libros influyentes, incluyendo Object-Oriented Analysis and Design with Applications.

• Su trabajo pionero en patrones de arquitectura de software.

Un apunte: UML ha repercutido a toda la informática, pues a medida que el software va creciendo su complejidad aumenta y, por tanto, se vuelve necesario —e inevitable— diseñar herramientas visuales. Incluso los más críticos de UML, no pueden evitar dibujar figuras geométricas en la pizarra, que se van relacionando y que nos recuerdan a, sí, UML :-)

Booch ha recibido numerosos reconocimientos por sus contribuciones, incluyendo el premio Lovelace de la Association for Computing Machinery (ACM) en 2012 y el IEEE Computer Society Computer Pioneer en 2016.

Algunas de sus citas memorables:

1. «La función de un buen software es hacer que lo complejo parezca simple».

   1. Que se puede combinar con «La tarea del equipo de desarrollo de software es diseñar la ilusión de simplicidad».

2. «El ingeniero de software aficionado siempre está en busca de magia».

3. «Toda la vida es iterativa. Esto nos lleva de nuevo al punto que mencioné antes, que es que no se puede saber a priori lo suficiente como para siquiera hacer las preguntas correctas».

¡Espero disfruten de esta corta pero interesante entrevista!1

Versión traducida

(1) A lo largo de tu extensa carrera en ingeniería de software, has sido testigo de la evolución de muchas tecnologías y paradigmas. ¿Cuáles han sido los hitos más importantes que has presenciado y cómo crees que han dado forma al campo de la ingeniería de software?

La transición de lenguajes y métodos algorítmicos a orientados a objetos representó un cambio masivo; el auge de los sistemas distribuidos a través de Internet, particularmente con dispositivos móviles, cambió la naturaleza misma del desarrollo.

Es justo decir que el campo de la ingeniería de software está en constante cambio.

Y eso es algo bueno.

(2) Fuiste uno de los creadores de UML, una herramienta fundamental en el diseño de sistemas. Más de dos décadas después de su introducción, ¿cómo ves la relevancia actual de UML en la industria, y qué mejoras crees que deberían hacerse para adaptarlo a las necesidades actuales?

El lenguaje unificado de modelado alcanzó quizás una penetración del 20% en todo el campo, lo cual es francamente bastante grande, pero lo más importante es que introdujo una forma diferente de pensar sobre el desarrollo de software, y eso perdura: las clases y objetos son tanto parte de la atmósfera del desarrollo de software que es como un pez pensando en el agua.

Independientemente del UML, sigue existiendo la necesidad de visualizar y razonar sobre la arquitectura de sistemas intensivos en software; de hecho, mira los diagramas de AWS para arquitectura, o la forma en que tratamos de visualizar sistemas de IA generativa.

(3) Con el avance de la IA generativa (de la cual he visto que has sido crítico), muchos predicen que parte del proceso de desarrollo de software será automatizado. ¿Cuál es tu perspectiva sobre cómo la IA cambiará el papel de los ingenieros de software y científicos de la computación en los próximos años?

No soy crítico de la IA generativa; soy crítico de las empresas e individuos que exageran la IA generativa más allá de lo que es capaz de hacer.

La IA cambiará la naturaleza del desarrollo de software de la misma manera que lo hicieron los compiladores: ayudan a elevar el nivel de abstracción del desarrollo.

(4) Eres un fuerte defensor de la ética en el desarrollo de software. En un mundo donde la IA tiene un impacto cada vez mayor, ¿cómo podemos asegurar que las tecnologías emergentes se desarrollen y utilicen éticamente? ¿Cuál será el papel de la filosofía en este proceso?

Esa es la pregunta correcta y difícil. El problema es que hay individuos intensamente ricos que realmente no se preocupan por la ética y ese es el mayor obstáculo.

La educación es clave; el hecho de que ACM, IEEE, AAAI y otras organizaciones profesionales estén impulsando la ética de la IA me da esperanza.

(5) Mirando hacia el futuro, más allá de la inteligencia artificial y las tecnologías actuales, ¿qué tendencias emergentes en ciencias de la computación crees que tendrán el impacto más profundo en nuestra sociedad y en la forma en que interactuamos con la tecnología?

La computación se ha movido hacia los espacios intersticiales de la sociedad, y eso es simultáneamente maravilloso y desafiante.

Los modelos basados en transformadores son, en mi opinión, útiles aunque un callejón sin salida arquitectónico, y creo que veremos el surgimiento de sistemas neurales simbólicos.

(6) Sé que te apasionan los libros. Si tuvieras que recomendar algunos libros a nuevos científicos de la computación que están comenzando en el mundo actual, un mundo donde la ciencia de la computación parece conectarse con muchas áreas del conocimiento, particularmente las humanidades, ¿cuáles elegirías y por qué?

Mira algunos clásicos: The Human Use of Human Beings de Wiener y The Pattern on the Stone de Hillis.

(7) Si tuvieras la oportunidad de viajar en el tiempo y darle un consejo no técnico a tu yo más joven, ¿cuál sería y por qué lo consideras importante?

Compra más acciones de Apple y NVIDIA :-)

Original

(1) Throughout your extensive career in software engineering, you've witnessed the evolution of many technologies and paradigms. What have been the most important milestones you've witnessed, and how do you think they have shaped the field of software engineering?

The transition from algorithmic, languages and methods to object oriented ones represented a massive change; the rise in distributed systems via the Internet in particular with mobile devices change the very nature of development.

It is fair to say that the field of software engineering is under constant change.

And that's a good thing.

(2) You were one of the creators of UML, a fundamental tool in system design. More than two decades after its introduction, how do you see UML's current relevance in the industry, and what improvements do you think should be made to adapt it to current needs?

The unified modeling language achieved perhaps a 20% market penetration throughout the field, which is frankly quite large, but most importantly, it introduced a different way of thinking about software development, and that endures: classes and objects are so much a part of the atmosphere of software development that it is akin to a fish thinking about water

Independent of the UML, there remains need to visualize and reason about the architecture of software intensive systems; indeed, look at AWS’s diagrams for architecture, or the way we try to visualize genAI systems.

(3) With the advancement of generative AI (which I've seen you being critical of), many predict that part of the software development process will be automated. What's your perspective on how AI will change the role of software engineers and computer scientists in the coming years?

I am not critical of generative AI; I am critical of the companies and individuals, who hype generative AI beyond what it is capable of doing

AI will change the nature of software development in the same way the compilers did: they help raise the level of abstraction of development.

(4) You're a strong advocate for ethics in software development. In a world where AI has an increasingly greater impact, how can we ensure that emerging technologies are developed and used ethically? What will be the role of philosophy in this process?

That is the right and hard question. The problem is you have intensely wealthy individuals who really don't care about ethics and that is the greatest stumbling block.

Education is key; the fact of the ACM, the IEEE, AAAI, and other professional organizations are pushing the ethics of AI gives me hope

(5) Looking toward the future, beyond artificial intelligence and current technologies, what emerging trends in computer science do you think will have the most profound impact on our society and the way we interact with technology?

Computing has moved itself into the interstitial spaces of society, and that is simultaneously wonderful and challenging.

Transformer based models are in my opinion  useful albeit an architectural dead end, and I think we will see the rise of neural symbolic systems.

(6) I know you're passionate about books. If you had to recommend some books to new computer scientists starting out in today's world, a world where computer science seems to connect with many areas of knowledge, particularly the humanities, which ones would you choose and why?

Look at some classics: The Human Use of Human Beings by Wiener and The Pattern on the Stone by Hillis.

(7) If you had the opportunity to travel back in time and give non-technical advice to your younger self, what would it be, and why do you consider it important?

Buy more Apple and NVIDIA stock :-)

Suscríbete ahora

Ahora estoy viviendo en un pequeño apartamento a las afueras de París, de unos 27 m², en la zona de Neuilly-Plaisance. Encontrar un lugar para vivir solo, con el dinero de una beca, es ya un logro. He evitado la incertidumbre de convivir con desconocidos. Pues nunca se sabe quién te puede joder el día. La vida, por tanto, ha transcurrido bien, estoy en una estancia doctoral —de dos meses— en el “impopular” Nokia Bell Labs, aprendiendo sobre Knowledge Graph y su integración con Large Language Models, mientras sigo avanzando en otros códigos y artículos y libros.

Mi cuarto libro se titula Palabras y Algoritmos. ¿Cómo la Inteligencia Artificial transformará la escritura? (Editado por Marcombo). La idea surgió a mediados del 2023, cuando estaba todo el revuelo de ChatGPT. Entre los múltiples usos que le di a ésta tecnología, estuvo usarla como un editor: encontrar horrores ortográficos, frases absurdamente complejas, repeticiones de palabras innecesarias y otras cosas. Entonces me di cuenta de que, bien usada, esta tecnología podría ayudarnos en la escritura. No para evitar que escribamos usando un prompt del tipo: “Dame la introducción a mi libro de programación, porque no sé escribir y quiero seguir siendo inhábil”, no, más bien como un editor sofisticado que conoce tu prosa y le ahorra tiempo a un editor humano.

En este libro, de unas 200-250 páginas, que es mi primer ensayo, exploro cómo se relaciona la escritura humana y la escritura artificial. Como la escritura humana es una tecnología, y cómo ha evolucionado en el tiempo, mientras convive con los avances tecnológicos de la IA. En él presento la idea de “escritura simbiótica”, que viene a ser una nueva forma de escritura humana asistida por la IA, pero que no busca ser un reemplazo a la creatividad humana, ni ser un alentador de la pereza, sino un potenciador creativo. Fue una excusa para leer y aprender sobre temas fuera de mi campo de estudio, como también medio para rendirle homenaje a escritores que admiro. Y es que siempre me he declarado un Informático Humanista, que significa simple y llanamente: un informático que no olvida el lápiz y el papel.

Tampoco pretendo dar más detalles del libro en esta entrada, pues falta un tiempo para su publicación. Sólo deseaba hacer un ping a los suscriptores del newsletter, mencionar que aún sigo vivo, y que todavía no es necesario darse de baja. Aunque usted es libre de hacer lo que quiera, por supuesto, incluso de invitarme un café, pero sobre todo para decirle que pronto regresaré con nuevas cosas.

Au revoir, à la prochaine.

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Richard Hipp es un desarrollador de software estadounidense, conocido principalmente por ser el creador del sistema de gestión de bases de datos relacionales SQLite. Hipp, tiene un PhD en Ciencias de la Computación de la Duke University, comenzó a trabajar en SQLite en 2000 mientras trabajaba en General Dynamics. En 2002, lanzó la primera versión pública de SQLite, que rápidamente ganó popularidad debido a su tamaño pequeño, eficiencia y flexibilidad. Desde entonces, Hipp ha continuado desarrollando y manteniendo SQLite, que se ha convertido en una de las bases de datos más populares y ampliamente utilizadas en el mundo.

Además de SQLite, Hipp ha desarrollado y contribuido a numerosos otros proyectos de software de código abierto; incluyendo CVSTrac, un sistema de seguimiento de bugs y wiki para CVS; un widget HTML para Tcl/Tk; y es creador del sistema de control de versiones Fossil SCM (que es competidor de Git). En reconocimiento a su trabajo en SQLite, Hipp recibió un premio Google O'Reilly Open Source Award en 2005.

Existe un consenso en que tanto SQLite como Fossil SCM son herramientas fáciles de usar; y no sólo eso, también su implementación es simple y elegante. Por tanto, es para mi un gusto haber podido conversar con uno de los grandes desarrolladores de software y contribuidores del ecosistema open source.

¡Espero disfruten de la entrevista!1

Versión traducida

(1) ¿Cuál fue el momento clave que te llevó a crear SQLite, y qué problemas específicos estabas tratando de resolver en ese momento?

Quería una biblioteca de base de datos SQL que pudiera vincular con mi aplicación y que pudiera leer y escribir contenido directamente desde el disco en lugar de enviar mensajes de ida y vuelta a un proceso de servidor separado. No pude encontrar tal biblioteca, así que la escribí yo mismo y la llamé SQLite.

Estaba trabajando como programador freelance. Uno de los problemas que me habían contratado para resolver involucraba un programa para encontrar soluciones aproximadas óptimas a un problema de grafos NP-completo. El “grafo” necesitaba leerse de una base de datos Informix. Funcionó bien la mayoría del tiempo. Pero a veces la base de datos Informix estaría caída y cuando el cliente hacía doble clic en mi aplicación, mi aplicación mostraba un cuadro de diálogo de error que decía “No se puede conectar a la base de datos”. No había nada que mi aplicación pudiera hacer al respecto, ya que el problema era externo a la aplicación. Sin embargo, como era mi aplicación la que entregaba el mensaje de error, yo recibía el ticket de problemas.

Pensé: “Si pudiera leer el contenido de la base de datos directamente desde el disco, entonces mi aplicación no dependería de un servidor externo y este problema no surgiría”.

El cliente no aprobó esta idea, así que no implementé SQLite como parte de ese contrato. Comencé a escribir SQLite unos meses después, en mi propio tiempo. El primer código se verificó el 2000-05-29.

(2) ¿Cómo logró SQLite una adopción tan amplia en la industria, y qué factores crees que contribuyeron a su éxito?

Nunca fue parte de mi plan de carrera ser un “chico de bases de datos”. Puse el código fuente de SQLite en internet como una curiosidad, pensando que otras personas podrían encontrarlo interesante. Nunca anticipé el nivel de interés que provocaría. Nunca pensé que SQLite se convertiría en un negocio.

De hecho, durante los primeros dos o tres años de su existencia, SQLite fue un proyecto de código abierto poco conocido y raramente utilizado. Seguí mejorándolo, poco a poco, porque disfruto escribiendo y trabajando en software. Pero SQLite no se utilizaba ampliamente. Luego, a partir de alrededor de 2003, comencé a recibir llamadas de las principales empresas tecnológicas de la época (AOL, Motorola, Symbian) pidiendo mejoras y soporte para SQLite para que pudieran utilizarlo en sus productos. Me dije a mí mismo: “¿Qué? ¿Puedes realmente ganar dinero con software de código abierto?” SQLite se convirtió en un negocio a tiempo parcial en ese momento. Un par de años más tarde, Android y iPhone salieron al mercado, y en ese punto SQLite se estableció firmemente en el paisaje de software para dispositivos embebidos. Dejé de hacer trabajo de desarrollo freelance y comencé a dedicar toda mi atención a SQLite.

¿Por qué fue exitoso SQLite? No lo sé, pero mi conjetura es que SQLite es simple:

• SQLite proporciona un modelo más simple para una base de datos relacional que los motores de base de datos cliente-servidor como PostgreSQL y MySQL, ya que no hay proceso de servidor que mantener en ejecución. Lee y escribe directamente desde el disco. Si el sistema de archivos funciona, entonces puedes acceder a tus datos. No dependes de un servidor separado.

• La base de datos SQLite es un solo archivo en el disco. Esto simplifica la gestión de múltiples bases de datos. Es trivial hacer una copia de seguridad de la base de datos (simplemente copia el archivo) o transferir la base de datos de una máquina a otra. Es mucho más fácil para los desarrolladores pensar en ella porque hay un solo archivo en el disco que pueden señalar y decir “Esta es la base de datos”.

• La biblioteca SQLite no tiene dependencias externas más allá de la biblioteca C estándar, por lo que es simple de implementar. Además, la biblioteca SQLite es compacta y utiliza poca memoria en comparación con las soluciones de base de datos cliente-servidor.

En resumen, SQLite “simplemente funciona”. Los desarrolladores de aplicaciones no necesitan preocuparse tanto por su solución de almacenamiento de datos y pueden enfocar más esfuerzo mental en resolver problemas para sus clientes.

(3) ¿Cómo surgió Fossil SCM, y qué diferencias de diseño tiene en comparación con Git?

El primer código para SQLite se almacenó en CVS, que era el sistema de control de versiones predominante en esa época. CVS era genial (mejor que otros sistemas de control de versiones contemporáneos y mucho mejor que los sistemas que vinieron antes) pero tenía sus limitaciones. Así que comencé a buscar alternativas.

Me inspiré en Monotone, que había llamado mi atención porque utilizaba una base de datos SQLite como formato de archivo de repositorio. Probablemente habría movido SQLite a Monotone excepto por el hecho de que necesitaba un puerto TCP personalizado y protocolo de comunicación cliente-servidor. Esto fue antes de la disponibilidad generalizada de servidores virtuales privados (VPS) y así que mi sitio web se hacía a través de hosting compartido y necesitaba un sistema donde pudiera ejecutar el lado del servidor como un script CGI. Comencé a experimentar con estas ideas en 2005. Git y Mercurial también habían comenzado en ese momento y los examiné también. Pero, al igual que con Monotone, no veía cómo ejecutarlos como CGI. Al mismo tiempo, también tenía un contrato con el fabricante de aviónica Rockwell Collins y ellos me presentaron DO-178B, que estudié cuidadosamente. No sentí que ni Git ni Mercurial cumplieran con los requisitos de gestión de configuración de software de DO-178B. Al no encontrar un sistema existente que se ajustara a mis necesidades, una vez más me dispuse a escribir mi propio.

Fossil es como Git (y Monotone y Mercurial) en que representa la historia de un proyecto de software como un grafo dirigido acíclico, donde cada confirmación es un nodo. Los nodos se identifican mediante un hash criptográfico y, por lo tanto, son inmutables. Así que el modelo de datos subyacente es conceptualmente el mismo.

Fossil se diferencia de Git de muchas maneras:

1. El formato de los artefactos individuales (“objetos” en la jerga de Git) es completamente diferente.

2. Los repositorios de Fossil se sincronizan sobre HTTP/HTTPS ordinarios. El servidor se puede ejecutar utilizando CGI.

3. El repositorio de Fossil se almacena en una base de datos SQLite (como Monotone), en lugar de como una pila de archivos más el formato de archivo “packfile” personalizado de Git.

4. Fossil es un ejecutable autónomo, lo que lo hace fácil de instalar, actualizar y/o desinstalar.

5. Además de control de versiones, Fossil también admite tickets de problemas distribuidos, wiki y documentación. Y tiene un servicio de chat de desarrolladores integrado.

6. Inspirado en DO-178B, Fossil pone un gran énfasis en mantener un registro de auditoría inmutable y promover la conciencia situacional de los desarrolladores.

Un beneficio no intencionado de escribir Fossil es que también sirve como una plataforma de prueba y “dogfooding” excelente para SQLite. Cuando estoy trabajando en Fossil, tengo que utilizar SQLite de la misma manera que cualquier otro desarrollador. Esto me fuerza a mirar la API de SQLite desde una perspectiva diferente a cuando estoy trabajando en SQLite mismo. Me ayuda a empatizar con las luchas de otros desarrolladores que están tratando de integrar SQLite en sus productos, y a ser más simpático con las solicitudes de mejoras de API. He agregado muchas características útiles en SQLite simplemente porque las necesitaba yo mismo para utilizarlas en Fossil. SQLite es un producto mejor porque lo uso en la implementación de Fossil.

(4) La opinión general entre los desarrolladores de software es que tanto SQLite como Fossil SCM tienen un buen diseño, no sólo en términos de facilidad de uso, sino también de implementación. ¿Cuáles son los principios de diseño de software que crees que son relevantes para hacer buen software?

• (A) La complejidad es tu enemiga. Mantén las cosas lo más simples posible.

• (B) Evita utilizar la primera solución que se te ocurra. Si piensas un poco más en el problema, a menudo encontrarás una aproximación mejor.

• (C) Documenta tu código, especialmente las definiciones de estructuras de datos y variables, con comentarios cuidadosos. Escribe el código de manera que pueda ser leído, entendido y mantenido por otros. Explica las cosas claramente. No, el propósito de esa subrutina que acabas de escribir o esa variable que acabas de declarar no es obvio desde su nombre.

• (D) Diseña para la prueba. No es suficiente escribir software que funcione; también debes escribir software que sea fácil de verificar, que pueda ser fácilmente probado para funcionar.

(5) ¿Qué proyectos o áreas de investigación estás explorando actualmente, y cómo ves el futuro de la tecnología de bases de datos?

Siempre tendremos bases de datos. Como dice el viejo dicho: “Sin datos, o eres afortunado o estás equivocado”. La pregunta debería ser: “¿Cómo serán las bases de datos en el futuro?” Creo que SQL estará aquí para quedarse. Incluso cuando empecé a escribir SQLite, seguía pensando que SQL estaba más relacionado con el soporte de mainframes heredados y que no era más que una complicación innecesaria. Pero he llegado a reconocer que SQL realmente tiene algunas ideas inquebrantables: (1) transacciones, (2) abstracción de datos y (3) un lenguaje declarativo.

Tener transacciones es vital para construir sistemas robustos. Si las máquinas nunca se caen y el poder nunca se corta inesperadamente, entonces tal vez las transacciones no serían tan importantes, pero esas cosas suceden.

Fred Brooks escribió en The Mythical Man-Month que “La representación es la esencia de la programación informática”. Y tenía razón. Es más importante obtener la estructura de datos correcta que obtener el código correcto. La estructura de datos puede persistir durante años y décadas. Resulta que el modelo de datos relacional es una excelente manera de definir las estructuras de datos para la mayoría de los problemas del mundo real.

La característica clave de SQL es que el programador le dice a la máquina “qué” computar, no “cómo” computarlo. Esto es una inversión de la mayoría de los otros lenguajes de programación, donde el programador especifica un algoritmo y el “qué computa esto” se deja como ejercicio para el lector. Con SQL, el programador no necesita pensar en algoritmos, sino que se enfoca en conceptos de alto nivel. Mientras tanto, una inteligencia artificial integrada en el motor de base de datos (el “planificador de consultas”) deduce el mejor algoritmo.

SQL tiene sus defectos, pero en su núcleo es un concepto muy poderoso. Hemos visto múltiples esfuerzos en las últimas décadas para reemplazar SQL con conceptos de gestión de datos más “modernos”. Pero todos esos esfuerzos han fracasado, y la gente sigue volviendo a SQL. Creo que SQL estará aquí en alguna forma u otra (esperanzadamente, pero no necesariamente incluyendo SQLite) durante muchas décadas más.

(6) ¿Cómo ves la industria de desarrollo de software actual con la popularidad de los sistemas de generación de código automático impulsados por inteligencia artificial?

Creo que el potencial de la inteligencia artificial (IA) está sobrevalorado.

La IA es ciertamente útil. Recuerda que hay una IA (llamada “planificador de consultas”) en el corazón de cada motor de base de datos SQL. Estoy seguro de que se encontrarán nuevos usos para la IA y que las tecnologías de IA serán un ahorro de tiempo valioso en los próximos años. Pero soy escéptico sobre las predicciones apocalípticas para una toma de posesión de la IA.

Me recuerda cuando era niño en la década de 1960 y 1970, y los futuristas predijeron que todos tendríamos helicópteros privados en lugar de coches, que pronto tendríamos colonias humanas en la luna, y que toda nuestra ropa sería hecha de fibras vegetales para que pudiéramos usarla una vez y luego tirarla. Me recuerda cuando la gente decía que los reactores de fusión nuclear harían que la electricidad fuera tan barata que no valdría la pena medirla. Nada de esto se ha cumplido, al menos de momento.

Recientemente, los tecnólogos han estado prediciendo que los coches pronto serían completamente autónomos. Parece que la conducción totalmente autónoma está siempre a dos o tres años vista.

Creo que la IA se desarrollará de manera similar. Seguro que habrá algunos resultados útiles. Pero creo que la generación completamente automática de código será difícil de conseguir. La codificación asistida por IA parece un resultado más probable que la generación de código totalmente autónoma.

(7) Si tuvieras la oportunidad de viajar en el tiempo y dar consejos no técnicos a tu yo más joven, ¿qué sería, y por qué lo consideras importante?

Responderé a una pregunta ligeramente diferente: “¿Qué consejo darías a los jóvenes de hoy?” Mi respuesta: “Resuelve más problemas de los que creas”.

Hay dos lados en esta ecuación: los problemas que creas y los problemas que resuelves. Minimiza el primero y maximiza el segundo.

Todo el mundo crea problemas. Consumes comida y agua y aire. Ocupas espacio de vida. Esperas que tu empleador y/o tus clientes te paguen. No puedes evitar crear todos los problemas, pero puedes evitar crear problemas innecesarios. No desperdicies recursos. No seas difícil de llevar. No seas dramático innecesariamente. No hagas un desastre innecesario.

Por otro lado, resuelve tantos problemas como puedas. Comienza con pequeñas cosas: haz tu cama. Recoge la basura y ponla en la papelera. Sé amable con el cajero que te atiende en la tienda. Estas cosas son buenos ejercicios para resolver problemas más grandes. Una vez que seas bueno en las pequeñas cosas, busca problemas más grandes que resolver. Ayuda a tu familia y amigos. Ayuda a tus clientes. Ayuda a la comunidad.

Si puedes resolver más problemas de los que creas, nunca te faltarán empleo, amigos, amor y felicidad.

Suscríbete ahora

Original

(1) What was the pivotal moment that led you to create SQLite, and what specific problems were you trying to solve at that time?

I wanted an SQL database library that I could link with my application and that could read and write content directly from disk instead of sending messages back and forth to a separate server process. I couldn't find such a library, so I wrote my own and called it SQLite.

I was working as a freelance programmer. One of the problem I was hired to solve involved a program to find good approximate solutions to a certain NP-complete graph problem.  The “graph” needed to be read out of an Informix database. That worked great most of the time.  But sometimes the Informix database would be down and then when the client would double-click on my application, my application would show an error dialog box that said “Cannot connect to database”. There is nothing my application could do about this, since the problem was external to the application. Nevertheless, since it was my application that delivered the error message, I got the trouble ticket.

I thought: “If only I could read the database content directly from disk, then my application wouldn't need to depend on an external server and this issue wouldn't arise.”

The customer did not approve of this idea, so I did not implement SQLite as part of that contract. I started writing SQLite a few months later, on my own time.  The first code was checked in on 2000-05-29.

(2) How did SQLite achieve such widespread adoption in the industry, and what factors do you think contributed to its success?

Being a “database guy” was never a part of my career plan. I put the SQLite source code out on the internet as a curiosity, thinking other people might find it interesting. I never anticipated the level of interest that it would provoke. I never thought that SQLite would become a business.

Indeed, for the first two or three years of its existence, SQLite was a scarcely known and seldom used open-source project. I kept improving it, little by little, because I enjoy writing and working on software. But SQLite was not widely deployed.  Then beginning in around 2003, I started getting phone calls from the largest tech companies of that time (AOL, Motorola, Symbian) asking for enhancements to and support for SQLite so they could use in their products. I thought to myself:  “What?  You can actually make money from open-source software?” SQLite became a part-time business at that point. A couple more years passed and Android and iPhone came out, and at that point SQLite became firmly established in the software landscape for embedded devices. I stopped doing freelance development work and began devoting all of my attention to SQLite.

Why was SQLite successful? I don't know, but my guess is because SQLite is simple:

• SQLite provides a simpler model for a relational database than client/server database engines like PostgreSQL and MySQL in that there is no server process to keep running.  It reads and writes directly from the disk. If the filesystem is working then you can have access to your data.  You do not depend on a separate server.

• SQLite database is a single file on disk. This simplifies management of multiple databases. It is trivial to make a backup of the database (just copy the file) or to transfer the database from one machine to another. It is much easier for developers to think about because there is a single file on disk that they can point to and say “This is the database”.

• The SQLite library has no external dependencies beyond the standard C library, so it is simple to deploy. Furthermore the SQLite library is compact and uses little memory compared to client/server database solutions.

In short, SQLite “just works”. Application developers do not need to stress as much about their data storage solution and can focus more mental effort on solving problems for their customers.

(3) How did Fossil SCM emerge, and what design-level differences does it have compared to Git?

The first code for SQLite was stored in CVS which was the predominate version control system of that era. CVS was great (better than other contemporary version control systems, and far better than systems that came before) but it did have its limitations. So, I began looking for alternatives.

I was inspired by Monotone which had come to my attention because it used an SQLite database as its repository file format. I probably would have moved SQLite into Monotone except for the fact that it needed a custom TCP port and protocol for client/server communications. This was before the wide-spread availability of Virtual Private Servers (VPSes) and so my websites were done via shared hosting and I needed a system where I could run the server side as a CGI script.  I started tinkering with these ideas in 2005.  Git and Mercurial had also started up at that time and I looked at them too.  But as with Monotone, I didn't see a way to run them as CGI. At about the same time, I also had a contract with avionics manufacturer Rockwell Collins and they introduced me to DO-178B which I studied closely. I didn't feel like either Git or Mercurial met the software configuration management requirements of DO-178B.  Finding no existing system that met my needs, I once again set out to write my own.

Fossil is like Git (and Monotone and Mercurial) in that it represents the history of a software project as an acyclic directed graph, where each check-in is a node.  Nodes are identified by a cryptographic hash and are thus immutable.  So the underlying data model is conceptually the same.

Fossil differs from Git in many ways: 

1. The format of individual artifacts (“objects” in Git-parlance) is completely different. 

2. Fossil repositories sync over ordinary HTTP/HTTPS.  The server can be run using CGI. 

3. The repository for Fossil is stored in an SQLite database (like Monotone), rather than as a pile-of-files plus the bespoke “packfile” format of Git. 

4. Fossil is a self-contained, standalone executable, making it easy to install, upgrade, and/or uninstall. 

5. In addition to version control, Fossil also supports distributed trouble tickets and wiki and documentation.  And it has a built-in developer chat service. 

6. Inspired by DO-178B, Fossil puts a lot of emphasis on maintaining an immutable audit trail and promoting developer situational awareness.

An unintended benefit of writing Fossil is that it also serves as a great testing and “dogfooding” platform for SQLite. When I'm working on Fossil, I have to use SQLite in the same way that any other developer would. This forces me to look at the SQLite API from a different perspective than when I'm working on SQLite itself. It helps me to empathize with the struggles of other developers who are trying to build SQLite into their products, and to be more sympathetic to requests for API enhancements. I've ended up adding a lot of useful features in SQLite simply because I needed them myself for use in Fossil. SQLite is a better product because I use it in the implementation of Fossil.

(4) A general opinion among software developers is that both SQLite and Fossil SCM have good software design, not only in terms of ease of use but also in terms of implementation. What software design principles do you think are relevant for making good software?

• (A) Complexity is your enemy. Always keep things as simple as possible.

• (B) Avoid using the first solution that comes to mind. If you think about a problem a little longer, often you will come up with a better approach.

• (C) Document your code, and especially data structure and variable definitions, very carefully with comments. Write the code such that it can be read, understood, and maintained by others. Explain things clearly. No, the purpose of that subroutine you just wrote or that variable you just declared is not obvious from its name!

• (D) Design for testability. It is not sufficient to write software that works - you also need to write software that is easily verified, that can be easily proven to work.

(5) What projects or areas of research are you currently exploring, and how do you see the future of database technology?

We will always have databases. As the old saying goes: “Without data, you are either lucky or you are wrong.” The question should be: “What will databases look like in the future?”

I think that SQL is here for the long term. I didn't used to think that way. Even when I first started writing SQLite, I was still of the opinion that SQL was more about mainframe legacy support and was just an unnecessary complication. But I have since come to recognize that SQL really does have some unstoppable ideas:  (1) Transactions, (2) Data abstraction, and (3) A declarative language.

Having transactions is vital to building robust systems. If machines never crashed and the power never went out unexpectedly, then perhaps transactions would not be as important, but those things do happen.

Fred Brooks wrote in “The Mythical Man-Month” that “Representation is the essence of computer programming.” And he was spot on. It is more important to get your data structure right than to get the code right. The code can be replaced, but data structures linger for years and decades. It turns out (and this was a big surprise to me) that the relational data model is great way to define the data structures for most real-world problems.

The key feature of SQL is that the programmer tells the machine “what” to compute, not “how” to compute it. This is an inversion of most other programming language where the programmer specifies an algorithm and the “what does this compute” aspect as left as an exercise to the reader. With SQL, the programmer does not need to think about algorithms, but instead focuses on higher-level concepts. Meanwhile, an AI embedded inside the database engine (the “query planner”) deduces the best algorithm.

SQL has its warts, but at its core it is a very powerful concept. We've seen multiple efforts over the past few decades to replace SQL with newer, more “modern”, data management concepts. But all those efforts have fallen flat, and people keep coming back to SQL. I think SQL will be around in some form or another (hopefully, but not necessarily including SQLite) for many decades to come.

(6) How do you see the current software development industry with the popularity of AI-powered automatic code generation systems?

I think the potential of AI is over-hyped.

AI is certainly useful.  Remember, there is an AI (called the “query planner”) at the heart of every SQL database engine.  I'm sure new uses for AI will be found, and that AI technologies will prove to be an invaluable time saver in coming years. But I'm skeptical of the apocalyptic predictions for an AI take-over.

I remember when I was a kid in the 1960s and 1970s, futurists were predicting that everybody would have private helicopters rather than cars, that we would soon have human colonies on the moon, and that all our clothing would be made from plant fibers such that you wear an outfit once and then toss it away.  I remember people saying that nuclear fusion reactors would make electricity so plentiful that it would be too cheap to meter.  None of this has come to pass, at least not yet.

More recently, technologists have been predicting that cars would soon be fully autonomous. It seems like full autonomous driving is always just two or three years away.

Untold billions of dollars of research has gone into these things, but it turned out the end goal is more difficult than originally estimated. I'm guessing that AI will play out similarly.  Sure, there will be some useful results. But I think that full automatic code generation will prove to be elusive. AI-assisting coding seems a more likely outcome than fully autonomous code generation.

(7) If you had the opportunity to travel back in time and give non-technical advice to your younger self, what would it be, and why do you consider it important?

I'll answer a slightly different question: “What advice do you give to younglings today?” My answer: “Solve more problems than you create.”

There two sides to this inequality: The problems you create and the problems that you solve.  Minimize the first and maximize the second.

Everyone creates problems. You consume food and water and air. You take of living space.  You expect your employer and/or your customers to pay you. You cannot avoid creating all problems, but you can avoid creating unnecessary problems. Don't waste resources. Don't be hard to get along with. Don't pick unnecessary fights. Don't be unnecessarily dramatic. Don't make an unnecessary mess.

On the other side, solve as many problems as you can. Start small: Make up your bed.  Pick up litter and put in in the waste can. Be kind to the clerk who is ringing up your purchase at the market. These things are good practice for bigger problems. Once you get good at the small things, look for larger problems that your family or friends or neighbors or clients or customers are having and devise innovative solutions for solving those problem. Problem solving is an acquired and a perishable skill. Keep practicing and improving.

If you can consistently solve more problems than you create, you will never lack for employment, friends, love, and happiness.

El Programador Extraviado (desde ahora PE) publicó recientemente un libro de programación. Lo autoeditó. Titulado: “Aprender a programar con X”, donde “X” es el nombre del un lenguaje de programación que usó en los ejemplos. Hasta aquí todo bien. Si no fuera porque, repetidamente, como quién ha sido atrapado robando y no puede admitir su delito, dice “Hey, pero es un libro de conceptos, no de un lenguaje de programación”. Aquí da inicio a su extravío. Pues si añade “X” al título, y reclama que su libro no es de “X”. Algo confundido lo vemos, o al menos, no tiene la gentileza de evitarle confusiones a sus lectores.

Me armé de valor: iba a encontrar su libro aunque tuviera que buscar en el último rincón de la deep web (no iba a pagarlo, claro). No lo encontré. La vida me hacía un favor, quizá.

Hasta que lo vi en Amazon. Así que me fui a Kindle, di clic en “leer muestra” del libro. Y mis dudas se despejaron. El extravío era mayor de lo que esperaba. Su prosa era magistral en su pensamiento, parece. Porque yo no lo podía detectar. Estaba tan mal escrito, con tantas faltas de ortografía, que no tuvo ni la molestia de usar ChatGPT para evitarlas. Su explicación de conceptos era difusa. Era un criptógrafo en ciernes. Es decir, ¡era un libro de criptografía sin él saberlo! No obstante, a medida que avanzaba en la lectura ésta decaía. Menos él. Porque aparecía su nombre incluso en los ejemplos de código del libro —no podemos decir que tenga problemas de autoestima—. Una escritura desprolija, al igual que su pelo, que parecía haber ocurrido después del primer fin de semana de recibir su sueldo. En el peor bar de la ciudad, consumido por altas dosis de alcohol. Pero ahí está. Ya es escritor.

La vida es generosa. PE lo sabe. Y quiere aprovechar el vuelo. Sus perfeccionistas feligreses aún no lo han detectado y le dan 5 estrellas en Amazon sólo porque no pueden darle 10. Excepto uno. En Goodreads, un sagaz lector lo atrapó y le dio 1 estrella, y con una reseña que vuelve generosa esta entrada.

PE dice que va a continuar escribiendo —a nuestro pesar—. Pero no es extraño. Los escritores —me incluyo— tendemos a ser porfiados. No nos rendirnos ante la adversidad. La escritura no puede esperar. Escribir es un compromiso inquebrantable.

Así pues, sólo nos queda esperar el nuevo libro de PE; eso sí, recemos, para que esta vez lo escriba sobrio.

Suscríbete ahora

El código encierra un relato secreto. Una historia. Que no es explícita, y pocas veces conocida por su autor. Se descubre con las siguientes preguntas: ¿Podré resolver el problema? ¿He podido entender lo qué me piden? ¿Tengo el conocimiento para resolverlo? Y, quizá, todavía más importante: ¿Tengo el conocimiento para resolverlo bien?

Por otro lado, la primera historia, tiende a tener un autoengaño dentro. Elegimos una tecnología, comenzamos a programar, con la esperanza de hacerlo lo más rápido posible, pues se debe terminar, y en informática, siempre se debe ser ágil. Perdemos. Siempre perdemos cuando vamos lento. Y si nos armamos de valor y decidimos ir lento, alguien de «arriba» ya nos hará entrar en razón, y volvemos a ir rápido. Una historia tan familiar.

Dudar. Criticar. Preguntar. Reflexionar. Son las palabras que tienen el antídoto a la segunda historia. El antídoto a nuestras limitaciones. Éste es un problema epistémico, diría un filósofo de la computación. ¿Cómo sé que sé? El «cielo digital» se despeja con más información; eso sí, con buena información. Los problemas de este tipo se resuelven con información que es tanto veraz como contrastable. Veraz significa quedarnos con lo que se sostiene por la evidencia; y, contrastable, que nosotros podemos verificar esa evidencia. En informática, la credulidad no es buena aliada. Y, me temo, que tampoco ayuda en ninguna área del conocimiento.

Para descubrir la segunda historia debemos pensar en ella como un problema epistémico, que es el problema del conocimiento. Un problema que siempre está ahí. Detrás de todo lo que programamos, independiente del lenguaje de programación. A veces nos damos cuenta de él; otras, simplemente no queremos mirarlo. ¿Por qué preocuparme por lo que no sé solucionar?

A mi lado, mientras escribo en la cafetería Sandwichez de la calle Bruc, una fuerte lluvia cae en Barcelona, algo poco común en el Mediterráneo, sobre todo, a la entrada de mayo. Pero como soy chilote: elijo no preocuparme. Me cruzo de brazo y ya. Recordando el dicho, «un chilote no le teme a la lluvia», pero yo ahora sí le temo. La falta de práctica agota el valor. Además, con la lluvia nada se puede hacer. Uno termina conociendo a su enemigo. Pero esto no tiene nada que ver con la segunda historia.

Con el conocimiento siempre hay algo que hacer.

Suscríbete ahora

A mediados del siglo XX comenzó a estar de moda una corriente filosófica que, a través de la metáfora computador-cerebro, venía a decir que los procesos mentales, entre ellos, la conciencia, son meros procesos computacionales. A esto se le conoció como «teoría computacional de la mente» o llanamente computacionalismo, una teoría funcionalista. Sin embargo, ésta teoría fracasó porque no logró capturar la complejidad del cerebro humano. Entre sus objeciones más famosas se encuentra el experimento mental Habitación china de John Searle, que dice que un computador nunca podrá lograr conciencia porque carece de semántica y un soporte biológico, así, nada más puede manipular símbolos.

Pero, los seguidores de esta teoría aún siguen ahí.

Quizá cabe explicar la conciencia antes. Cuando cada día nos despertamos, ya sea con energía o cansados, o cuando vemos a un amigo después de mucho tiempo, o cuando recibimos una mala noticia, o cuando nos enamoramos, estamos «viviendo» la conciencia. Como diría el filósofo de la mente, Gregory Miller, «la conciencia es experiencia».

Por eso el experimento mental descrito por Robert Nozick de seres humanos que, luego de implantarles un chip bloqueaba cualquier información de la conciencia, los trasformaba en «zombies». Fue popular, pues vino a describir cómo sería un mundo con seres carentes de emociones y de todo tipo de experiencia. Estos podían comer, viajar, conversar, pero eran incapaces de sentir nada, porque no son conscientes. A nadie le gustaría vivir en un mundo así, espero.

De hecho, la conciencia se enlaza con valores éticos. Cuando creemos que un ser vivo no tiene conciencia, nuestro trato suele ser distinto si estamos seguro de que la tiene. ¿Por qué nos parece que matar una hormiga no es lo mismo que matar a un perro? Porque sentimos que el perro tiene conciencia, puede alegrarse y sufrir como nosotros, es decir, tiene experiencia.

Esto se conecta con el antropomorfismo: la tendencia de atribuir características humanas a seres no humanos. Todo en IA está impregnado con antropomorfismo, al igual que el computacionalismo y la idea que el cerebro es un computador. Las metáforas nos permiten reducir la complejidad de las abstracciones para encontrar algo similar a nosotros. Caemos en el antropomorfismo porque no tenemos el conocimiento suficiente para establecer límites claros. Un reciente artículo trata este tema en detalle: «Anthropomorphising machines and computerising minds» .

En fin, quizá todos los avances de la IA actual (modelos generativos) nunca alcancen un tipo de conciencia humana, pues es una mala metáfora; quizá y sólo quizá, alcance otra cosa, algo igualmente sorprendente, pero que tenga otro nombre: una suerte de «conciencia computacional».

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Maarten van Steen es un destacado académico y experto en informática, con una sólida formación en Matemáticas Aplicadas. Obtuvo su Maestría en esta disciplina en 1983 en la Universidad de Twente, donde se destacó por su estudio en optimización combinatoria y teoría de grafos. Posteriormente, en 1988, completó su doctorado en informática en la Universidad de Leiden, centrándose en la modelización de sistemas operativos y realizando contribuciones significativas en esta área. Después de su graduación, Maarten trabajó durante aproximadamente cinco años en investigaciones para TNO antes de regresar al ámbito académico en 1993, donde continuó su carrera en instituciones como la Universidad Erasmus de Rotterdam y la Universidad VU de Ámsterdam. En reconocimiento a sus logros académicos, fue nombrado profesor titular en 2002 y jefe del departamento de Ciencias de la Computación en 2010. En 2015, Maarten se unió a la Universidad de Twente, donde continúa desempeñando un papel destacado en el campo de la informática.

Además, es autor de multiples libros, entre los cuales están:

• Computer and Network Organization (1995).

• Graph Theory and Complex Networks (2010).

• Y su libro más popular: Distributed Systems (2024, cuarta edición, versión 4.02). Este ha sido influyente en el campo de la informática y se ha utilizado como material educativo en todo el mundo.

Una de las cualidades de Maarten es su capacidad de explicar temas complejos de una manera clara, y sin evadir la rigurosidad. Además me gustaría destacar su gentileza para conmigo al aceptar esta entrevista.

¡Espero la disfruten!1

Versión traducida

(1) Eres coautor del libro Distributed Systems, que ahora está en su cuarta edición (2024). ¿Cómo surgió la idea de escribir este libro?

Hace unos años, en 1995, me uní al grupo de Andy Tanenbaum en la Vrije Universiteit de Ámsterdam como profesor asistente. Un año más o menos después, comencé a enseñar sistemas distribuidos utilizando su libro Distributed Operating Systems. Aunque eso funcionó bastante bien, después de un tiempo comencé a notar que los estudiantes tenían dificultades para ver el panorama general. Además, después de unos pocos años, algunos temas estaban quedando obsoletos. Lo más importante es que había demasiado énfasis en los sistemas operativos, mientras que los verdaderos desafíos radican en las cosas que eran independientes de los sistemas operativos. Decidimos escribir un nuevo libro enfocado únicamente en sistemas distribuidos. Para mí, los sistemas distribuidos caen en la categoría de cosas complejas. Como siempre les explicaba a los estudiantes: si cambias algo, es posible que comience a afectar en algún lugar donde no lo esperarías. Hay muchas interdependencias que deben considerarse. Entender esas interdependencias es, para mí, realmente de qué se tratan los sistemas distribuidos. Esa es la razón por la que elegimos tomar diferentes perspectivas: procesos, comunicación, coordinación, etc. El libro ha estado disponible en varias ediciones durante más de 20 años y aún se necesita. Es imposible explicar todo sobre sistemas distribuidos en un solo libro, pero ciertamente como introducción, todavía creo que el libro llena un vacío importante. Hay otros buenos libros ahí fuera, pero algunos de ellos realmente parecen una colección de temas aparentemente elegidos al azar. Eso no es bueno para un libro de texto, en mi opinión.

Una cosa con la que estamos satisfechos es hacer que el libro esté disponible en línea de forma gratuita. Simplemente permite que las personas comiencen con un presupuesto bajo. Junto con un conjunto extenso de diapositivas que cualquier profesor puede modificar según sus propias necesidades, lo que queda es concentrarse principalmente en el contenido. Además, cualquier error se puede corregir fácilmente y poner a disposición al instante. También lo vendemos a través de Amazon a un precio bajo, y con su sistema actual, incluso puedo actualizar las versiones físicas, lo que me permite mantener la copia digital y física sincronizadas. Esta autoedición realmente es útil para que las cosas avancen.

(2) ¿Cuáles consideras que son los desafíos más importantes en los sistemas distribuidos hoy y en el futuro? ¿Hay algún nuevo principio que pueda surgir?

Esa es una difícil. Mi propia investigación siempre se ha concentrado en los problemas de escalabilidad. Diseñar para la escalabilidad no es fácil: parece que tenemos esta tendencia a complicar demasiado las cosas. Desde esta perspectiva, un gran desafío real es mantener las cosas tan simples como sea posible (pero no demasiado simples). Creo firmemente que solo las cosas simples y basadas en principios pueden escalar. Esto también significa que no soy un gran fan de las optimizaciones de rendimiento, o al menos no hasta que se haya implementado el diseño más simple que funcione. Como se dijo, para muchos de nosotros, mantenernos alejados de las optimizaciones y reflexionar sobre cómo podemos simplificar aún más los diseños es un desafío. Puede ser el mayor desafío para aquellos que desarrollan sistemas distribuidos.

Para dar un ejemplo. Hay mucho revuelo sobre la computación edge. La mayor parte de ese revuelo se trata de cómo podemos implementar mejor los sistemas edge. Esto a menudo se trata de optimización. Sin embargo, cuando lo piensas, también podemos preguntarnos qué problema realmente resuelve la computación edge. Muchas personas mencionan la privacidad, la eficiencia energética, el uso del ancho de banda y demás. Sin embargo, yo diría que la computación edge puede contribuir a mejorar estas cosas (aunque la eficiencia energética es discutible). Para mí, el mejor argumento para la computación edge es que la necesitamos cuando es difícil vencer a la Madre Naturaleza, y eso prácticamente solo ocurre cuando hay problemas de latencia. Creo que es justo decir que los problemas de ancho de banda siempre son de naturaleza temporal; lo mismo ocurre con la conectividad (con notables excepciones, como en aplicaciones espaciales). Proteger la privacidad manteniendo las cosas locales no tiene sentido para mí (aunque reconozco que su realización puede ser algo más simple). Entonces, ¿por qué molestarse tanto con la computación edge? Desde la perspectiva de la computación en la nube, introducida ya en 2009, optimizar el edge no parece un tema de alta prioridad. Lo que sí importa, y es un tema difícil, es cruzar los límites administrativos. Y sí, esta es una de las cuestiones de escalabilidad ya mencionadas por Clifford Neuman en la década de 1990.

Una cosa que he estado considerando agregar como principio es el mantenimiento. Los sistemas distribuidos no se apagan (bueno, normalmente hablando). Siempre están en funcionamiento, y mientras lo hacen, las cosas deben actualizarse, reemplazarse, lo que sea. Los componentes también se rompen, y sería conveniente si pudieras predecir dónde sucedería eso. Aún no he desarrollado una imagen razonable para incluir esto en el libro como un principio separado. Pero quizás en la 5ª edición.

En resumen: diseñar para la simplicidad y con ella para la escalabilidad es y sigue siendo, para mí, el mayor desafío. Lo que ayuda a mantenerse en el camino correcto es preguntarnos cuál es el problema que estamos tratando de resolver. Intentemos evitar trabajar en tecnología por el bien de la tecnología, aunque sea tan divertido. En este sentido, puedes entender que no soy un gran fan de las blockchains.

(3) Con la popularidad de la IA y sus modelos generativos, ¿cree que este campo podría influir en la investigación en sistemas distribuidos, creando mecanismos para la adaptabilidad, la privacidad o los algoritmos distribuidos autogenerados?

Bueno, creo que acabas de dar una respuesta positiva a tu propia pregunta. Dicho esto, no me queda claro cuál es el verdadero poder de la IA (generativa), en el sentido de que aún tenemos que ver qué tan confiable es para generar soluciones que funcionen. A veces sospecho que una vez que superemos nuestro propio asombro, notaremos varias fallas profundas que son difíciles de mitigar. La IA sigue siendo IA estrecha: buena para hacer una cosa. A menudo, todavía tenemos que descubrir qué tan robustos son los análisis y las soluciones. Sin embargo, soy optimista, pero no me preguntes todavía cómo se utilizará la IA para los sistemas distribuidos. Como primer paso, veo mucha promesa en el mantenimiento predictivo basado en IA, un tema en el que Ozalp Babaoglu ha estado trabajando, como uno de los primeros, de hecho.

(4) Tienes un video titulado «Dos perspectivas sobre el futuro de las ciencias de la computación» (Two perspectives on the future of computer sciences) donde explicas una perspectiva integrada de la computación con otras áreas del conocimiento. Ahora, con los avances en el campo de la IA, ¿ha cambiado o se ha expandido de alguna manera tu perspectiva sobre el futuro de las ciencias de la computación?

Una cosa que mencioné en ese video fue el cambio del núcleo de las ciencias de la computación desde los temas «tradicionales» de las ciencias de la computación (algoritmos, sistemas, lenguajes) hacia la IA. Ahora preveo que las ciencias de la computación tendrán que mirar mucho más hacia los temas para hacer que las soluciones de IA funcionen. Por ejemplo, sospecho que necesitaremos alternativas para nuestras computadoras de Von Neumann, que actualmente nos permiten solo simular modelos de IA. ¿Qué significaría esto para nuestras prácticas de computación? ¿Para nuestro desarrollo de sistemas?

Volviendo a los problemas de escalabilidad, también creo que tendremos que enfocarnos más en la naturaleza estocástica y probabilística de nuestros sistemas informáticos muy grandes y complejos distribuidos, quizás mucho más a lo largo de los métodos que los físicos intentan capturar las sutilezas del mundo que nos rodea: mediante el modelado y la adopción gradual de esos modelos como la verdad. Sin embargo, un problema real radica en este campo vagamente definido llamado digitalización, mediante el cual virtualmente todo está equipado con componentes y soluciones digitales. Muchos espectadores de ese video han pensado erróneamente que propuse enfocarme mucho más en la aplicación de las ciencias de la computación a otras disciplinas. En cambio, quise decir que nosotros, como científicos de la computación, debemos enfocarnos mucho más en la integración con otras áreas, si solo para prevenir errores causados por personas que no entienden la computación como nosotros.

Para dar un ejemplo, tengo colegas, principalmente de las ciencias sociales, que están trabajando en un gran proyecto nacional sobre la sociedad algorítmica. Este es un tema extremadamente importante que puede dar forma al futuro para muchos de nosotros. Los científicos de la computación deberían estar (y en este ejemplo lo están) a bordo, no para aplicar lo que ya saben, sino para codesarrollar soluciones que sabemos que pueden funcionar, tanto técnicamente como socialmente. Esas soluciones a menudo aún no se conocen, ya que pueden necesitar cumplir con estrictas reglas de protección de la privacidad. Al mismo tiempo, la tecnología de las ciencias de la computación también puede ayudar a comprender lo que significa realmente proteger la privacidad (en particular, es mucho más que solo protección de datos).

Como otro ejemplo, considera el Reglamento General de Protección de Datos de la Unión Europea (RGPD). Algo que ha sido establecido por expertos, pero sospecho que no por aquellos profundamente familiarizados con las Ciencias de la Computación. Si realmente podemos hacer cumplir el RGPD ya es un punto de discusión, pero ¿qué pasa con el análisis y la aplicación automáticos del RGPD? Esto es algo para los sistemas de ley computacional. Sería interesante para mí ver qué sucedería si cocreáramos el RGPD junto con el requisito de que debe ser completamente compatible con un sistema de ley computacional. No puedo imaginar que podríamos capturar todo (lo cual es una pregunta de investigación), pero nos permitiría separar las partes «fáciles» (aquellas que se pueden automatizar) de otras partes (y típicamente aquellas que requieren mucho pensamiento). El acto de IA europeo también podría haberse manejado a lo largo de estas líneas (y habríamos descubierto interesantes contradicciones integradas).

Estos son solo dos ejemplos, pero otros fácilmente vienen a la mente que ilustran que las ciencias de la computación no pueden y nunca serán una disciplina aislada.

Así que la respuesta simple a tu pregunta es «no». Sin embargo, la urgencia de un enfoque integrado ha aumentado en mi opinión.

(5) Has escrito varios libros y enseñado varios cursos. ¿Cuál es tu enfoque para hacer que los temas complejos sean accesibles y comprensibles?

La respuesta simple es preguntarme continuamente si me estoy enfocando lo suficiente en los aspectos esenciales. Si me pierdo en tecnicismos, probablemente signifique que no entendí bien el tema para explicarlo claramente a otros. Como regla general, tomo el enfoque de que, si no entiendo lo que alguien me está diciendo, es probable que no sea mi culpa. Si comprendes bien un problema y su solución, las explicaciones se vuelven más simples. Hay numerosos ejemplos en mis libros y cursos en los que queda claro que mi comprensión del tema ha obstaculizado una explicación clara.

Además de este enfoque, y en línea con lo que mencioné antes, esforzarse por la simplicidad siempre debe ser lo primero. Realmente creo que la mayoría de nosotros, incluido yo mismo, estamos tentados demasiado rápido a optar por soluciones que pueden solucionar un problema, pero no nos hemos preguntado suficientemente si hemos entendido lo suficiente el problema, o incluso las fuentes de ese problema. Demasiadas veces he notado que también mis propias soluciones podrían simplificarse increíblemente solo dando un paso atrás. Un ejemplo reciente es el código que escribí para el libro de Sistemas Distribuidos, que utiliza el sistema Redis. Admito que no entendí completamente la semántica subyacente para la 3ra edición, lo que llevó a un código funcional, pero difícil de comprender por completo. Para la 4ta edición, creo que el código es mucho más simple y fácil de entender. Ahora también tengo más confianza en que es correcto. Por cierto, me he mantenido alejado de las optimizaciones.

(6) ¿Qué consejo le darías a una persona joven interesada en ingresar a un campo tan vasto como los sistemas distribuidos?

Simplemente comienza. Asegúrate de entender la programación de redes, cómo manejar bloqueos y cosas así, y luego elige un problema. En este sentido, recomendaría el libro de Martin Kleppmann para obtener experiencia práctica. Es una excelente lectura y una vez que tengas una sensación intuitiva de cómo funcionan las cosas en la práctica, se vuelve más fácil entender y apreciar también el material más teórico en nuestro libro.

También ayuda: construir cosas. Construir puede ser programar, pero también instalar software existente y unir cosas. Por ejemplo, todo el sitio web de distributed-systems.net se ejecuta en mis propios servidores, incluidas copias de seguridad calientes, copias de seguridad incrementales, réplicas independientes, servidores de correo, todo. En cierto punto, incluso tenía mi propio servidor DNS de segundo nivel en funcionamiento, pero es más una molestia administrativa que otra cosa. Todavía planeo tener un intercambio (semi-) automatizado simple a un servidor ubicado en otra parte, pero eso requiere una excelente conexión a Internet (y tiempo para una configuración adecuada). El punto es: los sistemas distribuidos se tratan mucho de hacer que las cosas se hagan de manera práctica, así que necesitas hacer más que solo estudiar material de libros y artículos. Una vez que tienes un sistema básico en su lugar, probar y agregar cosas se vuelve mucho más fácil. Ayuda si realmente dependes de que ese sistema funcione: te mantiene alerta.

(7) Si tuvieras la oportunidad de viajar en el tiempo y darle consejos no técnicos o no relacionados con la escritura a tu yo más joven, ¿qué sería, y por qué lo consideras importante?

En este caso, solo puedo citar al Dr. Seuss: «Sé quien eres y di lo que sientes, porque aquellos que les importa no importan y aquellos que importan no les importa». Esto también significa, para mí, que es importante escuchar lo que tienen que decir los demás, independientemente del tema. La diversidad al máximo generalmente será beneficiosa para todos, sin importar lo difícil que pueda ser a veces soportarlo. Las personas con ideas similares no te llevarán tan lejos como la gente con diferentes ideas, estilos y demás.

Suscríbete ahora

Original

(1) You are a co-author of the book “Distributed Systems,” which is now in its fourth edition (2023). How did the idea to write this book come about?

Back in 1995, I joined Andy Tanenbaum's group at Vrije Universiteit in Amsterdam as an assistant professor. A year later or so, I started teaching distributed systems using his book "Distributed Operating Systems." Although that worked quite well, after a while I began to notice that students had trouble getting the bigger picture. Also, already after a few years, some topics were becoming outdated. The most important was that there was too much emphasis on operating systems, whereas the real challenges lie in the stuff that was independent of operating systems. We decided to write a new book focusing entirely on distributed systems. Distributed systems for me fall into the category of complex stuff. As I always explained to students: if you change something, it may easily start hurting some place where you wouldn't expect it. There are so many interdependencies that need to be considered. Understanding those interdependencies is, to me, really what distributed systems are all about. That's the reason why we chose to take different perspectives: processes, communication, coordination, etc. The book has now been around in various editions for over 20 years and still in need. It's impossible to explain everything about distributed systems in a single book, but certainly as an introduction, I still believe the book fills an important gap. There are other good books out there, but some of them really appear to me as a collection of seemingly randomly chosen topics. That's not good for a textbook, in my opinion. 

One thing we're pleased with is making the book available online for free. It simply allows folks to get started on a low budget. Along with an extensive set of slides that any lecturer can modify to their own needs, what remains is to mainly concentrate on the content. Moreover, any mistakes can be easily corrected and made available instantly. We also sell it through Amazon for a low price, and with their current system, I can even update the hard-copy versions, allowing me to keep the digital and physical copy in sync. This self-publishing is really helpful in getting things going.

(2) What do you consider to be the most significant challenges in distributed systems today and in the future? Are there any new principles that could emerge?

That's a tough one. My own research has always concentrated on scalability problems. Designing for scalability is not easy: we seem to have this tendency to make things too complicated. From this perspective, a real big challenge is to keep things as simple as possible (but not too simple). I firmly believe that only principled, simple things can scale. This also means that I'm not a big fan of optimizations for performance, or at least not until the simplest working design has been implemented. As said, for many of us, staying away from optimizations and pondering on how we can further simplify designs is a challenge. It may be the biggest challenge for those developing distributed systems.

To give one example. There is a lot of buzz about edge computing. Most of that buzz is about how we can best deploy edge systems. This is often all about optimization. Yet, when you think about it, we can also ask ourselves which problem does edge computing really solve? Many folks mention privacy, energy efficiency, bandwidth usage, and so forth. However, I would say that edge computing may contribute to improving these things (although energy efficiency is disputable). To me, the best argument for edge computing is that we need it when beating Mother Nature is tough, and that's practically only when there are latency issues. I think it's fair to say that bandwidth issues are always of a temporary nature; the same holds for connectivity (with notable exceptions, such as in space applications). Protecting privacy by keeping things local doesn't make sense to me (although I acknowledge that its realization may be somewhat simpler). So, why bother so much about edge computing? From the perspective of sky computing, as introduced already in 2009, optimizing the edge doesn't seem like a high-priority topic. What does matter, and a subject that is tough, is crossing administrative boundaries. And yes, this is one of the scalability issues already mentioned by Clifford Neuman back in the 1990s.

One thing that I have been considering to add as a principle is maintenance. Distributed systems are not shut down (well, normally speaking). They are always up and running, and while doing so, things need to be upgraded, replaced, what have you. Components also break, and it would be convenient if you could predict where that would happen. I haven't developed a reasonable picture yet to bring this into the book as a separate principle. But perhaps in the 5th edition.

In summary: designing for simplicity and with it for scalability is and remains, to me, the greatest challenge. What helps in keeping on track is asking ourselves what the problem is that we're trying to solve. Let's try to avoid working on technology for the sake of technology, even it's so fun. In this respect, you may understand that I'm not a big fan of blockchains.

(3) With the popularity of AI and its generative models, do you think this field could influence research in distributed systems, creating mechanisms for adaptability, privacy, or self-generated distributed algorithms?

Well, I think you just gave a positive answer to your own question. Having said that, it is unclear to me what the real power of (generative) AI actually is, in the sense that we yet have to see how reliable it is for generating solutions that work. I sometimes suspect that once we are over our own amazement, we'll notice various deep flaws that are difficult to mitigate. AI is still narrow AI: good at doing one thing. Often, we still need to find out how robust the analyses and solutions are. Yet, I am optimistic, but don't ask me yet how AI will be put to good use for distributed systems. As a first step, I do see a lot of promise for AI-based predictive maintenance, a topic that Ozalp Babaoglu has been working on, as one of the first, actually.

(4) You have a video titled “Two perspectives on the future of computer sciences” where you explain an integrated perspective of computing with other areas of knowledge. Now, with advancements in the field of AI, has your perspective on the future of computer sciences changed or expanded in any way?

One thing that I mentioned in that video was the shift of the core of computer science from "traditional" computer science topics (algorithms, systems, languages), to AI. I now foresee that computer sciences will need to look much more into topics for making AI solutions work. For example, I suspect we'll need alternatives for our Von Neumann computers, which currently allow us to only simulate AI models. What would this mean for our computing practices? For our development of systems? 

Coming back to scalability problems, I also think we'll have to focus more on the stochastic and probabilistic nature of our very large and complex distributed computer systems, perhaps much more along the ways that physicists try to capture the intricacies of the world around us: by modeling and gradually adopting those models as being the truth. Yet, a real problem lies in this vaguely defined field called digitalization, by which virtually everything is equipped with digital components and solutions. Many viewers of that video have wrongly thought that I proposed to focus much more on the application of computer science to other disciplines. Instead, I meant that we, as computer scientists, need to focus much more on the integration with other fields, if only to prevent mistakes caused by people who do not understand computing as we do.

To give an example, I have colleagues, primarily coming from the social sciences, who are working on a large national project about the algorithmic society. This is an extremely important subject that may well shape the future for many of us. Computer scientists should be (and in this example are) on board, not to apply what they already know, but to co-develop solutions that we know can work, technically as well socially. Those solutions are often not yet known, as they may need to meet tough privacy protection rules. At the same time, computer science technology may also help to understand what protecting privacy really means (in particular, it's much more than just data protection). 

As another example, consider the European General Data Protection Regulation (GDPR). Something that has been set up by experts, but I suspect not ones deeply familiar with Computer Science. Whether we can actually enforce GDPR is already a point of discussion, but what about automatically analyzing and enforcing GDPR? This is something for computational law systems. To me, it would be interesting to see what would happen if we would co-create the GDPR along with the requirement that it should be fully supported by a computational law system. I can't imagine we would be able to capture everything (which is a research question), yet it would allow us to separate the "easy" parts (those that can be automated) from other parts (and typically those that require a lot of thinking). The European AI act could also have been handled along these lines (and we would have discovered interesting built-in contradictions).

These are just two examples, but others easily come to mind that illustrate that computer science cannot and never will be an isolated discipline.

So, the simple answer to your question is "no." The urgency for an integrated approach has, however, gone up in my opinion.

(5) You've written several books and taught various courses. What is your approach to making complex subjects accessible and understandable?

The simple answer is continuously asking myself if I'm focusing enough on the essentials. If I get lost in technicalities, that probably means I didn't understand the subject well enough to clearly explain it to others. As a general rule, I take the approach that if I don't understand what someone is telling me, it's most likely not my fault. If you understand a problem and its solution well, explanations become simpler. There are numerous examples from my books and courses where it is clear that my understanding of the topic has been hindering a clear explanation.  

Besides this focus, and in line with what I mentioned before, striving for simplicity should always come first. I really think that most of us, including myself, are tempted too quickly to go for solutions that may fix a problem, but have not sufficiently asked ourselves whether we have understood the problem enough, or even the source(s) of that problem. Too often have I noticed that also my own solutions could be incredibly simplified by just taking a step back. A recent example is the code I wrote for the Distributed Systems book, which makes use of the Redis system. Admittedly, I did not fully understand the underlying semantics for the 3rd edition, which led to working code, yet difficult to fully comprehend. For the 4th edition, I believe the code is much simpler and easier to understand. I'm now also more confident that it is correct. By the way, I have consistently stayed away from optimizations.

(6) What advice would you give to a young person interested in entering such a vast field as distributed systems?

Just start. Make sure you understand network programming, how to handle locks and such, and then pick a problem. In this sense, I would advise Martin Kleppmann's book to get hands-on experience. It's a great read and once you have a gut feeling how things work in practice, it becomes easier to understand and appreciate also the more theoretical material in our book. 

What also helps: build things. Building can be programming, but also installing existing software and tying things together. For example, the entire website for distributed-systems.net is running on my own servers, including hot backups, incremental backups, independent replicas, mail servers, the whole thing. At a certain point, I even had my own second-level DNS server running, but that is more of an administrative hassle than anything else. I still plan to have a simple (semi-) automated handoff to a server located elsewhere, but that requires an excellent Internet connection (and time for proper configuration). The point is: distributed systems are much about getting things practically done, so you need to do more than just study material from books and papers. Once you have a basic system in place, testing and adding stuff becomes much easier. It helps if you actually depend on that system to work: it keeps your alert.

(7) If you had the opportunity to travel back in time and give non-technical or non-writing related advice to your younger self, what would it be, and why do you consider it important?

In this case, I can only quote Dr. Seuss: "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." This also means, to me, that it is important to get to hear what others have to say, regardless of the subject. Diversity to the max will generally be beneficial to everyone, no matter how difficult it can sometimes be to endure. Like-minded people will not get you as far as the folks with different ideas, styles, and what have you.

Y es que, en la aventura de escribir, uno más de una vez se cruza con canallas. Personajes disfrazados de buenas intenciones. Carentes de voluntad. Y guiados por su deseo de escuchar «he abandonado el proyecto del libro» ven frustrados sus esfuerzos, mientras, ellos, se envuelven de miradas rencorosas. A algunos conozco, a mi pesar son pocos, sino escribiría con más frecuencia y motivación.

Aún no tengo claro en que libro comenzaré con Desagradecimientos. Solo sé que ocurrirá, seguro. Estoy esperando la oportunidad, como un lobo agazapado esperando a su presa. Y es que ésta sensación amenazante refuerza una negatividad, que tiene algo esperanzador. Quizá sea uno de los que, como yo, a veces prefiere escuchar música triste para subirse el animo. Donde suenan los violines, pianos, violonchelos, contrabajos, incluso trompetas… cualquier instrumento sirve para sentirse mejor. O leer algún existencialista para hacer las paces con la vida. Lo real, curiosamente, algunas veces está en la desolación.

Hasta aquí estas amables digresiones.

Como pequeño detalle adelanto uno de mis futuros desagradecimientos:

Tan Motivador.

Suscríbete ahora

Hace unos días regresé a Barcelona desde Chile. Casi un mes fuera es suficiente para descargar energía, porque para mí viajar significa mantenerse más activo que de costumbre. El viaje como búsqueda, no como contemplación, en eso creo. Siendo sincero, encontrar tranquilidad al regresar a casa es reconfortante. Veo a mi alrededor y no hay nada, solo silencio, y una tenue luz solar me golpea mientras el calefactor hace su único trabajo: el de evitar que tenga frio. Así recargo energías.

El día de la presentación de mi libro (Principios de Programación), en Castro, en la biblioteca pública, resultó bien. Fue bastante gente y más de lo que esperaba para ser un libro técnico, además, distintas generaciones se reunieron. Girar la cabeza y ver que por un lado había jóvenes, y por otro, mayores, me sorprendió. Nunca se espera eso. De hecho, nunca se espera nada. Porque escribir esperando alguna recompensa es tan tonto como esperar que tu código jamás tendrá errores. Más tarde llegaron las solicitudes de fotos conmigo, me embriagué de fama durante diez, quizá veinte, o incluso treinta segundos; una suerte de rock-star-chilote, aunque sin escenario ni instrumentos. (A mi pesar no sé tocar ningún instrumento.) Sin más, uno se da cuenta de que la gente tiende a exagerar en sus halagos. O tal vez se deba al contexto: salir de una isla parece requerir más esfuerzo (o suerte), especialmente si tu familia no es ni fue de plata. De todas formas, quiero creer que mis mínimos logros se deben a pura voluntad.

No tengo mucho que añadir sobre mi viaje a Chile, cuando las cosas salen bien, no hay nada que decir. Guardo silencio y sonrío. Porque los recuerdos son intransferibles, dicen. Nada más he añadido gratas vivencias que las disfrutaré en el futuro. Una posibilidad de felicidad futura. Un intento de resistir a los embates del olvido de las experiencias.

En algunas ocasiones ser vil conlleva el silencio.

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Valeria de Paiva1 es una matemática e investigadora científica en inteligencia artificial de origen brasileño radicada en UK, interesada en procesamiento del lenguaje natural, inferencia lógica y todo tipo de semántica. Además, su áreas de investigación incluyen la teoría de las categorías, la semántica del lenguaje natural y la programación funcional. En 1988, completó su doctorado bajo la dirección de Martin Hyland, en la Universidad de Cambridge. Su tesis introdujo la Dialéctica de espacios, una manera categórica de construir modelos de lógica lineal.

Además de su labor investigativa, se ha preocupado en el rol de las mujeres en sus vidas profesionales. Ayudando a mantener el sitio web Women in Logic, un grupo de Facebook Women in Logic, un blog Women in Logic y ahora un sitio web de charlas Women in Logic seleccionadas. Es parte del Comité Directivo de Women in Logic. También colabora con el programa de becas ACM-W Scholarship.

Algo curioso de De Paiva es su gran capacidad para adaptar temas de las matemáticas puras al entorno empresarial. Pues ha trabajado en Samsung, como investigadora principal; en Nuance Communications y Rearden Commerce, como investigadora senior; y actualmente se desempeña como investigadora principal en Topos Institute.

¡Espero disfruten de la entrevista !2

Versión traducida

(1) Un aspecto de tu trayectoria que despierta mi curiosidad es la combinación única de tus experiencias tanto en la industria como en la academia, especialmente teniendo en cuenta tu enfoque académico en matemáticas puras. A primera vista, podría parecer desafiante integrar temas abstractos como la teoría de categorías en un entorno empresarial. ¿Podrías detallar los desafíos más significativos que enfrentaste en la industria al aplicar estos conceptos abstractos?

Claro. En efecto, es una lucha cuesta arriba intentar «vender» conceptos abstractos a la industria, especialmente en un entorno donde los resultados deben verse en trimestres, en lugar de años. Pero una estrategia antigua es resolver problemas utilizando matemáticas sofisticadas y explicar las soluciones con poca sofisticación. Pero para eso, necesitas gerentes de contratación que crean en el poder de las matemáticas. Algunos lo hacen, muchos otros no.

Creo que he tenido suerte.

(2) Continuando nuestra discusión sobre teorías de categorías, el desarrollo de software contemporáneo busca cada vez más las abstracciones más adecuadas para abordar problemas complejos. ¿Cómo visualizas el futuro de la teoría de categorías en el ámbito del desarrollo de software? ¿Crees que puede ofrecer beneficios prácticos claros, como la reducción de errores o la gestión de la complejidad inherente de los sistemas de software?

Creo en el poder de la teoría de categorías para simplificar y organizar conceptos. Creo que la teoría de categorías ayuda a ver el desorden y a entender cómo eliminarlo, por lo que creo que debería ser útil para la ingeniería de software, pero también en general para toda la ciencia de la computación teórica. En particular, creo que el principio proposición-como-tipos conduce, como dice su nombre, a una programación basada en principios, que es menos propensa a errores y más eficiente.

Por otro lado, también creo que los «hacks» que son demasiado buenos para perderse son teóricamente importantes, simplemente no los hemos convertido en teoría todavía. Después de todo, la ciencia de la computación es para las matemáticas en el siglo XXI lo que la física fue en el siglo XX: un maravilloso patio de recreo lleno de problemas grandes y pequeños por resolver.

(3) Con tu participación en diversos proyectos de investigación, ¿podrías compartir cuál encontraste más intelectualmente exigente y qué conocimientos o lecciones valiosas obtuviste de él?

Oohhh, esto es difícil. Encuentro la mayoría de mis proyectos exigentes, tanto que realmente no puedo dejar esos proyectos en paz. Siento que quiero seguir trabajando en todos ellos. Y, por supuesto, no hay tiempo suficiente. Tuve esta conversación una vez con mi amigo Alan Jeffrey, a quien le pregunté sobre en qué estaba pensando en uno de sus proyectos antiguos, y él dijo que ya no pensaba en eso, estaba hecho, cerrado. Solo entonces me di cuenta de que no todos son como yo, siempre queriendo volver a las cosas que hice, mejorarlas, completarlas, conectarlas con otras cosas interesantes.

Quiero decir, me gustan los problemas difíciles y no creo que los resuelvas completamente, haces un intento, resuelves el problema principal que ves, pero siempre puedes volver y mejorarlo. Ciertamente tengo varias situaciones en las que creo que fracasé miserablemente en obtener una comprensión real, la búsqueda es una de estas. Trabajé para Cuil, un inicio de motor de búsqueda en 2008-2010, y aprendí mucho, pero no he podido utilizar mis herramientas categóricas. Así que siempre está ahí, un picor sin rascar, que tal vez si hubiera intentado más fuerte, podría haber logrado algo.

(4) Dado tu trabajo en semántica del lenguaje natural, ¿cómo percibes la extensa investigación en torno a los Modelos de Lenguaje Grandes (LLMs)? ¿Crees que los métodos lógicos y simbólicos pueden resurgir en un panorama dominado en gran medida por técnicas probabilísticas, como el aprendizaje profundo?

Bueno, es asombroso lo que pueden hacer. Estoy impresionada, como todos los demás. Pero, por supuesto, también me preocupa mucho los varios hechos negativos que los rodean. El hecho de que no podemos explicar cómo funcionan, que no podemos garantizar la reproducibilidad, que no podemos confiar en los resultados de la IA generativa. Entonces, sí, creo que necesitamos métodos neurales-simbólicos que nos brinden tanto las increíbles capacidades como la robustez del aprendizaje profundo, pero que también nos proporcionen la explicabilidad lógica y la garantía de verdad que conlleva.

(5) Has mostrado una gran preocupación por el papel de las mujeres en sus vidas profesionales, lo que se refleja en tu trabajo en Women in Logic. ¿Cómo ves la situación actual con respecto a estos problemas y qué necesita mejorarse?

Vaya, otra muy difícil. Creo que la situación no está mejorando tan rápido como debería. De todos los grandes problemas sociales, este debería haber sido más fácil. Me molesta enormemente ver que no parece que hagamos un progreso real, que el patriarcado, que debería ser solo objeto de burla, está vivo y fuerte, y la gente no ve el absurdo nivel de desigualdad entre los géneros en nuestra vida diaria.

Seguimos luchando, pero a veces me desespero cuando veo a adultos altamente inteligentes que no logran comparar situaciones de manera justa. Me desespera cuando las personas muestran no solo sexismo, sino especialmente racismo en sus formas sistémicas y variadas. También me desespero cuando veo a personas librando una guerra contra las personas pobres en lugar de luchar contra la pobreza misma. Me vuelve loco el mantra que veo que iguala tener dinero con ser una buena persona y ser pobre con no tener valor.

(6) Tu variada gama de intereses de investigación, que abarca múltiples áreas, es algo inusual para los investigadores. ¿Qué consejo ofrecerías a las personas que comparten una multitud de intereses y aspiran a explorar diversos campos de investigación mientras posiblemente dudan en salir de sus zonas de confort?

Bueno, creo que no soy un buen modelo a seguir. Creo que algunas personas son más organizadas y pueden tener muchos intereses de investigación diferentes y mantenerlos en paralelo. No soy tan organizada, así que perdí y sigo perdiendo muchas oportunidades para tener un impacto mayor. Creo que las personas deberían leer «You and Your Research» de Hamming.

Ojalá lo hubiera leído cuando estaba empezando. Algunas partes tratan sobre tener el «coraje de tus convicciones», y yo podría haberlo usado en algún momento. Pero todo es interesante. Y, por supuesto, no queremos más presumidos que saben todo en Academia, pero el punto es trazar un curso intermedio, creyendo en tus ideas lo suficiente como para darles la oportunidad de tener éxito.

(7) Si tuvieras la oportunidad de viajar en el tiempo y proporcionar orientación no técnica a tu yo más joven, ¿qué consejo darías y por qué lo consideras importante?

¡Bien! ¡Parece que ya respondí esto en el número 6! Pero permíteme reiterar que creo que la curiosidad es fundamental y divertirse con tu investigación también lo es. Si puedes combinar eso con organización y planificación táctica y estratégica, te irá mucho mejor. Pero la planificación debe estar al servicio de divertirse, no al revés. Porque Hamming tiene razón, la investigación es divertida, pero la investigación impactante es lo real, la máxima diversión.

Nada mejor que detenerte a la mitad de un cálculo o de la construcción de un argumento y pensar para ti mismo: ¡oh chico, funciona! (por supuesto, muchas veces no funciona. Es solo tu mente corriendo contra sí misma y haciendo saltos no permitidos, pero está bien. Fue muy divertido y es tu trabajo, y mañana llenarás los agujeros y funcionará y será divertido de nuevo).

Suscríbase ahora

Original

(1) One aspect of your background that piques my curiosity is the unique blend of your experiences in both industry and academia, especially considering your academic focus on pure mathematics. At first glance, it might seem challenging to integrate abstract topics like category theory into a business environment. Could you elaborate on the most significant challenges you encountered in industry while applying such abstract concepts?

Sure. it's indeed an uphill struggle to try to "sell" abstract concepts to industry, especially one where results have to be seen in quarters, instead of years. But an old age strategy is to solve problems using sophisticated mathematics, and explain the solutions with little of that sophistication. but for that, you have to have hiring managers that believe in the power of mathematics. some do, many more do not.

I think I have been lucky.

(2) Continuing our discussion on category theories, contemporary software development is increasingly seeking the most suitable abstractions to tackle complex problems. How do you envision the future of category theory in the realm of software development?

Do you believe it can offer clear practical benefits, such as bug reduction or managing the inherent complexity of software systems? I believe in the power of CT to simplify and organize concepts. I think CT does help with seeing clutter and seeing how to remove it, so I reckon it ought to useful for software engineering, but also more generally for all theoretical computer science. In particular, I think that the proposition-as-types principle leads, the name says it, to principled programming, which is less buggy and more efficient.

On the other hand, I also believe that the "hacks" that are too good to miss, are actually theoretically important, it's just that we haven't made them into theory, yet. after all, CS is for mathematics in the 21st century what physics was in the 20th century: a wonderful playground full of big and small problems to solve.

(3) With your involvement in various research projects, could you share which project you found to be the most intellectually demanding, and what valuable insights or lessons did you gain from it?

Oohhh, this is hard. I find most of my projects demanding, so much so that I actually cannot leave those projects alone. I feel like carrying on working on them all. and of course there isn't enough time. I had this conversation once with my friend Alan Jeffrey, who I asked about what he was thinking about on one of his old projects and he said he didn't think about it anymore, it was done, closed. only then I realized not everyone is like me, always wanting to go back to the things I did, to improve them, to complete them, to connect them to other interesting things.

I mean, I like hard problems and I don't think you completely solve these problems, you take a pass, you solve the main issue you see, but you can always go back and make it better. I certainly have several situations where I think I failed miserably to get some real understanding, search is one of these. I worked for Cuil, a search engine start-up in 2008-2010 and I learned lots, but I haven't been able to use my categorical tools. so it's always there, an itch unscratched, that maybe if I had tried harder I could've gotten some purchase.

(4) Given your work in natural language semantics, how do you perceive the extensive research around Large Language Models (LLMs)? Do you believe that logical and symbolic methods can make a resurgence in a landscape largely dominated by probabilistic techniques, such as Deep Learning?

Well, it's quite fantastic what they can do. I am amazed, like everyone else. but of course, I'm also very concerned by the several bad facts surrounding them. the fact that we cannot explain how they work, that we cannot guarantee reproducibility, that we cannot trust the results of generative AI. so yes, I believe we need neural-symbolic methods that can give us both deep-learning's amazing capabilities and robustness, but also provide us with the logical explainability, and the truth assurance that it entails.

(5) You have shown a great concern for the role of women in their professional lives, which is reflected in your work in Women in Logic. How do you see the current situation regarding these issues and what needs to be improved?

Oh boy, another very hard one. I think the situation is not improving as fast as it should be. of all the big society problems, this ought to have been an easier one. it annoys me no end to see that we don't seem to make real progress, that the patriarchy, which ought to be just an object of ridicule, is instead, very alive and powerful, and people don't see the absurd level of inequality between the genders in our daily lives.

We keep the fight on, but sometimes I do despair, when I see highly intelligent adults failing to compare situations fairly. I despair when people display not only sexism, but especially racism in its systemic and myriad of forms. I also despair when I see people waging a war against poor people, instead of waging it against poverty itself: it drives me nuts the mantra I see equating having money as being a good person, being poor as being worthless.

(6) Your diverse array of research interests, which span across multiple areas, is somewhat unusual for researchers. What advice would you offer to individuals who share a multitude of interests and aspire to explore diverse research fields while possibly hesitating to step out of their comfort zones?

Well, I think I am not such a good role model. I think some people are more organized and they can have these many different research interests and keep them going in parallel. I'm not that organized, so I missed and continue to miss many opportunities to have more impact. I think people should read Hamming's "You and Your Research".

I wish I had read it when I was starting. Some of it is about having the 'courage of your convictions' and I could've done with that some way back. But all of it is interesting. And of course we don't want any more arrogant know-it-alls than we have already in Academia, but the point is to chart a middle course, believing on your ideas well enough to give them a chance to succeed.

(7) If you had the opportunity to travel back in time and provide non-technical guidance to your younger self, what advice would you give, and why do you consider it important?

Nice, it looks like I answered it in number 6! but let me reiterate that I think curiosity is fundamental and having fun with your research is too! if you can pair that with organization, and both tactical and strategical planning you'll do much better. but the planning should be in the service of having fun, not the other way round. because Hamming is right, research is fun, but impactful research is the real deal, the utmost fun.

Nothing better than stopping in the middle of a calculation or of the construction of an argument and thinking to yourself, oh boy, it works! (of course, many times, it doesn't. it's just your mind racing against itself and making non-allowed jumps, but this is alright. it was great fun and it's your job and tomorrow you'll fill up the holes and it will work and be fun again.)

Suscríbase ahora

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Chris Lattner nació el 30 de junio de 1978 en San José, California, Estados Unidos. Se graduó en la Universidad de Portland con una licenciatura en Informática y Matemáticas. Posteriormente, completó su maestría y doctorado en Ciencias de la Computación en la Universidad de Illinois en Urbana-Champaign.

Lattner es un extraordinario ingeniero de software, y sus creaciones han tenido un impacto fundamental en el ecosistema de la programación y el desarrollo de lenguajes de programación. Es ampliamente reconocido por su contribución al desarrollo de LLVM (Low Level Virtual Machine), un conjunto de tecnologías de compilación que se ha convertido en un estándar de la industria para la compilación de código abierto. Fue el creador original de LLVM y también contribuyó al diseño de su lenguaje de programación, LLVM IR (Intermediate Representation).

Además de su trabajo en LLVM, Lattner es conocido por su participación en el diseño y desarrollo de otros proyectos influyentes. Fue uno de los desarrolladores principales de Clang, un compilador de código abierto que se utiliza en conjunto con LLVM y que se ha convertido en una alternativa a GCC. También desempeñó un papel esencial en la creación del lenguaje de programación Swift en Apple, que se ha convertido en un lenguaje popular para el desarrollo de aplicaciones en la plataforma iOS.

Actualmente, su principal proyecto es Mojo, un lenguaje de programación que busca ser un aliado de Python.

En esta entrevista, Chris Lattner, nos dirá por qué Mojo es importante y cuál es el rol de éste en el ecosistema de Python.

Además me gustaría darle las gracias por su rápida respuesta a mis preguntas.

¡Espero la disfruten!1

Versión traducida

(1) Has desempeñado un papel fundamental en el diseño de LLVM, Clang, Swift y MLIR, y más recientemente Mojo, todos los cuales han tenido un profundo impacto en el campo de la programación. Con una amplia gama de áreas de programación, ¿cómo surgió tu interés en el diseño e implementación de lenguajes de programación?

He hablado un poco sobre esto, por ejemplo, esta entrevista podría ser de ayuda:

https://nondot.org/sabre/2013-11-07-LLVMDevMtg-LLVMEarlyDays.pdf

Puedes ver muchas más charlas aquí: https://nondot.org/sabre/Resume.html#talks

(2) ¿Cuáles fueron las principales motivaciones detrás de la creación del lenguaje Swift y qué limitaciones esperabas abordar en comparación con Objective-C?

Por favor, consulta:

• https://oleb.net/2019/chris-lattner-swift-origins/

• https://atp.fm/205-chris-lattner-interview-transcript

(3) LLVM ha dejado una huella sustancial en la industria de la compilación y optimización de código. ¿Cuáles son tus reflexiones sobre el futuro de LLVM y su relevancia para el desarrollo de lenguajes de programación?

Creo que LLVM como proyecto tiene un largo camino por delante. El proyecto LLVM incluye una amplia gama de tecnologías de herramientas, así como MLIR, y subyace en muchos lenguajes de programación en la actualidad, incluyendo Clang/Rust/Swift/Julia, entre otros. Creo que LLVM como proyecto paraguas está prosperando, pero considero que LLVM IR está desactualizado y necesita una actualización utilizando tecnologías de MLIR.

(4) Tu proyecto más reciente es Mojo, un esfuerzo por combinar la facilidad de uso de Python, utilizando su sintaxis, con un rendimiento superior. Hemos visto lenguajes como Julia intentando competir con Python en el ámbito de los sistemas de inteligencia artificial. ¿Cómo se diferencia Mojo de estas otras iniciativas?

Existen diversas mejoras técnicas (respondidas a continuación), pero la diferencia más grande con respecto a cosas como Julia, Swift o Rust es que Mojo es un miembro del ecosistema de Python, no un nuevo lenguaje. Esto significa que está muy centrado en los usuarios existentes de Python, encontrando a las personas donde están y potenciándolas, en lugar de forzar a las personas a reaprender cómo escribir constructos básicos para comenzar.

(5) Las pruebas de rendimiento muestran que Mojo tiene una ventaja significativa sobre Python. ¿Qué subyace en la velocidad excepcional de Mojo?

Comparar Mojo con Python no es muy «justo» porque las tecnologías son muy diferentes: Mojo es compilado, la implementación estándar de Python («CPython») es interpretada.

Es mucho más interesante comparar Mojo con cosas como Swift, Python o Julia. En este sentido, Mojo sobresale de varias maneras:

1. Tiene un buen control a bajo nivel como Rust.

2. Tiene buena facilidad de uso como Swift o Python.

3. Tiene características avanzadas como la sintonización automática (autotuning) que ningún lenguaje ampliamente utilizado admite.

4. Puede admitir la generación de código para GPUs y otros aceleradores.

5. Está construido sobre una plataforma tecnológica novedosa basada en MLIR, que es una primicia en la industria.

Por supuesto, hay muchos detalles que entran en juego.

(6) ¿Cuál consideras que es el principal desafío para popularizar Mojo como un lenguaje de programación y cómo ves la relación entre Mojo y Python en el futuro?

La relación es sencilla, nos gustaría que Mojo crezca para ser un superconjunto de Python con el tiempo, de la misma manera en que C++ es un superconjunto de C. Esto no significa que los lenguajes sean exactamente iguales; C++ toma nuevas palabras clave que C te permite usar, por ejemplo. Dicho esto, C y C++ han logrado coevolucionar durante muchos años, y creo que lo mismo sucederá con Mojo y Python.

No preveo un desafío significativo para popularizar Mojo, ya tenemos más de 150,000 personas que han utilizado Mojo. El principal problema con Mojo en este momento es que todavía está en una etapa muy temprana y necesita madurar :-)

(7) Dado tu gran éxito en estos proyectos, ¿cómo gana popularidad un lenguaje de programación (o herramienta de compilación)? ¿Es una combinación de experiencia técnica junto con una comunidad de apoyo, o entran en juego otros factores?

Esto es diferente para cada sistema, por ejemplo, Swift claramente se benefició de que Apple posee el ecosistema de iOS.

En el caso de Mojo, realmente se reduce a brindar a los programadores de Python existentes superpoderes, desbloquear la innovación en una comunidad importante (desarrolladores de IA) y alinearse con los cambios en los hardware impulsados por el fin de la ley de Moore.

Suscríbase ahora

Original

(1) You've played a pivotal role in designing LLVM, Clang, Swift, and MLIR, and most recently Mojo, all of which have had a profound impact on the field of programming. With such a wide array of programming areas, how did your interest in programming language design and implementation come about?

I’ve spoken about this a bit, e.g. this interview might be helpful:

https://nondot.org/sabre/2013-11-07-LLVMDevMtg-LLVMEarlyDays.pdf

(You can see many more talks here: https://nondot.org/sabre/Resume.html#talks)

(2) What were the primary motivations behind creating the Swift language, and what limitations were you aiming to address in comparison to Objective-C?

Please check out:

• https://oleb.net/2019/chris-lattner-swift-origins/

• https://atp.fm/205-chris-lattner-interview-transcript

(3) LLVM has left a substantial mark on the compilation and code optimization industry. What are your thoughts on the future of LLVM and its relevance to the development of programming languages?

I think that LLVM as a project has a long life ahead of it. The LLVM project includes a wide range of toolchain technologies as well as MLIR, and underlies many programming languages today, including Clang/Rust/Swift/Julia/etc. I think that LLVM as an umbrella project is going strong, but I think that LLVM IR is dated and needs to be upgraded using MLIR technologies.

(4) Your latest endeavor is Mojo, an effort to blend the user-friendliness of Python, utilizing its syntax, with superior performance. We've seen languages like Julia attempting to compete with Python in the realm of AI systems. How does Mojo set itself apart from these other initiatives?

There are various technical improvements (answered below) but the biggest difference from things like Julia or Swift or Rust is that Mojo is a member of the Python ecosystem, not a new language. This means that it is very existing-Python user centric, meeting people where they are and lifting them, rather than forcing people to relearn how to write basic constructs to get going.

(5) Performance benchmarks show Mojo having a significant edge over Python. What underlies Mojo's exceptional speed?

Comparing Mojo to Python isn’t very “fair” because the technologies are so different: Mojo is compiled, Python’s standard implementation (“CPython”) is interpreted.

It is far more interesting to compare Mojo to things like Swift or Python or Julia.  Here Mojo excels in a few ways:

1. It has good low-level control like Rust.

2. It has good usability like Swift or Python.

3. It has advanced features like autotuning that no widely used language supports.

4. It can support code generation for GPUs and other accelerators.

5. It is built on a novel technology platform built on top of MLIR, which is an industry first.

There are also many details that go into it of course.

(6) What do you consider the primary challenge in popularizing Mojo as a programming language, and how do you foresee the relationship between Mojo and Python in the future?

The relationship is straightforward, we’d like Mojo to grow to be a superset of Python over time, in the same way that C++ is a superset of C. This doesn’t mean that the language is exactly the same — C++ takes new keywords that C allows you to use, for example. That said, C and C++ have managed to co-evolve for many years, and I think the same will happen with Mojo and Python.

I don’t foresee a significant challenge popularizing Mojo we already have >150K people who have used Mojo.  The major problem with Mojo right now is that it is still very early and needs to grow up :-)

(7) Given your substantial success in these projects, how does a programming language (or compiler tool) gain popularity? Is it a blend of technical expertise along with a supportive community, or do other factors come into play?

This is different for every system, e.g. Swift clearly benefited from Apple owning the iOS ecosystem.

In the case of Mojo, it really comes down to giving existing Python programmers superpowers, unlocking innovation in an important community (AI Developers), and aligning with changes in hardware driven by the end of Moore’s law.

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Gordana Dodig-Crnkovic obtuvo su primer doctorado en Física Teórica desde la Universidad de Zagreb, en 1988. Su carrera se divide en tres décadas. La primera estuvo dedicada a la Física, trabajando en el Instituto de Investigación Rudjer Boskovic en Zagreb. La siguiente década la pasó en la industria, trabajando para la compañía sueca ABB como analista de seguridad crítica para ABB Atom. Y en la última década, se trasladó a la ciencia de la computación, obteniendo su segundo doctorado en Ciencias de la Computación en la Universidad de Mälardalen en Suecia en 2006.

En la actualidad es profesora de Ciencias de la Computación en la Universidad de Mälardalen y profesora de Diseño de Interacción en la Universidad de Tecnología de Chalmers, ambas en Suecia. Su investigación actual se centra en dos áreas principales. En primer lugar, estudia los mecanismos de la computación y la conexión entre la computación natural/morfológica, la información y la cognición. Su segundo enfoque se relaciona con la ética de la tecnología y el estudio del diseño computacional basado en valores. En esta entrevista nos centramos en la primera área.

Dodig-Crnkovic es un ejemplo de la capacidad de conectar y darle coherencia a ideas provenientes de distintos campos de estudios, donde la computación tiene un papel principal, pero mirando siempre hacia la ciencia y la filosofía.

Tuve la oportunidad de conocer a Gordana cuando leí su artículo «Significance of Models of Computation, from Turing Model to Natural Computation», que me provocó una grata impresión. Y luego descubrí muchos otros de sus artículos sobre temas similares que están escritos con una bella claridad.

¡Espero disfruten la entrevista!1

Versión traducida

(1) Recientemente encontré tu artículo titulado «Significance of Models of Computation, from Turing Model to Natural Computation» (Importancia de los Modelos de Computación, desde el Modelo de Turing hasta la Computación Natural) y quedé intrigado por el concepto de «Computación natural». Dado que la mayoría de las personas que leen el newsletter son programadores, me gustaría indagar más sobre este tema. ¿Podrías brindar alguna perspectiva sobre este asunto?

Gracias, Camilo, por tu pregunta. En efecto, los enfoques computacionales naturales son modelos emergentes poderosos para comprender la naturaleza. El término «computación natural» se refiere a procesos computacionales observados en la naturaleza, y la computación diseñada por humanos a menudo se inspira en la naturaleza, por lo que encontramos inspiración en la química, la física, la biología y los procesos cognitivos de lo más básico (celular) hasta la cognición humana.

Cuando se analizan fenómenos naturales complejos en términos de procesos computacionales, se mejora nuestra comprensión tanto de la naturaleza como de las posibilidades de la computación. Es un aprendizaje bidireccional, como argumentan Rozenberg y Kari en su artículo «The Many Facets of Natural Computing», describiendo nuevos posibles mecanismos que se pueden utilizar para computar, mejorar procesos computacionales, diseñar algoritmos o crear nuevos paradigmas de computación imitando a la naturaleza. Actualmente, dos dominios de la computación natural están especialmente en foco: la computación cuántica y la computación biológica.

Aquí tienes una cita ilustrativa:

Una obra de referencia clásica es el «Handbook of Natural Computing», editado por Grzegorz Rozenberg, Thomas Bäck y Joost N. Kok. El manual abarca las principales ramas de la computación natural, que incluyen la Computación Cuántica, la Computación Evolutiva, la Computación Neural, la Computación Molecular, la Computación de Membranas, la Inteligencia de Enjambre y los Sistemas Inmunitarios Artificiales. Curiosamente, no aborda la Computación Cognitiva, que es de gran interés científico en nuestra era de la IA.

(2) En su opinión, ¿qué importancia tiene el estudio de la filosofía para las personas que se dedican a la computación?

En esta etapa del desarrollo de la computación, y especialmente en la actual revolución de la inteligencia artificial, donde el conocimiento de todos los demás campos está directamente relacionado con la computación, la división existente en campos de conocimiento dispares con diferentes suposiciones, métodos, aplicaciones y prioridades es insostenible.

La filosofía proporciona un marco común y unificador que establece conexiones entre campos de conocimiento dispares y nos ayuda a comprender y avanzar mejor. Esa fue la razón por la cual organicé un curso hace casi veinte años, que comenzó como Filosofía de la Ciencia de la Computación y se desarrolló en Filosofía de la Computación. Entre las disciplinas filosóficas, veo la filosofía natural contemporánea como el campo capaz de ejercer una fuerza cohesiva entre varios programas de investigación.

Como observó acertadamente Stephen Wolfram:

Efectivamente, también existe la filosofía computacional, que utiliza técnicas computacionales para respaldar la investigación filosófica.

En el mundo de los compartimentos estancos de conocimiento especializado, la computación y la información son un lenguaje común, la lengua franca de todos esos campos. Para conectarlos, necesitamos un contexto común. El mejor que conozco es la filosofía natural computacional. Hay tres números especiales de la revista Philosophies dedicados a la Filosofía Natural Contemporánea que reúnen investigaciones interdisciplinarias de diversas disciplinas.

Creo que el enorme desarrollo de la inteligencia artificial pone de manifiesto cuestiones filosóficas profundamente relevantes para todas las personas, especialmente para aquellos que desarrollan y aplican nuevas tecnologías informáticas.

(3) Ha trabajado extensamente con modelos info-computacionales. ¿Cómo se relacionan con los conceptos de emergencia, morfología y autorregulación?

En la base de todo está la idea de computar la naturaleza, que es el modelo de la naturaleza o el universo expresado en términos de estructuras informativas con dinámica computacional. En este enfoque, cuyas raíces históricamente se remontan a John Archibald Wheeler, la información y su dinámica son relativas al observador. Definitivamente no es «inmaterial», como se puede encontrar en la web, sino relacional. La información siempre se implementa en objetos físicos, pero su significado se deriva de la relación con un observador. Por ejemplo, sabemos que diferentes seres vivos observan el mundo de diferentes maneras, según los tipos de sensores y actuadores que tienen. Algunos no pueden ver y otros ven en diferentes longitudes de onda. Un observador puede ser cualquier sistema que reciba información y actúe en función de ella. Puede ser un ser humano, pero también una sola célula, un robot o un sistema similar capaz de registrar y procesar información. En este enfoque, el mundo se describe como una red de redes de agentes computacionales que intercambian información en diferentes niveles de organización, desde escalas microscópicas hasta macroscópicas. Es importante tener en cuenta que la información es el resultado de la relación entre objetos físicos incorporados y sus procesos.

Los procesos emergentes se explican mediante las interacciones entre las partes en un nivel de organización de un sistema, que producen comportamientos que se encuentran un nivel por encima: los insectos crean enjambres, los peces forman bancos, las personas crean sociedades.

Estas interacciones entre los objetos en el universo, en una variedad de escalas, conducen a la complejización de sus estructuras. En cuanto a la emergencia, Lee Smolin hizo una observación interesante:

El marco info-computacional se basa en la idea de la computación física/morfológica/corporizada (embodied). Basándose en estructuras descritas como información, los procesos en diferentes niveles de escala en la naturaleza pueden entenderse como computaciones intrínsecas y morfológicas realizadas por la materia/energía. Nuestra tecnología computacional diseñada es un subconjunto de las computaciones morfológicas realizadas por sistemas naturales a los cuales se pueden delegar tareas computacionales, como en el caso del «caminante pasivo», un robot simple cuya morfología le permite «caminar» por la pendiente sin necesidad de controles externos adicionales. Para obtener más información sobre los mecanismos computacionales subyacentes, se puede consultar el libro «How the Body Shapes the Way We Think» de Rolf Pfeifer y Josh Bongard, así como el artículo «Morphological Computation: Connecting Body, Brain, and Environment» de Rolf Pfeifer y Fumiya Iida.

(4) ¿Qué investigación le ha apasionado más y qué lecciones le dejó?

Para mí, la pregunta fundamental era cómo conectar los puntos del conocimiento fragmentario de diferentes disciplinas en un conjunto coherente. Esas disciplinas fueron las que encontré en mi desarrollo como investigador: física, computación, ciencia cognitiva, filosofía y recientemente biología, con la evolución de las especies naturales. Mi enfoque se basa en nociones fundamentales de información y computación, que son mecanismos subyacentes de generación de conocimiento. Esto no significa que el mundo sea solo información y computación, pero es una perspectiva muy útil.

Aprendí que la información y el conocimiento son relativos al observador, como mencioné. Esto no significa que sean subjetivos, sino que los observadores con una arquitectura cognitiva similar (sensores, procesamiento de información y actuadores) tendrán una «realidad» similar. La realidad de un mosquito es bastante diferente de la realidad de un humano o del mundo de una ameba. Esto nos enseña a ser humildes con respecto a nuestras creencias sobre el mundo o el Universo y lo que es real. Será interesante ver cómo será el mundo para los agentes de inteligencia artificial que pueden diseñarse de diferentes maneras y equiparse con muchos más sensores y actuadores, más potentes que los que tenemos nosotros como humanos.

(5) ¿Qué piensa sobre el futuro de la computación en los próximos años?

Estoy de acuerdo con Wolfram en que en las próximas décadas veremos una proliferación de «Computación X» no solo en campos de investigación, sino también en todos los dominios del conocimiento y la práctica, desde la academia hasta el gobierno, la atención médica y las industrias, tanto en la cultura material como en la no material en su conjunto. En mi opinión, habrá «Inteligencia X» en todas partes, que, por supuesto, será computacional. El impresionante progreso reciente de la inteligencia artificial continuará y permeará nuestra civilización.

En este prometedor escenario futuro, sin embargo, tenemos muchos desafíos que resolver, y el principal es la sostenibilidad, tanto física (con recursos materiales y energéticos limitados) como cultural y cognitiva. La participación inclusiva y democrática de las partes interesadas es otro problema central. El desarrollo tecnológico centrado en el ser humano es el imperativo fundamental que mantendrá el desarrollo de la inteligencia artificial en beneficio de toda la humanidad.

(6) ¿Cree que las funciones del cerebro se pueden simular y comprender mediante medios computacionales?

Sin duda, los comportamientos resultantes de la actividad cerebral serán simulados cada vez más computacionalmente. No hay nada mágico en cómo funcionan los sistemas vivos. Son parte de la naturaleza y, por lo tanto, fenómenos naturales. Presentan formas evolucionadas de materia capaces de percibir, actuar, aprender y adaptarse. En un futuro no muy lejano, tendremos robots lo suficientemente inteligentes con funciones similares. Aún no hemos llegado a ese punto, pero los robots conscientes, es decir, robots que se comportarán de manera que los humanos los percibirán como conscientes, no son imposibles.

Para obtener más argumentos que respalden esta perspectiva, consulta el artículo recientemente publicado «Consciousness in Artificial Intelligence: Insights from the Science of Consciousness» de Patrick Butlin, Robert Long, Eric Elmoznino, Yoshua Bengio, entre otros.

(7) ¿Qué consejo le darías a alguien que quiera profundizar en estos temas?

Existen muchas formas de abordar este nuevo y emergente paradigma info-computacional para modelar, predecir, diseñar, gestionar y controlar sistemas. Depende completamente de tu sensibilidad y preferencias personales. Este campo es multidisciplinario, interdisciplinario y transdisciplinario. Para aquellos interesados en comprender cómo funcionan las cosas, aprender de la naturaleza es un enfoque valioso. Conectar la información y la computación con la cognición es una manera poderosa de estudiar la cognición e inteligencia, lo cual es especialmente relevante hoy en día y lo será durante varias décadas. Y como mencioné, la Computación X abarcará todo tipo de dominios, incluyendo las artes, humanidades, aplicaciones prácticas de todo tipo, puedes nombrarlo.

Personalmente, las preguntas relacionadas con la cognición e inteligencia son las más emocionantes en este momento. Una mejor comprensión de la cognición basal, la capacidad de todas las células vivas para procesar información, aprender y adaptarse, puede ayudarnos a desarrollar nuevos tipos de sistemas inteligentes diseñados, así como ayudarnos a controlar procesos de enfermedad y reparación de organismos vivos. Además, la abiogénesis, el proceso que lleva a la creación de organismos vivos a partir de la materia no viva, es muy importante de comprender. Si comenzara hoy como investigador, investigaría biología computacional y cognición en el contexto de la filosofía natural computacional, centrándome en sistemas vivos y buscando conexiones interdisciplinarias con campos de investigación adyacentes, así como enfoques filosóficos y metodológicos.

Hay mucho que aprender de la naturaleza que nos ayudará a comprender cómo funcionan las cosas en realidad y cómo pueden funcionar y relacionarse entre sí. Este proceso de aprendizaje es, al mismo tiempo, el proceso de liberación de los seres humanos y la toma de cada vez más influencia en nuestras vidas.

El nuevo poder vendrá con una nueva responsabilidad hacia la humanidad y el planeta. Se aplica el antiguo adagio: «Con gran poder viene una gran responsabilidad».

Suscríbase ahora

Gordana Dodig-Crnkovic earned her first doctorate in Theoretical Physics from the University of Zagreb in 1988. Her career spans three decades. The first was dedicated to Physics, working at the Rudjer Boskovic Research Institute in Zagreb. The following decade was spent in industry, working for the Swedish company ABB as a criticality safety analyst for ABB Atom. In the last decade, she transitioned to computer science, earning her second doctorate in Computer Science from Mälardalen University in Sweden in 2006.

She currently holds positions as a Professor of Computer Science at Mälardalen University and a Professor of Interaction Design at Chalmers University of Technology, both in Sweden. Her current research focuses on two main areas. First, she studies the mechanisms of computation and the connection between natural/morphological computation, information, and cognition. Her second focus relates to the ethics of technology and the study of value-based computational design. In this interview, we are primarily addressing the first area.

Dodig-Crnkovic is an example of the ability to connect and give coherence to ideas from various fields of study, where computing plays a central role, but always with an eye toward science and philosophy.

I had the opportunity to get to know Gordana when I read her article “Significance of Models of Computation, from Turing Model to Natural Computation,” which left a positive impression on me. Later, I discovered many of her other articles on similar topics, all written with beautiful clarity.

Original

(1) I recently came across your article titled “Significance of Models of Computation, from Turing Model to Natural Computation” and found myself intrigued by the concept of “Natural Computation.” As the majority of the readers of this newsletter are programmers, I would like to inquire further about this topic. Could you provide some insight into this subject matter?

Thank you, Camilo, for your question. Indeed, Natural computational approaches are powerful emerging models for understanding nature. “Natural computation” refers to computational processes observed in nature, and human-designed computing is often inspired by nature, so we find inspiration in nature on the level of chemistry, physics, biology, and cognitive processes from basal (cellular) to human cognition.

When complex natural phenomena are analyzed in terms of computational processes, our understanding of both nature and the possibility of computation is enhanced. It is a two-way learning as Rozenberg and Kari argue in their paper The Many Facets of Natural Computing, describing new possible mechanisms that can be used to compute, improve computational processes, design algorithms, or create new paradigms of computing by mimicking nature. Currently, two domains of natural computing are especially in focus: quantum computing and biological computing.

Here is an illustrative quote: 

Classic reference work is the “Handbook of Natural Computing”, edited by Grzegorz Rozenberg, Thomas Bäck, and Joost N. Kok. The handbook spans the major branches of natural computing, including Quantum Computing, Evolutionary Computation, Neural Computation, Molecular Computing, Membrane Computing, Swarm Intelligence, and Artificial Immune Systems. Interestingly, it does not cover Cognitive Computing, which is of great scientific interest in our era of AI.

(2) In your opinion, how significant is the study of philosophy for individuals pursuing computation?

At this stage of the development of computing, and especially the ongoing AI revolution where knowledge of all other domains is directly connected to computing, the existing division into disparate knowledge fields with different assumptions, methods, applications, and priorities, is untenable. Philosophy provides a common, unifying overarching framework that brings connections between disparate knowledge fields and helps us better understand and move forward. That was the reason why I organized a course almost twenty years ago, that started as Philosophy of Computer Science and developed into Philosophy of Computing. Among philosophical disciplines, I see contemporary natural philosophy as the field capable of bringing a cohesive force among various research programs. 

As Stephen Wolfram rightly observed: 

Sure enough, there is also Computational philosophy, that uses computational techniques to support philosophical research. 

In the world of separated silos of specialized knowledge, computation and information are a common language, lingua franca of all those fields. To connect them, we need a common context. The best one I know of is Computational natural philosophy. There are three special issues of the Journal Philosophies dedicated to Contemporary Natural Philosophy bringing together interdisciplinary research from a variety of disciplines. I believe that the enormous development of AI brings to the fore philosophical issues deeply relevant for all people, particularly those who develop and apply new computing technologies.

(3) You have worked extensively with info-computational models. How do they relate to the concepts of emergence, morphology, and self-regulation?

At the bottom is the idea of computing nature, which is the model of nature or universe expressed in terms of informational structures with computational dynamics. In this approach whose roots historically can be traced back to John Archibald Wheeler, information and its dynamics are observer-relative. Definitely not “immaterial” as one may find on the web, but relational. Information is always implemented in physical objects, but its meaning is given by the relation with an observer. For example, we know that different living beings observe the world in different ways, depending on which kinds of sensors and actuators they have. Some cannot see, and some see in different wavelengths. An observer can be any system that receives information and acts upon it. It could be a human, but also a single cell, a robot, or a similar system capable of registering and processing information. The world in this approach is described as a network of networks of computational agents exchanging information at different levels of organization, from microscopic to macroscopic scales. Important to keep in mind is that information is the result of the relation between embodied physical objects and their processes. 

Emergent processes are explained through the interactions between the parts on one level of organization of a system, producing behaviors that lie one level above: insects create swarms; fish form schools, people create societies.

Those interactions between the objects in the universe, on a variety of scales, lead to the complexification of its structures. Regarding emergence, Lee Smolin made an interesting observation:

The info-computational framework builds on the idea of physical/ morphological/ embodied computation. Based on structures described as information, processes at different levels of scale in nature can be understood as intrinsic, morphological computations performed by matter/energy. Our designed computational technology is a subset of morphological computations performed by natural systems to which computational tasks can be delegated, as in the case of the “Passive walker” a simple robot whose morphology makes it capable of “walking” down the slope without additional external controls. More about the underlying computational mechanisms can be found in the book “How the Body Shapes the Way We Think” by Rolf Pfeifer and Josh Bongard and e.g., the article “Morphological Computation: Connecting Body, Brain, and Environment” by Rolf Pfeifer and Fumiya Iida.

(4) What research have you been most passionate about, and what lessons did it teach you?

For me, the fundamental question was how to connect the dots of fragmentary knowledge from different disciplines into a coherent whole. Those disciplines were the ones I encountered in my development as a researcher: physics, computing, cognitive science, philosophy, and recently biology, with the evolution of natural species. My approach is based on fundamental notions of information and computation, which are underlying mechanisms of knowledge generation. It does not mean that the world is only information and computation. But it is a very useful perspective. I learned that information and knowledge are observer-relative, as I mentioned. That was a very important insight for me. It does not mean they are subjective, but means that observers with similar cognitive architecture (sensors, information processing, and actuators) will have similar ’reality’. A mosquito’s reality is rather different from a human’s reality or an amoeba’s world. This teaches us to be humble regarding our beliefs about the world or the Universe and what is real. It will be interesting to see what the world will be for AI agents that can be designed in different ways and equipped with many more and more powerful sensors and actuators compared to what we humans have.

(5) What are your thoughts on the future of computing in the years to come?

I agree with Wolfram that we in the coming decades will see a proliferation of “Computational X” through not only research fields but all knowledge and practical domains as well — from academia to government, healthcare, and industries; material and non-material culture as a whole. As I see it, there will be “Intelligent X” everywhere, which of course will be computational. Impressive recent progress of AI will continue and permeate our civilization. In this promising future scenario, we nevertheless have many challenges to solve and the main one is sustainability — physical (with limited material and energetic resources) but also cultural and cognitive. Inclusive and democratic stakeholder involvement is another central issue. Human-centric development of technology is the fundamental imperative that will keep AI development for the benefit of entire humanity.

(6) Do you believe that the functions of the brain can be simulated and comprehended through computational means?

No doubt, behaviors resulting from brain activity will be simulated computationally to an increasing degree. There is nothing magical in how living systems function. They are part of nature, and thus natural phenomena. They present evolved forms of matter, capable of sensing, acting, learning, and adaptation. We will in the not-too-distant future have intelligent enough robots with similar functions. We are not there yet, but conscious robots, that is robots that will behave so that humans will experience them as conscious, are not impossible. For more arguments for that view see the recently published article “Consciousness in Artificial Intelligence: Insights from the Science of Consciousness” by Patrick Butlin, Robert Long, Eric Elmoznino, Yoshua Bengio, et al. 

(7) What advice would you give to someone who wants to delve deeper into these topics?

There are many ways to approach this new emerging info-computational paradigm of modeling, predicting, designing, managing, and controlling systems. It depends entirely on your own sensibility and preferences. The field is multidisciplinary/ crossdisciplinarity/transdisciplinary. For those who are interested in understanding how things work, learning from nature is a good approach. Connecting information and computation with cognition is a powerful way to study cognition and intelligence which are especially important today and certainly for several decades to come. And as we mentioned, Computational X will cover all sorts of domains, including arts, humanities, practical applications of all sorts, you name it.

For me, questions related to cognition and intelligence are the most exciting right now. A better understanding of basal cognition — the ability of all living cells to process information, learn, and adapt can help us develop new types of intelligent engineered systems as well as help us control processes of disease and repair of living organisms. Also, abiogenesis, the process that leads to the creation of living organisms from non-living matter is very important to understand. If I started today as a researcher, I would research computational biology and cognition in the context of computational natural philosophy, focusing on living systems and searching the interdisciplinary connections to adjacent research fields as well as philosophical and methodological approaches. There is a lot to learn from nature that will help us understand how things actually work and may work and relate to each other. That process of learning is at the same time the process of liberation of humans and taking more and more influence over our lives.

The new power will come with a new responsibility towards humanity and the planet. The age-old adage applies: “With great power comes great responsibility.”

Esta entrevista fue originalmente realizada en inglés por email, y las respuestas fueron en audio. Por tanto, primero se ofrece una traducción al español desde la transcripción, y al final, se encuentra la versión transcrita original.

This interview was originally conducted in English by email, and the answers were in audio. Therefore, a translation into Spanish from the transcript is provided first, and at the end, you will find the original transcribed version.

Simon Peyton Jones es un destacado informático británico conocido por su influyente contribución al mundo de la informática y la programación funcional. Nacido en Sudáfrica en 1958, se graduó en la Universidad de Cambridge y completó su doctorado en el Trinity College de esa misma institución en 1980.

Peyton Jones es ampliamente reconocido por su papel en el desarrollo del lenguaje de programación Haskell, uno de los lenguajes funcionales más influyentes y utilizados en la actualidad. Ha trabajado en la investigación y promoción de la programación funcional y ha sido parte esencial en el desarrollo de la Glasgow Haskell Compiler (GHC), un compilador de referencia para Haskell.

Además de su trabajo en Haskell y la GHC, Simon Peyton Jones ha tenido una destacada carrera en Microsoft Research en Cambridge, donde ha investigado y contribuido en diversos campos de la informática y la tecnología, incluyendo la verificación de programas y la investigación sobre tipos de datos polimórficos.

Sus contribuciones al campo de la informática y su compromiso con la enseñanza y la divulgación de la programación funcional han dejado una huella invaluable en la comunidad de entusiastas de la computación y, en particular, de Haskell.

Como autor de un libro de programación funcional es para mí un honor haber podido conversar con una las mentes principales detrás de Haskell. Además, y quiero dejar testimonio, Simon tiene una gentileza inusitada.

¡Espero disfruten la entrevista!1

Versión traducida

(1) En los últimos años, muchos lenguajes de programación populares han empezado a incorporar técnicas de lenguajes funcionales. Sin embargo, lenguajes como Haskell aún no han alcanzado una popularidad comparable. En su opinión, ¿a qué se debe esta dicotomía?

Bueno, ocurren muchas cosas. Los lenguajes se adoptan no tanto por su excelencia técnica, aunque eso influye, sino por su posicionamiento sociotécnico. Y eso tiene que ver con muchas cosas, como la disponibilidad percibida de programadores que puedan utilizar el lenguaje o su nivel percibido de familiaridad. En pocas palabras, ¿utiliza llaves y, punto y coma? Haskell nunca ha buscado la popularidad o la adopción como único objetivo. Por supuesto, todo el mundo quiere que su lenguaje de programación sea adoptado y utilizado. De eso se trata. Pero siempre hemos querido que Haskell sea un lenguaje bonito, que tenga unos fundamentos intelectuales claros y que no los comprometa para, por así decirlo, buscar la popularidad.

Creo que inicialmente, también en términos históricos, Haskell surgió de un grupo de grupos de investigación de laboratorio. No surgió de un grupo de usuarios corporativos. Y muchos de los lenguajes más exitosos hoy en día han surgido de laboratorios corporativos. Quiero decir, mira TypeScript. El éxito arrollador de TypeScript, que surgió de Microsoft, y C# y Java. Todos estos lenguajes surgieron de entornos comerciales. Eso les dio mucho más poder. Es genial que ese lenguaje se haya popularizado. Pero nosotros no. Creo que Haskell ha salido gradualmente del laboratorio y ha empezado a enfrentarse a todos los retos de la adopción.

Ahora, los retos de la adopción son cosas como que la gente no adopta tu lenguaje si sigues rompiéndolo en cada nueva versión, si sigues cambiándolo de forma que rompe sus programas. Hoy en día prestamos cada vez más atención a no hacer cambios que rompan o a proporcionar formas de mitigar esos cambios. Y esa es una tarea lenta, tortuosa y que lleva mucho tiempo. Es una especie de impuesto a la innovación. Al mismo tiempo, por supuesto, es un impuesto necesario si quieres que tu lenguaje sea adoptado.

Yo diría que, con el tiempo, Haskell ha ido pasando gradualmente de tener en cuenta las preocupaciones de los adoptantes, de la gente que utiliza Haskell para temas críticos, a tener cada vez más en cuenta sus preocupaciones. Pero creo que, por así decirlo, todavía estamos en ese camino. Y creo que no es sorprendente que otros lenguajes tengan tasas de adopción mucho mayores. En cierto modo, está bien. Si Haskell se adopta, no es tanto por la gente que usa Haskell en sí, sino por la gente que adopta las ideas de Haskell.

A menudo veo Haskell como un lenguaje que es un laboratorio para desarrollar ideas que luego se pueden adoptar y utilizar en otros lugares. Y creo que cosas como las mónadas y las clases de tipos han demostrado exactamente eso. Las mónadas y las clases de tipos aparecen ahora en todo tipo de lugares, no sólo en Haskell. Así que yo diría que es una especie de adopción de Haskell, por así decirlo.

(2) Has desempeñado un papel importante en el desarrollo de GHC (Glasgow Haskell Compiler), que es el principal compilador de Haskell. ¿Podría explicarnos los retos técnicos más formidables a los que se ha enfrentado al diseñar y mejorar este compilador a lo largo de los años?

Creo que GHC comenzó alrededor de 1990, supongo, en la Universidad de Glasgow, cuando intentábamos construir uno de los primeros compiladores para Haskell. En ese momento, Lennart Augustsson también estaba construyendo un compilador para Haskell llamado HBC. Y así, inicialmente, éramos bastante modestos, pero incluso por entonces, Haskell en ese momento incluía clases de tipos. Y creo que el primer obstáculo que tuvimos fue implementar clases de tipos también. Y eso significaba el comprobador de tipos, significaba la implementación del análisis del diccionario de las clases de tipos y hacerlo razonablemente eficiente. Porque nadie quiere ejecutar programas que son demasiado lentos. Y yo diría que realmente nos tomó mucho tiempo, ya sabes, varios años para perfeccionar esa aplicación hasta el punto en que estaba haciendo un buen trabajo.

Creo que otro gran reto técnico que resolvimos muy bien en su momento fue cómo mantener los tipos sanos en todo el compilador. Haskell es un lenguaje estáticamente tipado, pero los compiladores para lenguajes estáticamente tipados no tienen por qué serlo en todo su proceso de optimización. Pero especialmente debido a las clases de tipos, queríamos mantener los tipos en nuestro programa. Así que primero pensamos en decorar el árbol sintáctico de una forma bastante ad hoc. Después de desugar (desugaring), este es el árbol de sintaxis lambda, decorándolo con información de tipos. Pero es difícil mantenerlo correcto, ¿verdad? Si tienes una función polimórfica, como, no sé, map, y la alineas (inline), entonces en la copia especializada que está alineada, las cosas que eran variables de tipo como a y b en maps el código original ahora se instancian a int y bool en la copia instanciada. Así que de alguna manera inline significa especialización y especialización de tipos.

Tuvimos una serie de soluciones ad hoc antes de que Philip Wadler finalmente señalara, bueno, todo lo que necesitas hacer es simplemente implementar el system F que tiene grandes lambdas y la reducción beta simplemente reemplaza sistemáticamente la gran lambda de a.e aplicada a un tipo T. Entonces sólo tienes que tomar e con a reemplazado por T en todas partes. Y resultó que esta era una manera increíblemente simple y directa de implementar un compilador con un fuerte sistema de tipos estáticos en todo el compilador que nadie había hecho realmente antes.

Creo que GHC sigue siendo uno de los pocos compiladores que está tipado estáticamente desde el principio hasta el final. Creo que es todo un logro. Y para mí, es un logro de Jean-Yves Girard, que inventó el system F. Resultó que el system F era realmente exactamente el adecuado para nosotros para soportar tipado estático en presencia de optimizaciones de programa al por mayor, bastante radicales. Ese fue un gran desafío técnico en ese momento, pero uno que siento que resolvimos no por ser terriblemente inteligentes, sino simplemente por usar tecnología estándar, reconociendo que podíamos usar tecnología estándar para resolverlo.

Creo que otro gran reto con el paso del tiempo fue que el comprobador de tipos se complicó cada vez más. Tenemos clases de tipo multiparámetro. Tenemos dependencias funcionales. Tenemos familias de tipos. Tenemos familias de tipos inyectivas. Tenemos nuevos tipos y nuevas coerciones de tipos. Hay mucho que hacer en el comprobador de tipos de GHC. Y gradualmente el verificador de tipos se volvió más y más difícil de mantener.

Finalmente, me di cuenta de que podíamos coger de nuevo algo de tecnología de otros lugares, esta vez de Inria en Francia, Francois Poitier y Didier Rémy, que explicaron cómo implementar un lenguaje de programación tipado estáticamente en dos pasos. Uno recorriendo la sintaxis del programa original, que es muy grande. Es decir, como muchos casos. Se camina sobre ese árbol sintáctico, generando restricciones. El proceso de generación de restricciones es relativamente sencillo. Y luego, como un paso separado, caminas sobre la sintaxis de las restricciones que has generado. Y allí, en una sintaxis muy pequeña, recorres esta pequeña sintaxis resolviendo las restricciones.

Ahora, la resolución es bastante complicada, realmente complicada. Ese es el solucionador de restricciones en GHC. Pero es completamente 100% separado del generador de restricciones, que camina sobre el gran árbol de sintaxis de los términos. Esta es una muy buena separación de preocupaciones. Ha funcionado muy bien para nosotros. Y una gran parte de lo que aprendimos de Francois y Didier no es sólo la idea, sino también, estaba en su artículo, la idea de las restricciones de implicación, donde las restricciones no son sólo planas, pero podrían ser anidadas de una manera significativa. Y eso refleja exactamente lo que ocurre durante la inferencia de tipos y la comprobación de tipos.

Creo que verás un patrón común aquí, que es que hemos tenido importantes desafíos técnicos, pero los hemos resuelto usando ideas intelectualmente profundas que tomamos de la literatura, en lugar de simplemente por un asalto frontal de resolverlo con sangre, sudor y lágrimas.

(3) ¿Existe alguna característica emergente en Haskell o en otro lenguaje de programación funcional que, en su opinión, sea muy prometedora y pueda mejorar significativamente el trabajo de los programadores?

Creo que probablemente lo más importante que podemos hacer para mejorar el trabajo de los programadores con Haskell hoy en día es promover la estabilidad, la riqueza, la eficacia y la ausencia de fricción de la cadena de herramientas. En otras palabras, creo que lo que más ayudará a los programadores profesionales a usar Haskell no son las nuevas características del lenguaje. Son que Cabal funcione perfectamente o que Hackage funcione perfectamente o que sus sistemas CI funcionen perfectamente. Para ellos es fácil adoptar nuevas versiones del compilador cuando salen. Esos son probablemente más importantes. Quiero decir, hay algunas cosas grandes en proceso. Creo que hay un viaje muy lento pero definitivo hacia la adición de más características de tipado dependiente.

A menudo se habla de Haskell dependiente como si fuera una cosa. Pero no es una cosa. Es una constelación de características. Y, de hecho, la programación dependiente tipada no es en sí misma una cosa. Pero Haskell está mejorando gradualmente en el manejo de modismos de programación tipada dependiente. Y creo que eso es interesante porque nos ayuda a explorar la frontera entre los sistemas de tipos estáticos y las pruebas. Es decir, resulta que algunos de los más entusiastas adoptantes de tipos sofisticados no son personas en entornos universitarios. Son personas en entornos industriales. Y están usando tipos estáticos complicados porque encuentran que les da una manera de tener más confianza en la corrección de su código. Y si están escribiendo código, quieren que sea mantenible dentro de dos años. En particular, quieren refactorizar de manera sustantiva donde la persona que hace la refactorización no es la persona que escribió el código. Entonces los tipos estáticos son increíblemente útiles para hacer esto. Por lo tanto, tratan de hacer más y más.

¿Qué hace un tipo estático? Explica algunas propiedades de la función, ¿verdad? Una función de tipo int a int toma un entero y devuelve un entero. Estos son requisitos y garantías. Y tipos más sofisticados te permiten decir cosas más sofisticadas sobre los argumentos y los resultados. Y explicar invariantes en estructuras de datos. Creo que es un cambio continuo y gradual hacia tipos estáticos más potentes. Creo que continuará. Hay otro gran experimento intelectual en marcha en forma de Haskell lineal. Creo que el jurado aún no ha decidido hasta qué punto funcionará bien. Pero me encanta que Haskell sea un laboratorio en el que podemos probarlo.

La gente está haciendo muchas otras cosas en Haskell. Pero yo no diría que hay una gran innovación en el lenguaje que está en el horizonte. Una más lejana. Podrías imaginar algo como tipos de fila. Los tipos de fila son una característica de los sistemas de tipos que son realmente muy expresivos. Y Haskell no lo tiene todo por el momento. Y tal vez si lo tuviera, tal vez podríamos encontrar maneras de usarlos. Ciertamente conocemos algunas de ellas. ¿Hay suficiente ímpetu para implementar tipos de fila? No estoy seguro por el momento. Pero tal vez. Pero eso es un ejemplo de algo mucho más lejano. Pero, aun así, tiene la idea de que me gustaría que GHC fuera un laboratorio en el que la gente pueda explorar ideas como esa.

(4) Además de tus contribuciones a Haskell, también ha participado activamente en proyectos de investigación en Microsoft Research. ¿Cómo percibe la interacción entre la investigación académica y la industria tecnológica y cuál es, en su opinión, su influencia en la trayectoria evolutiva de los lenguajes de programación?

Bueno, hay muchas cosas en esa pregunta. Veamos, yo participé en varias cosas en Microsoft. Una muy destacada es que cuando llegué por primera vez a Microsoft, pensaba, ¿cuál es la mejor manera de que un programador funcional se involucre en los productos de Microsoft? Pensé, ¿dónde estamos utilizando ya la programación funcional? Y me di cuenta de que uno de los mayores lugares es Excel.

Cada hoja de cálculo de Excel es un programa funcional. Todas esas fórmulas en una hoja de cálculo son pequeños programas funcionales. Y una hoja de cálculo con miles de fórmulas es un programa funcional bastante grande. Pero Excel no es un lenguaje de programación funcional muy bueno. No es muy potente. En particular, no proporciona ninguna facilidad para la abstracción, para definir nuevas funciones. Así que durante dos décadas enteras en Microsoft, formamos una asociación de investigación bastante productiva con el equipo de Excel. Y ahora me complace decir que Lambda, es decir, el cálculo Lambda completo, forma parte de Excel. Puedes escribir fórmulas Lambda. Dices igual a LAMBDA(X, X + 1). Esa es la función de incremento. Puede ser el valor de una celda y entonces puedes aplicar el valor de esa celda. Es un valor perfectamente de primera clase. Puedes aplicarlo a otra celda. Estoy bastante orgulloso de eso.

Creo que eso significa que las ideas de la programación funcional, incluida la programación funcional de orden completamente superior del cálculo Lambda, están ahora presentes en una herramienta de usuario final. Eso es bastante emocionante. Y creo que puede ser silencioso, es una especie de combustión lenta, y puede resultar bastante influyente. También en Excel, tratando de hacer que las matrices se aniden correctamente para que pueda tener matrices de funciones y funciones que devuelven matrices y matrices que contienen matrices y así sucesivamente y celdas que contienen matrices, así como celdas que contienen funciones. Y todo eso está por venir.

Veamos, ¿qué más en Microsoft? Estuve bastante involucrado de manera periférica en F#. Ese fue el proyecto de Don Syme, pero creo que estaba bastante inspirado en muchas de las cosas que estábamos haciendo en la escuela secundaria. Me involucré en un proyecto de aprendizaje automático (ML) que trataba de ver un compilador como algo que podría ser el optimizador de un compilador, algo que podría ser impulsado por ML. Y al final no se convirtió en ningún tipo de producto. Pero la otra mitad de tu pregunta tenía que ver con, veamos, ¿cómo influye la tecnología en los lenguajes de programación o en la industria tecnológica? Así que ahora creo que la influencia es muy clara, muchos lenguajes muy influyentes han surgido de laboratorios de investigación industrial o grupos industriales.

Antes he mencionado algunas de ellas. Supongo que Swift y Go son otros que tienen patrocinadores corporativos. Rust también tiene un patrocinador corporativo en la forma de Mozilla. Así que, en cierto modo, los lenguajes de programación más utilizados han surgido casi todos, no del mundo académico, sino de la industria. Creo que es un cambio interesante. También refleja que la industria tiene ahora un montón de gente trabajando en ella que han tenido una educación bastante seria de gente como tú, tal vez, en la programación funcional y en lenguajes de programación en general. Y, por lo tanto, no son lenguajes de Mickey Mouse. Son piezas serias de diseño de lenguajes. Creo que es muy emocionante. Creo que ha habido mucha influencia de la industria en el sector tecnológico en la trayectoria evolutiva de los lenguajes de programación.

Ahora trabajo para Epic Games, donde estamos diseñando un lenguaje de lógica funcional destinado a ser utilizado como lenguaje de programación para el metaverso. Y también es, bueno, es un entorno industrial, pero estamos desarrollando un lenguaje de programación bastante emocionante e innovador que, en realidad, antes podría haberse considerado extremadamente académico.

(5) La inteligencia artificial y el aprendizaje automático representan ámbitos en continua expansión dentro de la informática. ¿Puede identificar oportunidades para la aplicación de principios de programación funcional, como los que encarna Haskell, en estos campos? Además, ¿cómo cree que estos principios pueden beneficiar a la IA y el ML?

Bueno, es difícil de decir. En cierto modo, todas las redes neuronales son programas funcionales. Así es. Una red neuronal no es más que una pila de nodos de procesamiento de flujo de datos con datos fluyendo a través de ellos, y eso es expresable muy directamente como un programa funcional. Hay muy poco de, ya sabes, escribir en esa variable mutable y leer de ese disco en una red neuronal. Nada, excepto en los bordes. Así que, en gran medida, ML son programas funcionales. Es muy influyente dentro de eso. Y también necesitan ser ejecutados en un tipo de paralelismo de datos. Y creo que un montón de técnicas de la investigación en programación funcional se están utilizando en estas configuraciones de ML a gran escala para ejecutar estos programas y datos en paralelo.

Me encantaría que Haskell fuera un lenguaje en el que se pudieran escribir programas de ML y luego diferenciarlos. Estoy trabajando en ello con algunos colegas. Pero, de todos modos, no creo que la influencia de Haskell sea muy directa en la esfera de ML por el momento. Supongo que la influencia de las técnicas de programación funcional, bueno, aparte de esta general, creo que diría que el marco, cualquiera que esté haciendo ML está pensando funcionalmente todo el tiempo. Todo el tiempo.

(6) ¿Cómo ve el futuro de la enseñanza de la informática en las escuelas con la llegada de los grandes modelos lingüísticos (LLM)?

Acabamos de pasar la última década intentando integrar la programación en las escuelas como parte de la enseñanza de la informática. Pero, ¿necesitamos seguir enseñando programación en las escuelas si, bueno, los estudiantes pueden, en lugar de intentar escribir merge sort, pueden simplemente conjurarlo con un gran modelo de lenguaje diciendo, por favor, escríbeme merge sort. Pero creo que la respuesta es definitivamente sí. Después de todo, enseñamos a los niños mucho sobre aritmética. Les damos años de formación en aritmética, años en la escuela primaria. Y, sin embargo, todo lo que hacen se puede hacer mucho más rápido con una calculadora de 5 dólares. ¿Por qué dedicamos todo ese tiempo? Bueno, creo que es porque obtienes cierta comprensión visceral de lo que son los números y obtienes cierta capacidad para estimar lo que deben ser los resultados sin usar una calculadora. Es difícil de asimilar, pero en términos objetivos, los conocimientos numéricos están estrechamente relacionados con los resultados en la vida. Las personas que no saben aritmética suelen tener malos resultados en la vida.

Creo que hay fuertes razones para creer que aprender cosas fundamentales, aunque se pueda hacer más rápido, más rápido por un ordenador extremadamente barato, sigue valiendo la pena, no vale la pena hacerlo. Quizás no todas las cosas, ¿verdad? Entonces tienes que decir, bueno, ¿qué cosas deberíamos aprender? La aritmética es una de ellas. Yo diría definitivamente que la programación es parte de eso, que cada niño debe aprender los elementos de programación para que tengan una visceral, en sus entrañas, la comprensión de cómo funcionan los ordenadores y sus fragilidades y su poder, tanto sus fragilidades y su poder. Entonces, ¿necesitamos enseñar informática? Sí. Luego está, ¿cómo podríamos enseñar informática o, de hecho, historia o inglés? Y ahí, creo, quizás los LLMs jueguen un papel. Es decir, en educación, los profesores dedican mucho tiempo a críticas de nivel relativamente bajo de los ensayos de los estudiantes o de sus programas. Y tal vez parte de esta retroalimentación de nivel relativamente bajo podría ser realizada por una especie de tutor de IA. Y creo que eso podría ser útil. Tal vez eso liberaría al profesor para dedicar más tiempo a las cosas importantes que sólo él puede hacer en ese momento.

En cuanto a la inteligencia artificial como tecnología educativa, creo que el futuro está muy abierto. Hay muchas startups intentando hacer esto, y está lejos de estar probado, muy lejos de estar probado, diría yo. Y, sin embargo, debe haber algo ahí. Tiene que haber algo ahí.

(7) ¿Qué consejo, ya sea de carácter técnico u orientado a la vida, ofrecería a las personas que aspiran a dedicar su vida a la investigación en el campo de la informática?

Bueno, es una pregunta muy amplia y abierta, ¿no? Bueno, lo primero, que es una observación común y que mucha gente dice, pero que sin embargo sigue siendo cierto, es que sigas a tu corazón, ¿no? Si te apasiona estudiar informática, estudia informática. No te empeñes en hacer otras cosas. Sigue las cosas que realmente quieres hacer. La gran ventaja de la informática como campo de estudio es que es comercialmente muy relevante. Así que, aunque no te paguen como investigador informático en una universidad, por ejemplo, o en un laboratorio de investigación de una empresa, puedes conseguir un trabajo muy bien remunerado.

Tal vez, si eres lo suficientemente apasionado, trabajes dos días y medio a la semana para una empresa, ganes mucho dinero y pases los otros dos días y medio investigando. No es una ley de hierro que todo el mundo tenga que trabajar a tiempo completo, especialmente en informática, donde la gente está relativamente, en comparación con otros sectores, ya sabes, intenta ser un poeta medieval, relativamente bien pagado, bien recompensado. Creo que somos muy afortunados.

Así que la otra sugerencia que yo haría es que no pases demasiado tiempo intentando pensar en cómo investigar en informática, sino que simplemente te pongas manos a la obra y hagas algo. Hay que sacar tiempo. Y es que, como digo, puede ser difícil conseguir financiación para ese tiempo. Puede que acabes teniendo que financiarte tú mismo. Pero entonces no seas demasiado ambicioso. Cuando empecé mi vida como investigador, tuve, bastante notablemente, y fue una característica de esa época en particular a mediados de los 80, conseguí un trabajo como profesor cuando ni siquiera tenía un doctorado en informática. No tenía ni idea de cómo investigar. Me sentaba en mi oficina y cuando no estaba enseñando, pensaba, bueno, ahora será mejor que investigue. Me sentaba con un lápiz afilado y una hoja de papel en blanco y pensaba, «quiero grandes ideas». Pero, por supuesto, las grandes ideas no caían del cielo. Pero al final, uno de mis colegas, un mentor muy simpático y servicial, me dijo: Simon, empieza con cualquier cosa, incluso con algo bastante humilde, y a ver en qué se convierte. Haz algo humilde. Empecé a escribir. Creo que era un generador de analizadores sintácticos que tomaba una gramática BNF y generaba un analizador sintáctico en Sassel, que era el lenguaje funcional que yo estaba usando entonces.

Y eso, al final, para mi sorpresa, se convirtió en un trabajo de investigación que fue publicado. Pero en cierto modo, lo más importante era que estaba haciendo algo. Por lo tanto, yo sugeriría ponerse en marcha y hacer algo, probablemente construir algo. Y a medida que lo construyes, a medida que te encuentras con desafíos, lo maravilloso de la investigación es que, si estás tratando de construir algo y te encuentras con un desafío, en lugar de tener que hackearlo de alguna manera para conseguir construirlo, que es lo que sucede si estás trabajando para una empresa que necesita esa cosa. Si eres un investigador, puedes decir, oh, eso es un problema muy interesante. Puedes girar 90 grados y empezar a estudiar ese problema. Pero estás estudiando ese problema, no en abstracto, sino porque es un problema que quieres resolver para conseguir otra cosa. Así que tienes un motivo para hacerlo. Eso es muy útil.

Lo otro es empezar a escribir pronto, escribir mucho. No hace falta que sean artículos que te publiquen, sino artículos de algún tipo, porque una vez que tienes un artículo, algo escrito sobre lo que estás haciendo, puedes compartirlo con otras personas. Puedes iniciar un diálogo. Personalmente soy alguien que investiga principalmente en diálogo con otras personas. De hecho, soy casi incapaz de pensar por mi cuenta.

Es muy útil dialogar con otros y hablar con otros. Es muy útil tener algo escrito que compartir con ellos, que puedan leer y que tenga sentido. Y eso te ayudará a escribir.

¿Qué sugiero? Saca algo de tiempo para investigar, si es necesario, trabajando a tiempo parcial. Empieza a hacer algo, incluso algo que no parezca muy de investigación, sólo para ponerte en marcha en algo. Escribe pronto y a menudo sobre lo que estás haciendo e intenta encontrar a otras personas con las que puedas compartirlo y entablar conversación. Ésas serían mis sugerencias iniciales, creo.

No creo que debas decir: «No puedo empezar a menos que alguien me pague por hacer un doctorado o consiga un trabajo en Microsoft Research o algo así», porque entonces te estás abocando al fracaso. Si realmente quieres hacer un doctorado, quizá tengas que ahorrar algo de dinero para hacerlo. Probablemente consigas una plaza, pero es muy difícil encontrar gente que te pague por investigar, ¿verdad? Cuando todavía no tienes un historial para hacerlo. Así que encuentras otra manera. Pero la otra cosa, por supuesto, es que incluso en tu trabajo diario como desarrollador de software, te encuentras todo el tiempo con problemas de investigación.

Y así, y muchas empresas, sobre todo en algunos aspectos, bueno, no sé, tal vez no es una cuestión de tamaño. Es sólo que muchas empresas en realidad te dan un poco de holgura. Si dices, aquí hay un problema interesante, creo que podemos resolver este desafío de una manera más general o sustantiva que simplemente hackearlo. Muchas de ellas te darán un poco de margen para intentarlo. Por lo tanto, casi se puede hacer un poco de investigación en el contexto de un entorno corporativo. A veces depende un poco de la empresa. Depende un poco de qué tipo de código estás escribiendo.

Estupendo. Bueno, espero que esto haya sido útil. Gracias Camilo. Saludos.

Suscríbase ahora

Original (transcripción)

(1) In recent years, many widely adopted programming languages have begun to incorporate functional language techniques. However, languages like Haskell have not yet achieved comparable popularity. What, in your estimation, accounts for this distinct dichotomy in adoption rates?

Well, there are lots of things going on. Languages are adopted not so much because of their technical excellence, though that plays a role, but because of their sort of socio-technical positioning. And that has to do with a lot of things like the perceived availability of programmers who can use the language or its perceived level of sort of familiarity. I mean, crudely put, does it use curly braces and semicolons? Haskell has never sought popularity or adoption as its only goal. Of course, everybody wants their programming language to be adopted and used. That's the point. But we've always primarily wanted Haskell to be a beautiful language, one that has clear intellectual foundations and that does not sort of compromise those in order to, as it were, pursue popularity.

I think initially also in historical terms, Haskell emerged from a bunch of laboratory research groups. It did not emerge from a group of corporate users. And many of the most successful languages these days have emerged from corporate labs. I mean, look at TypeScript. TypeScript's runaway success, which emerged from Microsoft and C# and Java. All of these languages emerged from commercial settings. And more power to them. It's great that language has become popular. But we haven't. I think Haskell has gradually, therefore, emerged from the lab and has started to grapple with all the challenges of adoption.

Now, the challenges of adoption are things like people don't adopt your language if you keep breaking it, if you keep changing it in a way that breaks their programs. We pay more and more attention these days to not making breaking changes or to providing ways to mitigate those changes. And that's a slow and quite torturous and time-consuming business. So, it's a sort of tax on innovation. At the same time, of course, it's a necessary tax if you want your language to be adopted.

I would say that over time, Haskell has gradually moved towards taking the concerns of adopters, people who are using Haskell for mission-critical purposes, to taking their concerns more and more seriously. But I think, as it were, we're still on that journey. And I think it's not surprising that other languages have got much wider adoption rates. In some ways, though, it's fine. If Haskell gets adopted, not so much by people using Haskell itself, but by people adopting the ideas in Haskell.

I often see Haskell as a language that's a laboratory for developing ideas that can then be adopted and used in other places. And I think things like monads and indeed type classes have proved exactly that. Monads and type classes show up in all sorts of places now, not just in Haskell. So, I would say that is a kind of Haskell adoption, if you like.

(2) You have played a significant role in the development of GHC (Glasgow Haskell Compiler), which stands as the primary compiler for Haskell. Could you elaborate on the most formidable technical challenges you encountered while designing and enhancing this compiler throughout the years?

I think GHC started back in about 1990, I suppose, at University of Glasgow, when we were trying to build one of the first compilers for Haskell. At the time, Lennart Augustsson was also building a compiler for Haskell called HBC. And so initially, we were pretty modest, but even by then, Haskell at that time included type classes. And I think the first obstacle we had was implementing type class as well. And that meant the type checker, it meant the dictionary parsing implementation of type classes and making it reasonably efficient. Because nobody wants to run programs that are too slow. And I would say that it really took us quite a long time, you know, several years to refine that implementation to the point where it was doing a good job.

I think another big technical challenge at the time that we solved really quite nicely was how do we keep types sane throughout the compiler? Haskell is a statically typed language, but compilers for statically typed languages don't have to be statically typed throughout their optimization pipeline. But especially because of type classes, we did want to keep types in our program throughout. And so first we thought of just decorating the syntax tree in a fairly ad hoc way. After desugaring, this is the lambda syntax tree, decorating it with type information. But it's difficult to keep correct, right? If you've got a polymorphic function, like, I don't know, map, and you inline it, then at the specialized copy that's inline, the things that were type variables like a and b in maps original code now become instantiated to int and bool in the instantiated copy. So somehow inlining means specialization and specialization of types.

We had a number of ad hoc solutions before Philip Wadler finally pointed out, well, all you need to do is to just implement system F that has big lambdas and beta reduction just systematically replaces the big lambda of a.e applied to a type T. Then you just take e with a replaced by T throughout. And it turned out this was an incredibly simple and direct way to implement a compiler with a strong static type system throughout the compiler that nobody had ever really done before.

I think that GHC perhaps remains one of the very few compilers that is statically typed all the way from the front to the back. I think that's quite an achievement. And for me, it's an achievement of Jean-Yves Girard, right, that he invented system F. It turned out the system F was really just about exactly right for us to support static typing in the presence of wholesale, quite radical program optimizations. That was a big technical challenge at the time, but one that I feel as if we solved not by being terribly clever, but by just using off the shelf technology, recognizing that we could use off the shelf technology to solve it.

Then I think another big challenge as time went on was the type checker went on getting more complicated. We got multi-parameter type classes. We got functional dependencies. We got type families. We got injective type families. We got new types and new type coercions. There's a lot going on in GHC's type checker. And gradually the type checker became more and more difficult to maintain.

Finally, I realized that we could again take some off the shelf technology, this time from Inria in France, Francois Poitier and Didier Rémy, who explained how to implement a statically typed programming language in two steps. One by walking over the syntax of the original program, which is very big. That is as many cases. You walk over that syntax tree, generating constraints. The process of generating constraints is relatively straightforward. And then as a separate step, you walk over the syntax of the constraints that you've generated. And there in a very small syntax, you walk over this small syntax solving the constraints.

Now, the solving is quite tricky, really quite tricky. That's the constraint solver in GHC. But it's completely 100% separated from the constraint generator, which walks over the big syntax tree of the terms. This is a very nice separation of concerns. It's worked really well for us. And a big part of what we learned from Francois and Didier is not just the idea, but also, was it in their paper, the idea of implication constraints, where constraints are not just flat, but could be nested in a significant way. And that exactly mirrors what happens during type inference and type checking.

I think you'll see a common pattern here, which is that we have had significant technical challenges, but we solved them by using intellectually deep ideas that we took from the literature, rather than just by a frontal assault of solving it with blood, sweat and tears.

(3) Are there any emerging features within Haskell or another functional programming language that you believe hold substantial promise and have the potential to enhance the work of programmers significantly?

I think probably the most significant thing that we can do to enhance the work of programmers with Haskell today is actually this promoting stability and the promoting the stability and richness and effectiveness, friction lessness of the toolchain. In other words, I think the primary things that will most help professional programmers use Haskell are not new language features, actually. They are that Cabal works flawlessly or Hackage works flawlessly or that their CI systems work flawlessly. And that we don't... It's easy for them to adopt new versions of the compiler when it comes out. Those are probably more important. I mean, there are some big things in process. I think there's a very slow but definite journey towards adding more dependently typed features.

People often talk about dependent Haskell as if it was a thing. But it's not one thing. It's a constellation of features. And indeed, dependently typed programming is itself not one thing. But Haskell is gradually getting better at handling dependently typed programming idioms. And I think that's interesting because it helps us to explore the boundary between static type systems and proof. By which I mean, it turns out that some of the most enthusiastic adopters of sophisticated types are not people in university settings. They are people in industrial settings. And they're using complicated static types because they find that it gives them a way to have more confidence in the correctness of their code. And if they're writing code, they want to be maintainable in two years' time. Particularly, they want to refactor in substantive ways where the person doing the refactoring is not the person who wrote the code. Then static types are incredibly helpful in doing this. So, they try to do more and more.

What does a static type do? It explains some properties of the function, right? A function of type int to int takes an integer and returns an integer. These are requirements and guarantees. And more sophisticated types let’s you say more sophisticated things about the arguments and results. And explain invariants on data structures. I think that is a continual, now quite gradual shift towards more powerful static types. I think that will continue. There's another big intellectual experiment going on in the form of linear Haskell. I think the jury's still out on how well that will play out. But I love that Haskell's a laboratory in which we can try it.

People are doing lots of other things in Haskell. But I wouldn't say there's some big language innovation that's sort of on the horizon. A more distant one. You might imagine something like row types. Row types are a sort of feature of type systems that are really quite expressive. And Haskell doesn't have it all at the moment. And maybe if it did have, maybe we could find ways to use them. We certainly know some of them. Is there enough impetus to implement row types? I'm not sure at the moment. But maybe. But that's an example of a much rather further off kind of thing. But still, it has the idea that I'd like GHC to be a laboratory in which people can explore ideas like that.

(4) Beyond your contributions to Haskell, you have also been actively engaged in research projects at Microsoft Research. How do you perceive the interplay between academic research and the technology industry, and what, in your view, is its influence on the evolutionary trajectory of programming languages?

Well, there are lots of things in that question. Let's see, I was involved in several things at Microsoft. One very prominent one is that when I first arrived at Microsoft, I was thinking, what is the best way for a functional programmer to get involved in Microsoft's products? I thought, where are we already using functional programming? And I realized that one of the biggest places is Excel.

Every Excel spreadsheet is a functional program. All those formulae in a spreadsheet are little functional programs. And a spreadsheet with thousands of formulae is quite a big functional program. But Excel is not a very good functional programming language. It's not very powerful. In particular, it doesn't provide any facilities for abstraction, for defining new functions. So over actually two whole decades at Microsoft, we formed quite a productive research partnership with the Excel team. And now I'm happy to say that Lambda, as in the full-on Lambda calculus, is part of Excel. You can write Lambda formulae. You say equals LAMBDA(X, X + 1). That's the increment function. It can be the value of a cell and you can then apply the value of that cell. It's a perfectly first-class value. You can apply it to another cell. I'm quite proud of that.

I think that means that ideas from functional programming, including fully higher order Lambda calculus functional programming, are now present in an end-user tool. That's quite exciting. And I think it may be quiet, in a sort of slow burn kind of way, may prove quite influential. Also in Excel, trying to make arrays nest properly so that you can have arrays of functions and functions that return arrays and arrays that contain arrays and so forth and cells that contain arrays as well as cells that contain functions. And all that is sort of coming.

Let's see, what else at Microsoft? I was quite involved in a peripheral way in F#. That was Don Syme project, but I think it was quite inspired by quite a lot of the stuff that we were doing in high school. I became involved in a machine learning (ML) project that was trying to look at a compiler as something that could be a compiler's optimizer, something that could be powered by ML. And that didn't ultimately emerge as any kind of product. But the other half of your question was to do with, let's see, how does the technology influence programming languages or the technology industry? So now I think that the influence is very clear that lots of very influential languages have emerged from industrial research labs or industrial groups.

I mentioned some of them earlier. I guess Swift and Go are other ones that have corporate sponsors. Rust, too, has a corporate sponsor in the form of Mozilla. So, in some ways, the most widely used programming languages have almost all emerged, not from academia, but from industry. That's an interesting shift, I think. It also reflects that industry now has a lot of people working in it who have had pretty serious educations from people like you, perhaps, in functional programming and in programming languages generally. And so, they're not Mickey Mouse languages. These are serious, serious pieces of language design. I think that's quite exciting. I think there's been a lot of influence of industry in the tech sector on the evolutionary trajectory of programming languages.

I'm now working for Epic Games, in which we're designing a functional logic language that is meant to be used as the programming language for the metaverse. And it, too, is, well, it's an industrial setting, but we are developing a pretty exciting and innovative programming language that's actually previously might have been thought of as being extremely academic.

(5) Artificial intelligence and machine learning represent continually expanding domains within computer science. Can you identify opportunities for the application of functional programming principles, such as those embodied by Haskell, in these fields? Furthermore, how do you envision these principles benefiting AI and ML?

Well, that's hard to say. I mean, at one level, all neural networks are just functional programs, really. Right. A neural network is just a stack of data flow processing nodes with data flowing through them, and that's expressible very directly as a functional program. There's very little of, you know, write to that mutable variable and read from that disk in a neural network. None, except at the edges. So, to a large extent, ML is, you know, just that ML programs are functional programs. It's very influential within that. And they also need to be executed in a very data parallelly kind of way. And I think loads of techniques from functional programming research is being used in these very large-scale mainstream ML setups to execute these programs and data parallel.

I'd love Haskell to be a language in which you could write ML programs and then differentiate them. And I'm working with a few colleagues on that at the moment. But I don't think that Haskell's influence is very direct in the ML sphere at the moment anyway. I suppose the influence of functional programming techniques, well, apart from this general one, I think I would say that the framework, anybody who's doing ML is thinking functionally all the time. All the time.

(6) How do you see the future of computer science education in schools with the advent of large language models (LLMs)?

We just spent the last decade trying to get programming embedded in schools as part of a computer science education. But do we anymore need to teach programming in schools if, well, students can, instead of trying to write merge sort, can just conjure it up with a large language model by saying, please write me merge sort. But I think the answer is definitely for me, it's yes. After all, we do teach children a lot about arithmetic. We give them years of training in numeracy, years at primary school. And yet, everything they are doing can be done much faster by a $5 calculator. Why do we spend all that time? Well, I think it's because you get some visceral understandings of what numbers are and you get some ability to estimate what outcomes must be without using a calculator. You get, and it's hard to internalize, but in objective terms, actually, numeracy turns out to be quite closely associated with life outcomes. Innumerate people generally have poor life outcomes.

I think there's strong reasons to believe that learning foundational stuff, even though it can be done faster, faster by an extremely cheap computer, is still worth it, not worth doing. Not perhaps all stuff, right? Then you've got to say, well, which stuff should we learn? Numeracy is one of it. I would definitely say that programming is part of that, that every child should learn the elements of programming so that they have a visceral, in their guts, understanding of how computers work and their frailties and their power, both their frailties and their power. So, then, so that's, do we need to teach computer science? Yes. Then there's, how might we teach computer science or indeed history or English? And there, I think, perhaps LLMs will play a role. That is to say, in education, teachers spend a lot of time on relatively low-level critiques of students' essays or of their programs. And perhaps some of this relatively low-level feedback could be done by a sort of AI tutor thing. And I think that could be helpful. Maybe that would free the teacher up to spend more of their time on the big picture stuff that only they can do at the moment.

So, for AI as a, what should we say, piece of educational technology, I think the future is wide open. There are lots of startups trying to do this stuff, and it's far from proven, far from proven, I would say. And yet, it must be something there. There's got to be something there.

(7) What counsel, be it of a technical or life-oriented nature, would you offer to individuals aspiring to devote their lives to research in the field of computer science?

Well, that's a very broad, open-ended kind of question, isn't it? Well, the first thing, which is a common observation and which lots of people say, but it nevertheless remains true, is follow your heart, right? If you are passionate about studying computer science, then study computer science. Don't sort of get too bent out of shape doing other things. Follow the things that you really want to do. The great advantage of computer science as a field of study is that it's commercially very relevant. So even if you can't get paid as a computer science researcher by a university, say, or by a company's research lab, you can get a job that's highly rewarded, highly paid.

Maybe if you're passionate enough, maybe you work two and a half days a week for a company, earn lots of money and spend the other two and a half days doing your research. It's not an iron law that everybody has to work full time, especially in computer science, where people are relatively, relatively, compared to other sectors, you know, try being a medieval poet, relatively well paid, well rewarded. I think we're very fortunate.

So, the other suggestion I would have been not to spend too long trying to think about how to do research in computer science, but just get on and do some. You need to make some time. And that's, as I say, that it might be difficult to get funded for that time. You might end up having to fund yourself. But then don't be too ambitious. When I started my life as a researcher, I did have, rather remarkably, and it was a feature of that particular time in the mid-1980s, I got a job as a lecturer when I didn't even have a PhD in computer science. I had no idea how to do research, really. I would sit in my office and when I wasn't teaching, I would be thinking, well, now I'd better do research. I would sit with a sharpened pencil and a blank sheet of paper and think, “let me have great ideas”. But of course, great ideas did not fall out of the sky. But eventually, one of my colleagues, very nice, helpful mentor that I had said, Simon, just start on anything, even something quite humble and see what it turns into. Just do something humble. I started writing. I think it was a parser generator that would take a BNF grammar and generate a parser in Sassel, which was the functional language that I was then using.

And that, in the end, to my surprise, did turn into a research paper that was published. But in a way, the most important thing was that I was doing something. So, I'd suggest get on and do something, probably build something. And as you build it, as you come across challenges, the wonderful thing about research is if you're trying to build something and you come across a challenge, instead of just having to sort of somehow hack around it to get the thing built, which is what happens if you're working for a company that needs that thing. If you're a researcher, you can say, oh, that's a very interesting problem. You can sort of turn right through 90 degrees and start studying that problem. But you're studying that problem, not in the abstract, but because it's a problem you want to solve to get something else done. So you've got a motive for getting it done. That's very helpful.

The other thing is then start to write early, write a lot. It doesn't need to be papers that you get published, but papers of some kind, because once you've got a paper, something written about what you're doing, you can share it with other people. You could start a dialogue. I personally am somebody who does research mainly in dialogue with other people. I'm almost incapable of thinking on my own, actually.

It's very helpful to talk to others and to talk to others. It's really helpful to have something written to share with them that they can read and make sense of. And it will help your writing skills to do that.

What am I suggesting here? Carve out some time to do research, if necessary, by working part-time. Start doing something, even something that doesn't feel very research, just to get going on something. Write early and often about what you're doing and try to find other people that you can share that with and get into conversation with. Those would be my initial suggestions, I think.

Do not, I think, say, “I can't really get started unless somebody pays me to do a PhD or I can get a job at Microsoft Research or something like that,” because then you're setting yourself up to fail. I mean, if you really want to do a PhD, then maybe you need to save up some money to do it. You probably get a place, but it's jolly hard finding people to pay you to do research, right? When you don't yet have a track record to do it. So, you find another way. But the other thing, of course, is that even in your day job as a software developer, you're all the time coming across research problems, really.

And so, and many companies, particularly in some ways, well, I don't know, maybe it's not a matter of size. It's just that many companies will actually give you some slack. If you say, here is an interesting problem, I think we can solve this challenge in a more general or substantive way than just hacking through it. Many of them will give you a bit of leeway to try that out. So, you can almost do a bit of research kind of stuff in the context of a corporate setting. Sometimes it depends a bit on the company. It depends a bit on what kind of code you're writing.

Great. Well, I hope this has been helpful. Thanks Camilo. Cheers.

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Brian Kernighan, nació en 1942 en Toronto, Canadá. Es un influyente científico de la computación y autor destacado en el mundo de la informática. Obtuvo su doctorado en informática en la Universidad de Princeton y luego se unió a Bell Labs, donde desempeñó un papel crucial en el desarrollo del sistema operativo Unix junto con Dennis Ritchie y Ken Thompson.

Kernighan es conocido por su coautoría junto con Ritchie del libro «The C Programming Language», que se convirtió en un estándar en la programación en C. Además, fue coautor de AWK, un lenguaje de programación ampliamente utilizado para el procesamiento de texto en sistemas Unix. Y de AMPL, un lenguaje de programación algebraica utilizado para problemas matemáticos, por ejemplo, de optimización.

A lo largo de su carrera, Kernighan ha escrito una impresionante y devastadora variedad de libros de programación:

• «The C Programming Language» (1978). Coescrito con Dennis Ritchie.

• «The Unix Programming Environment» (1984). Coescrito con Rob Pike.

• «The Practice of Programming» (1999). Coescrito con Rob Pike.

• «AMPL: A Modeling Language for Mathematical Programming» (1993). Coescrito con Robert Fourer y David Gay.

• «Go Programming Language» (2015). Coescrito con Alan A. A. Donovan.

• «The AWK Programming Language» (2023, segunda edición). Coescrito con Alfred Aho1 y Peter Weinberger.

Brian Kernighan es una figura destacada en la historia de la informática y su trabajo ha dejado una huella indeleble en el campo de la programación y la computación.

Brian Kernighan a lo largo de su vida a mencionado frases geniales que me gustaría mencionar:

• «Controlar la complejidad es la esencia de la programación».

• «Cada nuevo usuario de un nuevo sistema descubre una nueva clase de errores».

• «No comentes código incorrecto: reescríbelo».

• «El 90% de la funcionalidad entregada ahora es mejor que el 100% entregado nunca».

• «La herramienta de depuración más eficaz sigue siendo una reflexión cuidadosa, junto con declaraciones impresas (print) colocadas juiciosamente».

Como escritor de libros de programación que ha leído «The C Programming Language» y que le encanta usar AWK, no puedo más que sentirme afortunado de que Brian haya contestado amablemente —y velozmente— a mis inquietudes.

¡Espero disfruten la entrevista!2

Versión traducida

(1) A lo largo de tú carrera, has escrito numerosos libros que se han convertido en recursos de referencia para diversos lenguajes de programación, como C y Golang. Con la reciente publicación de una nueva edición del libro AWK, ¿qué elementos hacen que un libro sobre lenguajes de programación resulte atractivo y cautive a los lectores?

Creo que lo más importante es tener una secuencia de ejemplos que puedan ser relevantes para los lectores, que sean realistas (no artificiales ni tontos) y que aparezcan justo en el momento en que el lector se está preguntando cómo hacer algo o pensando en el siguiente paso. Es difícil hacerlo bien, y no voy a decir que lo haya conseguido en ninguno de mis libros, pero sin duda es el objetivo.

(2) Has diseñado múltiples lenguajes de programación, como AWK y AMPL. ¿Qué dificultades encontró al crear estos lenguajes y cuáles fueron las lecciones esenciales que aprendió de esas experiencias?

Mi forma de diseñar lenguajes es intentar encontrar formas naturales de expresar algún tipo de cálculo, utilizando ejemplos básicos. Quiero que sean fáciles y naturales. Para algunas situaciones, también es de gran ayuda que la sintaxis del lenguaje sea al menos culturalmente compatible con otros lenguajes, si no la misma. Así que en AWK, tomamos prestado mucho de C, como if-else y un tipo de bucle for. Pero había otros lugares en los que eso no funcionaba, como la inclusión de expresiones regulares, así que hubo que inventarlas.

AMPL es lo bastante diferente como para que gran parte de la sintaxis fuera nueva, aunque intentamos que las entidades básicas (conjuntos, parámetros y expresiones de indexación) estuvieran claras. Pero en aquel momento no pensamos en utilizar AMPL como un verdadero lenguaje de programación; era puramente declarativo. Con el paso de los años (obra de David Gay, no mía) añadimos condicionales, bucles, funciones, etc., básicamente todos los demás mecanismos de los lenguajes de programación convencionales. Pero la sintaxis es diferente, por lo que es un poco más difícil de aprender que si la hubiéramos tomado directamente de C o similares.

(3) ¿Qué opina sobre el futuro de AWK? ¿Qué funciones debería tener en esta era de big data?

AWK sigue siendo un lenguaje realmente útil para el análisis exploratorio de datos o EDA (Exploratory data analysis). Cuando tienes que empezar a procesar un nuevo tipo de datos, AWK es genial para averiguar qué hay en los datos. ¿Cuáles son los rangos de valores de los datos en cada campo? ¿Hay el mismo número de campos? ¿Qué tipos de caracteres extraños aparecen? ¿Cuáles son los valores comunes y cuáles los atípicos? En general, ¿son válidos los datos o tienen errores potenciales? Un nuevo capítulo en el nuevo libro de AWK habla de esto en profundidad, y también hay un ensayo independiente sobre ello en www.awk.dev, el sitio web del libro. Nada de esto requiere nuevas funciones, aunque hay características que podrían mejorarlo. Por ejemplo, poder obtener datos de Internet sería de gran ayuda. Eso está en la versión GNU de AWK (Gawk), gracias a Arnold Robbins, pero no en mi versión.

(4) Tras una larga carrera en el desarrollo de software, ¿cuál es el principal obstáculo que impide a los programadores alcanzar una mayor pericia en un lenguaje de programación y en el desarrollo de software en general?

El volumen de material, el ritmo de cambio y la creciente complejidad; todo es demasiado. Simplemente hay demasiado que saber, y no es posible convertirse en experto más que en una pequeña parte. Y las cosas cambian tan deprisa que los conocimientos de cinco o diez años antes pueden quedar obsoletos. Una de las razones por las que uso AWK, incluso para cosas en las que otra cosa sería mejor opción, es que realmente lo conozco bien y no tengo que andar buscando cosas. He abandonado el desarrollo web (no es que haya hecho mucho) porque se convirtió en un montón de trabajo y no muy gratificante. Las aplicaciones para teléfonos son peores.

(5) Eres coautor del libro «The Practice of Programming». ¿Existen nuevas prácticas (o herramientas) que hayan surgido en los últimos años que beneficien a un mejor estilo de programación?

Sospecho que herramientas como Docker, Kubernetes, Travis y un sinfín más ayudan a gestionar grandes proyectos de software, pero no las uso así que no tengo conocimiento de primera mano. Yo uso Git y GitHub, y definitivamente hacen la vida mejor, aunque confío en amigos para consejos sobre más que el uso básico de Git. Pero estos son para bases de código más grandes que cualquier cosa en la que trabajo regularmente.

(6) En 2019, publicaste el libro «UNIX: A History and a Memoir». Me gustaría preguntarte sobre tus ideas y pensamientos con respecto al futuro de UNIX. ¿Qué evolución prevé para este sistema operativo?

Imagino que siempre habrá sistemas llamados Unix o, como Linux, que sigan la misma estructura básica. Supongo que Linux se convertirá en el sistema operativo por defecto para todo, excepto para los portátiles de consumo, que seguirán utilizando Windows y macOS. Y macOS se parece lo suficiente a Unix / Linux que está bien para mí; Yo uso rutinariamente ambos todo el tiempo.

(7) Ha impartido una perspicaz orientación en materia de programación y escritura técnica a lo largo de su trayectoria profesional. Pero si tuvieras la oportunidad de viajar en el tiempo y dar un consejo no técnico o no relacionado con la escritura a tu yo más joven, ¿cuál sería y por qué lo consideras importante?

Es difícil responder a esta pregunta sin recurrir a tópicos y clichés. La mayoría de las veces he tenido suerte de estudiar o trabajar allí, y sobre todo de la gente con la que he trabajado. Pero decirle a mi yo más joven que «tuviera suerte» no me habría servido de nada. Quizá el mejor consejo venga de Pasteur: «El azar favorece a la mente preparada». Así que cuanto más hagas, cuanto más explores, cuanta más gente haya en tu vida, más probabilidades tendrás de tener suerte.

Suscríbase ahora

Original

(1) Throughout your career, you have authored multiple books that have become the go-to resources for various programming languages, including C and Golang. With the recent release of a new edition of the AWK book, what elements make a programming language book engaging and captivating for readers?

I think the most important thing is to have a sequence of examples that are likely to be relevant to readers, that are realistic (not artificial or silly), and that appear at just the time when the reader is wondering about how to do something or thinking about the next step. It's hard to do this well, and I won't claim to have figured it out for any of my books, but it's definitely the goal.

(2) You have designed multiple programming languages, such as AWK and AMPL. What difficulties did you encounter while creating these languages, and what were the essential lessons you learned from those experiences?

The way I design languages is to try to figure out natural ways to express some computation, using basic examples. I want those to be easy and natural. For some situations, it's also a big help if the language syntax is at least culturally compatible with other languages, if not the same. So in Awk, we borrowed a lot from C, like if-else and one kind of for loop. But there were other places where that just didn't work, like including regular expresssions, so those had to be invented.

AMPL is different enough that a lot of the syntax was new, though we tried to make it so that the basic entities —sets, parameters and indexing expressions— were clear. But at the time we didn't give any thought to using AMPL as a real programming language; it was purely declarative. Over the years we (David Gay's work, not mine) added conditionals, loops, functions, and so on, basically all the other mechanisms of conventional programming languages. But the syntax is different, so it's a bit harder to pick up than if we had borrowed more directly from C or the like.

(3) What are your thoughts on the future of AWK? What functions should it have in this era of big data?

Awk is still a really useful language for exploratory data analysis or EDA. When you have to start processing some new kind of data, Awk is great for figuring out what's in the data. What are the ranges of data values in each field? Are there the same number of fields? What kinds of weird characters appear? What are the common values and what are the outliers? Generally, is the data valid or does it have potential errors. One new chapter in the new Awk book talks about this at length, and there's also an independent essay about it at www.awk.dev, the web site for the book. None of this requires new functions, though there are features that might make it better. For example, being able to grab data from the Internet would be a help. That's in the GNU version of Awk (Gawk), thanks to Arnold Robbins, but not in my version.

(4) After a long career in software development, what is the main obstacle that prevents programmers from achieving greater expertise in a programming language and software development in general?

Volume of material, rate of change, and increasing complexity; all are way too big. There is simply too much to know, and it's not possible to become expert on more than a small part. And things change so rapidly that knowledge from five or ten years earlier may be obsolete. One of the reasons why I use Awk, even for things where something else would be a better choice, is that I really know it well and don't have to keep looking things up. I've given up on web development (not that I ever did a lot) because it became a lot of work and not very rewarding. Phone apps are worse.

(5) You are co-author of the book "The Practice of Programming." are there any new practices (or tools) that have emerged in recent years that would benefit a better programming style?

I suspect that tools like Docker, Kubernetes, Travis, and endless others all help in managing large software projects, but I don't use them so I don't have firsthand knowledge. I use Git and GitHub, and they definitely make life better, though I rely on friends for advice on more than basic use of Git. But these are for larger code bases than anything I work on regularly.

(6) In 2019, you published the book "UNIX: A History and a Memoir." I'd like to inquire about your insights and thoughts regarding the future of UNIX. What developments do you predict for this operating system?

I imagine that there will always be systems called Unix or, like Linux, that follow the same basic structure. I will guess that Linux will become the default operating system for everything except consumer laptops, which will continue to use Windows and macOS. And macOS looks enough like Unix / Linux that it's fine for me; I routinely use both all the time.

(7) You have imparted insightful programming and technical writing guidance during your professional journey. But if you had the chance to travel back in time and provide a piece of non-technical or non-writing related advice to your younger self, what would it be, and why do you deem it significant?

It's hard to answer this question without resorting to platitudes and cliches. Mostly I've just been lucky in where I happened to go to school or work, and especially in the people who I have worked with. But telling my younger self to "be lucky" would not have been helpful. Perhaps the best advice comes from Pasteur: "Chance favors the prepared mind." So the more than you do, the more you explore, the more people in your life, the more likely it is that you will be lucky.

Esta entrevista fue originalmente realizada en inglés por email. Por tanto, primero se ofrece una traducción al español, y al final, se encuentra la versión original.

This interview was originally conducted in English by email. The Spanish translation is provided first, followed by the original version.

Bjarne Stroustrup es un destacado científico de la computación danés, nacido en 1950 en Aarhus, Dinamarca. Es ampliamente conocido como el creador del lenguaje de programación C++, que revolucionó la programación y la ingeniería de software.

Stroustrup obtuvo su doctorado en Ciencias de la Computación en la Universidad de Cambridge y posteriormente se unió a Bell Labs, donde desarrolló el lenguaje C++. Su trabajo en C++ permitió la creación de sistemas más eficientes y flexibles al combinar características de programación orientada a objetos con la capacidad de bajo nivel del lenguaje C, además de incorporar muchas otras características novedosas para su época.

A lo largo de su carrera, Stroustrup ha recibido numerosos premios y reconocimientos, incluido el premio Dr. Dobb's Excellence in Programming en 2008 y ser nombrado Doctor Honoris Causa por la Universidad Carlos III (España) en 2019. Ha sido profesor en diversas universidades, incluyendo la Universidad de Texas A&M.

El legado de Bjarne Stroustrup en la informática es innegable, ya que su creación, el lenguaje C++, sigue siendo ampliamente utilizado en la industria del software y ha influido en numerosos lenguajes de programación modernos.

Me gustaría destacar algunas de sus citas más memorables —según mi opinión— que ha dicho Bjarne Stroustrup a lo largo de su vida y que paso a enlistar:1

• «C hace que sea fácil dispararte en el pie; C++ lo hace más difícil, pero cuando lo haces te vuela toda la pierna».

• «Para utilizar bien C++, hay que entender las técnicas de diseño y programación».

• «Si crees que es sencillo, entonces has entendido mal el problema».

• «Es fácil obtener el perdón por equivocarse; tener razón es lo que te mete en verdaderos problemas».

• «El diseño y la programación son actividades humanas; olvida eso y todo estará perdido».

No saben la emoción que tuve entrevistar a Stroustrup, porque C++ fue uno de mis primeros lenguajes de programación que aprendí. Con C++ me entusiasmé con la programación, me hizo entenderla bajo otros términos y, a su vez, pude enfrentarme a mis primeros retos técnicos. En suma, C++ me dio las principales alegrias, y también, los principales «infiernos».

¡Espero disfruten la entrevista!2

Versión traducida

(1) ¿Cómo surgió la idea de crear unas directrices básicas (Core Guidelines) para C++ y qué espera del proyecto en el futuro? ¿Es posible añadir «asistentes inteligentes» que puedan hacer sugerencias y revisar el código de acuerdo con las directrices básicas?

Especialmente después de C++11, mucha gente expresó su interés por saber qué era el «C++ moderno». Además, en mi trabajo en Morgan Stanley, necesitaba dar consejos para mejorar las bases de código. Obviamente, no era el único que se agarraba a esa pregunta, así que pregunté por ahí y varios de nosotros creamos el proyecto que se convirtió en «The C++ Core guidelines».

Siempre fui de la opinión de que las normas por sí solas son insuficientes. Quería —y sigo queriendo— que el análisis estático detectara vulneraciones y remitiera a las directrices pertinentes que contienen sugerencias sobre lo que se podría hacer mejor. Esto podría convertirse en un «asistente inteligente».

(2) ¿Qué características infrautilizadas del «C++ moderno» (es decir desde C++11 a C++20) podrían mejorar el código de un programador y evitar errores y aún no se utilizan ampliamente?

Cosas muy sencillas podrían ayudar, span para evitar las interfaces propensas a errores (pointer, count), vectores en lugar de arrays, punteros de gestión de recursos (unique_ptr y shared_ptr) en lugar de punteros más «desnudos» con new/delete. Uso de contenedores de rango comprobado y span.

Uso coherente de RAII y uso adecuado de excepciones.

Lo que importa no son las características individuales, sino cómo se combinan para apoyar un diseño sólido. Uso coherente del sistema de tipos. Evitar macros, moldes (casts) y void*. Eche un vistazo a The C++ Core Guidelines para obtener ideas.

(3) Desde C++11, se han incorporado más características de la programación funcional, como las expresiones lambda o std::function, que lo hacen más declarativo. ¿Hay planes para añadir más características declarativas a futuras versiones de C++?

Eso espero. Desde el día #1, he trabajado para hacer que el código sea más explícito / declarativo. Algunos ejemplos son los pares constructor/destructor que conducen a la gestión de recursos de estilo RAII y los conceptos que proporcionan una comprobación inicial del código genérico a través de una especificación más precisa. Me gustaría que la concordancia de patrones (pattern matching) al estilo funcional resolviera los problemas del código condicional y que los contratos hicieran explícitas las suposiciones. Por desgracia, no parece fácil que el comité apruebe versiones concretas de estas ideas.

(4) ¿Cuál es la estrategia recomendada para migrar una base de código C++ escrita en «C-Style» a C++ moderno dentro de un proyecto?

Por desgracia, no es fácil. Es fácil estropear un buen diseño, pero es difícil hacer que un código desordenado sea más limpio y regular. La gente suele exigir compatibilidad de errores con código desordenado antiguo, y eso no se puede tener junto con un código más limpio.

Lo primero que hay que limpiar son las interfaces.

Una vez que tengas una interfaz decente, puedes empezar a limpiar el código a cada lado de ella. Compara:

using Cmp = int(const void*, const void*); 
void qsort(void *ptr, std::size_t count, std::size_t size, Cmp* comp); 

y

template<ranges::random_access_range R, class Comp = ranges::less> sort(R&& r);

Esta última es mucho más fácil de usar y proporciona al optimizador más información para permitir un mejor rendimiento.

(5) Ha mencionado que C++ se diseñó para evolucionar desde el primer día. Tras años de experiencia, ¿hay alguna característica de C++ que le gustaría eliminar pero que ahora es inconcebible?

No hay ninguna característica importante que me gustaría eliminar, pero no se me ocurre ninguna característica importante que no pudiera hacer mejor con los conocimientos actuales. Por ejemplo, las plantillas (templates) habrían sido mejores y más sencillas si hubieran tenido conceptos desde el primer día. Lo sabía en aquel momento, pero no pude idear un diseño que ofreciera generalidad, rendimiento óptimo e interfaces bien especificadas. Podía hacer dos de esas tres cosas, pero ni yo ni nadie con quien consultara podíamos averiguar cómo conseguir las tres.

La compatibilidad con versiones anteriores —estabilidad durante décadas— es una característica importante, así que desaconsejo meterse con pequeños detalles aparentemente irrelevantes. Arreglarlos aportaría ventajas menores y probablemente molestaría a un número significativo de desarrolladores. Con millones de usuarios en todo el mundo, nunca se sabe qué se utiliza de forma crítica en algún lugar.

(6) Se habla mucho de lenguajes como Rust, Julia y Python. Sin embargo, tú has mencionado anteriormente que estos lenguajes, en particular Python, se centran en un conjunto diferente de problemas. En 2023+, ¿qué tipo de problemas requerirían que un programador utilizara C++? Lo pregunto porque puede ser un reto determinar qué herramienta es la más adecuada para una situación concreta.

Problemas que requieren un uso eficiente del hardware y cierta abstracción.

Algunos ejemplos son las principales bibliotecas utilizadas por lenguajes como Python, y sistemas como LLVM de los que dependen muchos lenguajes modernos. Sistemas embebidos complejos, como el software automovilístico y aeroespacial. Gráficos y animación. Computación científica, donde la alternativa es Fortran.

No me gustan las exageraciones.3 Se interpone en la toma de decisiones técnicas racionales y tranquilas.

(7) ¿Hay algún nuevo lenguaje o herramienta de programación que le haya sorprendido y contenga ideas que le gustaría aplicar a C++?

No tantas sorpresas, pero me encantaría contar con algún gestor estándar de paquetes y compilación para C++. Como siempre, el problema es que hay varios y es difícil elegir. Además, necesitamos mejores herramientas de análisis estático.

Suscríbase ahora

Original

(1) How did you develop the idea of creating C++ Core Guidelines, and what do you expect from the project in the future? Is it possible to add "intelligent assistants" that can make suggestions and review the code according to the core guidelines? 

Especially after C++11, many people expressed an interest in knowing what “Modern C++” was. Also, at my job in Morgan Stanley, I needed to give advice about improving code bases. Obviously, I wasn’t the only one grabbling with that question, so I asked around and several of us created the project that became “The C++ Core guidelines.”

I was always of the opinion that rules by themselves are insufficient. I wanted – and still want – static analysis to detect violations and point to the relevant guidelines that contain suggestions about what could be done better. This could develop into an “intelligent assistant.”

(2) What underutilized "modern C++" features (from C++11 to C++20) could improve a programmer's code and prevent errors and are not yet widely used?

Very simple things could help, span to avoid the error-prone (pointer, count) interfaces, vectors, rather than arrays, resource management pointers (unique_ptr and shared_ptr) rather than pointers plus “naked” new/delete. Use of range-checked containers and span.

Consistent use of RAII and appropriate use of exceptions.

What matters is not individual features but how they combine to support sound design. Consistent use of the type system. Avoidance of macros, casts, and void*.  Have a look at The C++ Core Guidelines for ideas.

(3) Since C++11, more functional language features, such as lambda expressions or std::function, have been incorporated, making it more declarative. Are there plans to add more declarative features to future versions of C++?

I hope so. From day #1, I have worked to make code more explicit/declarative. Examples are constructor/destructor pairs leading to RAII-style resource management and concepts providing up-front checking of generic code through more precise specification. I would like to see functional-style pattern matching to address problems with conditional code and contracts to make assumptions explicit. Unfortunately, it doesn’t seem easy to get concrete versions of such ideas through the committee. 

(4) What is the recommended strategy for migrating a C++ codebase written in C-style to modern C++ within a project?

Unfortunately, that’s not easy. It is easy to mess up a good design, but hard to make messy code cleaner and more regular. People often demand bug-compatibility with older messy code, and you can’t have that together with cleaner code.

The first thing to clean up is interfaces. 

Once you have a decent interface, you can start cleaning up code on each side of it. Compare:

using Cmp  = int(const void*, const void*); 
void qsort(void *ptr, std::size_t count, std::size_t size,  Cmp* comp); 

and 

template<ranges::random_access_range R, class Comp = ranges::less> sort(R&& r);

The latter is far easier to use and gives the optimizer more information to allow better performance.

(5) You mentioned that C++ was designed to evolve from day one. After years of experience, are there any features of C++ that you would like to remove but are now inconceivable?

There is no major feature I’d like to remove, but I can’t think of any major feature that I couldn’t do better with today’s knowledge. For example, templates would have been better and simpler had they had concepts from day #1. I knew that at the time but couldn’t come up with a design that offered generality, optimal performance, and well-specified interfaces. I could do any two out of those three, but neither I nor anyone I consulted with could figure out how to get all three.

Backwards compatibility – stability over decades – is a major feature, so I discourage messing with apparently irrelevant small details. Fixing them would bring minor advantages and probably annoy a significant number of developers. With millions of users worldwide, you never know what is in critical use somewhere.

(6) There is a lot of hype around languages like Rust, Julia, and Python. However, you have previously mentioned that these languages, particularly Python, are focused on a different set of problems. In 2023+, what kind of problems would require a programmer to use C++? I ask because it can be a challenge to determine which tool is best suited for a particular situation.

Problems that require efficient use of hardware and some abstraction.

Examples are major libraries used by languages such as Python, and systems like LLVM that many modern languages depend on. Complex embedded systems, such as automobile and aerospace software. Graphics and animation. Scientific computation, where the alternative in Fortran.

I dislike hype. It gets in the way of calm rational technical decision making.

(7) Are there any new programming languages or tools that have surprised you and contain ideas you would like to apply to C++?

Not so many surprises, but I would dearly love some standard packaging and build systems for C++. As usual, the problem is that there are several and it’s hard to choose. Also, we need better static analysis tools.