Entrevista a Brian Kernighan
Cocreador de AWK y AMPL. Y coautor del libro «The C Programming Language» (K&R)
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.
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.
También tuve la oportunidad de entrevistar a Alfred Aho.
Maravillosa entrevista!! Sin duda Kernighan es un Pro en nuestra profesión