Entrevista a Simon Peyton Jones

Una de las mentes principales detrás de Haskell

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!¹

Imagen extraída de aquí.

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.

---

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.

1. El audio fue transcrito usando https://replicate.com/openai/whisper. Solo eliminé algunas palabras para evitar redundancia. La traducción fue hecha con DeepL y con pequeñas modificaciones de mi parte para mejorar la claridad.