Beautiful Code

Mi lectura técnica de este verano recién terminado ha sido Beautiful Code. Se trata de un tipo de libro poco común desde mi punto de vista, porque el planteamiento del editor fue «voy a buscar a un tío que me cuente qué trozo de código ha escrito o leído por el que se sienta orgullo o tenga una especial admiración». Y así la friolera de 33 capítulos, treinta y trés.

Algunos de los autores me eran desconocidos totalmente, otros me sonaban y el resto eran de los de toda la vida. Algunos de los capítulos que me han llamado especialmente la atención:

• A Regular Expression Matcher por Brian Kernighan, o cómo hacer un matcher de expresiones regulares con 400 líneas de C. Brillante, aunque no habla de su código sino del de Rob Pike. Además acaba el capítulo proponiendo ejercicios para el lector (el único que lo hace). Además, el tema está bastante de moda, porque parece que todas las implementaciones de los matchers actuales descienden de una implementación con backtracking que no es la más eficiente, porque la cañera, la de hace 30 años de Pike, se perdió en algún lugar.
• Finding Things por Tim Bray. Sobre parsing de ficheros de log con Ruby, la verdad es que un capítulo bastante flojo, pero lo pongo por aquí porque el calavering se ha hecho colega de Tim Bray.
• Correct, Beautiful, Fast (In That Order): Lessons From Designing XML Verifiers por Elliotte Rusty Harold. Interesante relato de cómo hacer dos veces lo mismo (un verificador de XML) te abre los ojos a la hora de tomar decisiones, explicando cómo fue cada una de ellas antes y después. No cuenta la pereza que le dio repetir el curro, que me parece de lo más importante.
• Framework for Integrated Test: Beauty through Fragility por Michael Feathers. Describe su framework (y dale con la palabra) para la ejecución de tests de manera automática. Una patada en el estómago para los ortodoxos radicales de la programación orientada a objetos.
• Beautiful Tests, por Alberto Savoia. O cómo se puede pensar a la hora de intentar que algo no funcione, para escribir el test acorde. Ejemplo, seguido de contraejemplo, seguido de contracontraejemplo. Ilustrante.
• On-the-Fly Code Generation for Image Processing por Charles Petzold. Este capítulo es de los mejores, porque describe cómo en las primeras versiones de windows determinadas operaciones con imágenes en mapas de bits podían lentísimas. El enfoque para arreglarlo fue generar código al vuelo para cada una de ellas. Cuando lo lees te quedas un poco asombrado de la capacidad que puede llegar a tener la gente. Por desgracia, el capítulo habla de una implementación de ejemplo en c# para .Net en vez de la de hace 20 años (de ahí que el capítulo haga referencia a portable ).
• How Elegant Code Evolves With Hardware: The Case Of Gaussian Elimination por Jack Dongarra y Piotr Luszczek. Relata la historia del paquete LINPACK de cálculo numérico y de cómo se ha ido adaptando a los cambios de las arquitecturas HW subyacentes gracias a su diseño. Interesante.
• Python’s Dictionary Implementation: Being All Things to All People por Andrew Kuchling. Diseño cuidado y excepciones para casos concretos en los diccionarios de Python. Es curioso leer cosas así después de haber sido abducido por el sistema de “una forma de resolver el problema y que lo haga bien”.
• Distributed Programming with MapReduce por Jeff Dean y Sanjay Ghemawat. Describen el enfoque de programación paralela que se ha aplicado en los últimos años en Google. Interesante para comprender el concepto y anhelar que Hadoop esté listo para hacer alguna cosilla.
• When a Button Is All That Connects You to the World por Arun Mehta. Te cuenta cómo funciona el sistema que utiliza Stephen Hawkins para comunicarse con el mundo, que consiste en un único botón. Curioso.
• Code in Motion, por Laura Wingerd y Christopher Seiwald. Cómo escribir código que sea visualmente comprensible. Una especie de guía de estilo que va un poco más allá. Por ejemplo, te cuentan que les parece mucho mejor poner las condiciones de un if en líneas distintas, que se entiende mejor sin pensar. Yo les hice caso durante un día o dos durante mis sesiones de tecleo y la fricción cognitiva que me producía el asunto visualmente me impedía pensar.

Los capítulos no mencionados… no significa que no valgan la pena, simplemente que ya no quería escribir más, o que no los iba a resumir todos o que realmente no valían la pena. Hay que tener cuidado, porque efectivamente hay alguno tostón tostón.

En definitiva, un libro a tener de todas todas. Es un libro de ingeniería del software escrito por programadores y no por teóricos y creo que une lo mejor de los dos mundos. Los beneficios del libro se donan a Amnistía Internacional, así que una razón de más.

• programming