- Brian Kernighan recuerda The Practice of Programming, escrito junto con Rob Pike, como un libro que intentó tratar “cómo escribir programas bien y de manera profesional” en 1999, cuando internet, Python, Perl y Java se estaban difundiendo rápidamente.
- Aunque algunos ejemplos quedaron anticuados con el tiempo, considera que principios como estilo, depuración y actitud al escribir pueden trasladarse aunque cambien los lenguajes y los entornos.
- El parseo de CSV sigue siendo engorroso y la especificación tampoco es del todo clara; pandas es potente, pero pesado y de alto nivel de abstracción, por lo que a veces un código simple en Python puede ser mejor.
- Bell Labs fue un entorno de investigación que hizo posibles trabajos como Unix, yacc y herramientas de preparación de documentos gracias al pensamiento de largo plazo, colegas excelentes y poca presión por productos o ingresos.
- Los grandes modelos de lenguaje son una tecnología que de pronto tuvo un gran impacto desde noviembre de 2022; la experiencia de que Claude generara código Python relacionado con spaCy casi correcto anticipa cambios en la forma de trabajar de los programadores.
El entorno de programación de 1999 y el objetivo del libro
- The Practice of Programming es un libro publicado unos 15 años después de The Unix Programming Environment, que Kernighan y Rob Pike habían escrito juntos anteriormente.
- El objetivo del libro era abordar “cómo se escriben programas en la práctica” y “cómo escribirlos de forma efectiva y profesional”.
- El entorno de cómputo alrededor de 1999 era muy distinto al actual.
- Internet era algo relativamente nuevo para el público general, aparecido alrededor de 1995~1996.
- Python era un lenguaje relativamente nuevo, Perl seguía siendo fuerte y Java también era popular.
- Aunque los ejemplos concretos pueden resultar menos directos para los lectores actuales, considera que los principios generales pueden trasladarse a otros entornos.
- Los conductores consideraron que las guías de estilo y el capítulo sobre depuración siguen siendo especialmente vigentes, y les pareció llamativo que la palabra “bug” ya se hubiera usado antes de la anécdota de Grace Hopper con la computadora Mark, también en el contexto de Thomas Edison y el fonógrafo.
CSV, pandas, memoria y abstracción
- Kernighan dice, a propósito del ejemplo de parser CSV incluido en el libro, que aún hoy no existe un buen parser CSV.
- El verano pasado dedicó entre varias semanas y alrededor de un mes a usar un “parser CSV adecuado” para agregar funcionalidad CSV a awk.
- Considera que la especificación de CSV no es completamente clara y, en cierto sentido, no está estandarizada.
- pandas se evalúa como una herramienta pesada, aunque potente.
- Dice que en muchos casos es más simple escribir Python directamente que entender los mecanismos implícitos de iteración y selección al estilo pandas.
- El conductor comenta que pandas suele elegirse en trabajos de machine learning y ciencia de datos, pero que cuando se necesita un rendimiento de ejecución importante, se plantea enfoques más simples.
- La gestión de memoria se ha vuelto un área a la que casi no hace falta prestar atención en gran parte de la programación actual.
- En C hay que gestionar la memoria directamente, y eso es muy difícil.
- En C++ también es posible, pero dice que es difícil aprender las técnicas para manejarla correctamente.
- En Python lo describe como algo que funciona “por arte de magia” en la mayoría de los casos.
- Las grandes abstracciones no siempre ocultan por completo los problemas.
- Al procesar con spaCy un texto del tamaño de un libro, recibió un mensaje de falta de memoria porque la cuota de trabajo predeterminada era de 1GB, y lo resolvió duplicando la configuración.
- En la época en que Kernighan crecía, incluso los kilobytes eran una gran cantidad de memoria.
- En la comunidad de sistemas embebidos, la memoria y el rendimiento siguen tratándose como aspectos muy importantes, y en ese contexto se mencionan lenguajes como Rust o Zig, además de C.
Go, Plan 9 y el entorno de investigación de Bell Labs
- El conductor dice que las inquietudes de The Practice of Programming le dieron la impresión de ser una base para el diseño del lenguaje Go.
- Kernighan considera “totalmente creíble” que Rob Pike, uno de los tres creadores de Go, tuviera como trasfondo las incomodidades tratadas en el libro al pensar más adelante en un nuevo lenguaje.
- Sin embargo, dice que no recuerda concretamente que Pike pensara en ese momento “voy a mejorar el mundo con un nuevo lenguaje”.
- Considera que el trabajo en Plan 9 de fines de los 1990, junto con lenguajes como Limbo y Alef, formó parte de la genealogía que llevó a Go.
- La experiencia en Bell Labs fue, para Kernighan, cercana a un entorno ideal.
- Durante sus estudios de posgrado en Princeton, en la década de 1960, hizo dos pasantías de verano en Bell Labs trabajando con un grupo relacionado con Multics.
- Dice que la experiencia le gustó tanto que, al recibir una oferta para volver, no entrevistó en ningún otro lugar.
- Estuvo en Bell Labs desde comienzos de 1969 hasta alrededor de 2000.
- En Bell Labs de aquella época era posible pensar a largo plazo, y había poca presión por resultados trimestrales o por producir de inmediato productos e ingresos.
- Las personas podían trabajar de forma relativamente independiente en cosas que les parecían interesantes e importantes.
- Como AT&T proporcionaba servicio telefónico a la mayor parte de Estados Unidos, era un “entorno con muchos problemas”, y también había mucho trabajo que podía ser útil para el sistema telefónico.
- No tuvo un encuentro directo con Claude Shannon.
- Recuerda que Shannon se había ido al MIT unos años antes de que Kernighan llegara a Bell Labs.
- Kernighan dice que sí tuvo una relación cercana con Richard Hamming, quien había compartido oficina con Shannon.
Aprendizaje, escritura de libros y pensamiento programático
- El aprendizaje inicial de Kernighan ocurrió en Bell Labs, al estar expuesto a personas, herramientas y problemas interesantes.
- yacc era una herramienta que facilitaba crear nuevos lenguajes de programación, y Kernighan la aprovechó no solo para la generación tradicional de lenguajes, sino también en áreas como la preparación de documentos y los lenguajes declarativos.
- En ese proceso aprendió mucho sobre diseño e implementación de lenguajes.
- También mantuvo durante mucho tiempo interés por las herramientas de preparación de documentos.
- Recibió influencia de runoff, un programa temprano del MIT para preparación interactiva de textos.
- En Princeton escribió en Fortran un programa similar de preparación de documentos para producir su propia tesis.
- En Bell Labs creó herramientas para fabricar libros físicamente con más facilidad y evitar que los ejemplos de programas se dañaran durante el proceso editorial.
- Tras pasar a la universidad, explicar a estudiantes no especialistas cosas que ya sabía se convirtió en una fuente importante de aprendizaje.
- Tenía que explicar cómo funcionan los números binarios a estudiantes fuertes en literatura o música.
- Dice que en ese proceso también aprendió que Leibniz fue el inventor práctico de los números binarios a fines del siglo XVII y que creó algo similar a la notación hexadecimal usando notas musicales en lugar de letras.
- Dice que la motivación para escribir un libro surge cuando hay “algo que vale la pena decir” y “un coautor con quien se quiere decirlo”.
- La mayoría de los libros de Kernighan son obras en coautoría.
- Considera que el trabajo colaborativo es mucho más fácil que escribir solo, porque permite complementar y pulir el contenido mutuamente.
Grandes modelos de lenguaje, educación y libros recomendados
- Kernighan menciona como desarrollos importantes en su carrera los sistemas de tiempo compartido, Unix, la evolución de los lenguajes de programación, el aumento de recursos por la ley de Moore y la PC.
- El tiempo compartido fue un gran cambio porque permitió trabajar según el propio horario, sin estar físicamente frente a la computadora ni esperar el procesamiento por parte de un operador.
- Considera que la computación en la nube vuelve a acercarse al tiempo compartido, en el sentido de que el cómputo se centraliza y los usuarios cuentan con periféricos avanzados que se comunican con sistemas remotos.
- Como tecnología más interesante en la actualidad, señala los grandes modelos de lenguaje.
- Le parece particular que hayan aparecido de pronto alrededor de noviembre de 2022 y hayan tenido un gran impacto en poco tiempo.
- Dice que pidió a Claude, en dos o tres frases, una tarea relacionada con spaCy, y que generó código Python correcto en un 99,9%; además, su nivel de uso de Python era más sofisticado que el suyo.
- Cree que los programadores no desaparecerán, pero que es probable que cambie su forma de trabajar.
- Los LLM abren nuevos enfoques para los estudiantes.
- Una estudiante consideró que podía usar LLM para mejorar traducciones de griego antiguo.
- Dice que los resultados de OCR de documentos impresos antiguos del siglo XVIII pueden mejorarse usando el conocimiento lingüístico que tienen los modelos de lenguaje.
- En las clases para no especialistas, intenta conectar cómo funcionan las computadoras con los temas tecnológicos que ocurren en el mundo.
- Muchos estudiantes provienen de humanidades y ciencias sociales, y a menudo toman la clase para cumplir un requisito de razonamiento cuantitativo.
- Trata temas como hardware, software, comunicaciones, net neutrality, privacy, security y Google antitrust junto con sus bases técnicas.
- Considera que el pensamiento programático de dividir tareas grandes en tareas pequeñas y pensar paso a paso puede trasladarse a otros campos, como escribir ensayos o analizar problemas legales.
- Para principiantes, es importante encontrar algo que quieran hacer por sí mismos.
- Partir de problemas que les interesen, como crear juegos, mejorar sus finanzas personales o analizar textos, puede reducir la barrera psicológica.
- En la clase para no especialistas usa una tarea en la que primero se analiza Pride and Prejudice con NLTK y luego los estudiantes eligen otro libro que quieran para explorarlo del mismo modo.
- Los libros recomendados o mencionados y sus gustos de lectura son variados.
- Entre los libros técnicos, a veces vuelve a leer The Mythical Man-Month; dice que algunas partes envejecieron bien, pero que algunas expresiones lingüísticas hoy se ven muy sexistas.
- Recoding America, de Jennifer Pahlka, se menciona como un libro interesante que trata por qué el software gubernamental no funciona tan bien como se espera y por qué los sistemas dificultan las mejoras.
- Como lectura no técnica menciona historia, historia militar, novelas policiales, novelas de Dick Francis sobre carreras de caballos y Chip War, sobre semiconductores.
1 comentarios
Comentarios de Hacker News
Este libro es fundamental, así que todo programador, especialmente quien empieza, debería leerlo
Como es de esperarse de un libro de Kernighan, la prosa es simple, concisa y precisa, y en poco más de 200 páginas va directo a lo esencial sin relleno. Basta con entender los principios a partir de los ejemplos y luego aplicarlos en tu propio contexto
La virtud de los libros de K&P está en que no te aplastan con teoría, sino que primero muestran la aplicación real de la técnica y luego hacen que estudiar la teoría resulte mucho más accesible
Por ejemplo, ya teniendo experiencia en programación de redes e implementación de protocolos, leí este libro y me abrió completamente los ojos ver en el capítulo "Notations" una rutina de empaquetado/desempaquetado de mensajes de red que especifica el layout de paquetes con cadenas de formato estilo
printf/scanf. Ahí aprendí el poder de una notación adecuada y de los pequeños lenguajes, y también hay fragmentos de código que muestran ideas de máquinas virtuales, code threading y compilación JITTambién vale la pena leer junto con este libro otro más antiguo de Kernighan y Pike, "The Unix Programming Environment". El capítulo "Program Development" condensa en unas 50 páginas todo el proceso de construir un compilador para un pequeño lenguaje de calculadora usando herramientas de desarrollo de compiladores; hasta donde sé, es el texto más pequeño y simple que explica cómo escribir un compilador
En conclusión, todos los libros de Kernighan valen la pena comprarse y estudiarse
El libro de C ya lo había leído hace tiempo y recuerdo que estaba magníficamente escrito. Seguro sacaré mucha sabiduría de programación, pero también quiero analizar por qué los libros de Kernighan son tan buenos desde la perspectiva de la escritura técnica
Parece que Kernighan estudió mucho la escritura, o al menos pensó mucho sobre ella desde primeros principios. Incluso el título "The Elements of Programming Style" hace referencia al famoso libro sobre escritura "The Elements of Style" de Strunk y White
Para los estándares actuales está algo anticuado, pero sigue siendo fácil de leer
No lo digo con sarcasmo; quiero entender por qué se considera lectura obligatoria incluso para alguien cuya carrera ya va bastante bien
Me encanta "The Practice of Programming"
De todos los libros de programación que he leído, este es el que me ha dejado las lecciones más marcadas. No lo he releído en años, pero siento que sigue influyendo en mi práctica diaria
Algunos ejemplos de programación concretos sí se sienten bastante anticuados, pero las ideas generales siguen siendo muy sólidas
Me gusta mucho Kernighan. De verdad es una persona muy humilde
En uno de los videos de YouTube contó que en su tesis doctoral estaba resolviendo un problema difícil y más tarde resultó ser un problema NP-completo antes de que la teoría estuviera formalizada
Le mandé un correo pidiéndole la tesis y me respondió bastante rápido; la leí y de verdad me pareció muy interesante
Para mí y para mucha gente, sus ideas sobre programación están entre las más interesantes y útiles, y en gran parte es porque puede transmitirlas con muchísima claridad
Ojalá que hoy las entrevistas evaluaran más la comprensión conceptual que aparece en este libro en lugar de LeetCode
En este nuevo mundo absurdo, hasta Brian Kernighan podría no pasar una entrevista de LeetCode hard
Todas eran problemas de programación bastante prácticos. En Stripe hubo una entrevista en la que tomaron la librería Java Jackson, le metieron un bug en un fork y te pedían encontrarlo y arreglarlo. Era bastante peculiar, pero mucho más cercano al trabajo real de programar
También me recuerda a cuando a Katalin Karikó, que ganó el Nobel por el mRNA, la degradaron en UPenn porque no lograba atraer financiamiento para investigación
Otro autor que entra en una categoría tan destacada como Kernighan y sus libros es Jon Bentley, con sus libros Programming Pearls y More Programming Pearls
https://en.m.wikipedia.org/wiki/Jon_Bentley_(computer_scient...
Este libro le enseña a cualquier programador a pensar la eficiencia desde arriba, con foco en algoritmos y lenguaje
Los libros modernos sobre eficiencia, como los de Agner Fog y Fedor Pikus, tratan sobre todo técnicas de rendimiento a nivel compilador/sistema operativo/procesador, así que leerlos junto con este ayuda a tener el panorama completo
Gente, la g es muda
Estaría bien invitar a Rob Pike. Seguro se tomaría un momento para corregir la pronunciación. Casi puedo oír su voz
También me encantaría invitar a Rob Pike. Ya lo estamos intentando, pero es un poco más difícil contactarlo
Solo vi como un tercio del video, pero se notaba que los conductores hacían preguntas perspicaces bastante buenas
Soy Carter, uno de los conductores del video. Me alegra que lo estés disfrutando. Haber podido hablar con Brian Kernighan fue realmente un gran honor
Como este formato trata libros, creo que estaría bien organizar en la descripción o en algún comentario los libros que se mencionan, y si es posible también una lista de medios
Puse "The Bit Player" (documental de Claude Shannon de 2018) en mi lista para ver, y "Recoding America", "Chip War" y "Endurance: Shackleton's Incredible Voyage" en mi lista de lectura
Estaría bueno agregar también Software Tools in Pascal de Kernighan a la lista de libros para tratar en el pódcast
Tengo ese libro y me parece bueno
Kernighan y Plaugher primero escribieron "Software Tools" en RATFOR, y luego escribieron "Software Tools in Pascal". Y como reacción directa a esa experiencia, Kernighan escribió el ensayo "Why Pascal Is Not My Favorite Programming Language"
Escribirlo en Pascal debería haber sido mucho más fácil que escribirlo en RATFOR, pero no fue así, y Kernighan se puso a pensar por qué
Sigue siendo un texto interesante, y por ejemplo puede leerse aquí: https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
Eso sí, el texto se refiere al Pascal estándar original. Extensiones como Turbo Pascal corrigieron muchos de los problemas. Aunque, como él mismo dijo, no había portabilidad entre extensiones. Aun así, eso se resolvió en parte cuando Turbo Pascal se convirtió en la extensión "estándar" de facto
Me impresionaron las ideas y la escritura, y eso se convirtió en el punto de partida para buscar y leer el resto de las obras principales de Kernighan
Kernighan también es coautor de The Go Programming Language, al menos de la primera edición