Querido Ndugu,
Una profesora que tuve durante mis años de universidad dijo una vez algo como:
Yo lo siento, chicos, pero a programar se aprende programando.
Tengo que admitir que la frase me gustó tanto que la he utilizado alguna que otra vez en las clases de presentación de asignaturas de laboratorio.
Sin embargo, también creo que hay otro aspecto importante para aprender a programar: ver código de otros. De esta forma, puedes salir de tus vicios y defectos viendo como otra gente resuelve distintos problemas, qué estilo utilizan, etc. Es como jugar al squash con alguien distinto a los cinco con los que siempre juegas. Ves cosas nuevas, golpes nuevos, distintas formas de moverse en la pista, que te sirven para refinar tu propio estilo.
El libro que hoy comento fue escrito nada menos que por Brian W. Kernighan y Rob Pike. 
Lo que hace es plantearse ciertos problemas y resolverlos en distintos lenguajes, explicando qué cosas están mal hechas (y por qué), y cómo pueden mejorarse. Muchos de los problemas planteados son experiencias vividas por los propios autores en su trabajo diario, por lo que se incrementa la credibilidad de los mismos y su relevancia, de tal forma que el lector toma plena conciencia de por qué una determinada solución es mejor o peor que otra.
Uno ya tiene demasiados años de programación a sus espaldas como para descubrir/aprender cosas nuevas, pero el texto es recomendable para estudiantes de programación que quieren cubrir la parte de “ver código de otros” sin tener que recurrir a bucear en el código de algún proyecto de código abierto.
Bueno, sí, he aprendido una cosa que me gustó. En uno de los ejemplos que desarrollan tienen una lista enlazada de elementos, y necesitan implementar una función que elija aleatoriamente uno de ellos. La función recibe la lista, pero no conoce, a priori, el número de elementos que contiene… ¿cuántos recorridos sobre la lista son necesarios? La respuesta obvia es uno para contar los elementos, y otra para encontrar el elemento i elegido con un random. En el libro implementan un método que requiere un único recorrido. ¿Se os ocurre como?
Como nota negativa, tengo que decir que el libro es un poco antiguo. Los ejemplos están en C (no podría ser de otra manera, estando Kernighan entre los autores…), aunque también han añadido código en Java e incluso Awk (tampoco era difícil… la K de AWK es de Kernighan…). No obstante, los distintos lenguajes no ayudan a olvidar esa “antigüedad” que se respira durante todo el libro, debido a que muchos de los ejemplos y experiencias datan de los años en los que el PC era una cosa rara. Además casi todos ellos están relacionados con Unix, algo que los estudiantes de hoy en día a los que aconsejo el libro puede pillarles un poco lejos.
Nota: recomendable
Macho, a mí lo que me acojona es eso que dices de que has seguido aprendiendo trucos nuevos en el squash.
Creo que, cuando vuelvas, vamos a tener que atarte las piernas para poder ganarte.
Ya llevas 19 libros y los que te quedan, ¿cómo te da tiempo a leer tanto?