El arte de la programación en Unix

Ya les habrá pasado a muchos con algún libro en particular que lo ven interesante y no lo terminan leyendo por alguna razón.

Yo ya había leído "La Catedral y el Bazar" del mismo autor, por lo que no entiendo como lo dejé pasar por tanto tiempo; hace ya varios años que sabía de la existencia de este libro.

Lo estoy leyendo justo ahora, y siento como si hubiera perdido muchos años de mi vida. De casualidad hoy un amigo me contacta por IM (Instant Messaging) para decirme lo "Gratificante que resulta programar en Linux" y pensé que el debe estar sintiendo lo mismo que yo pero en peores condiciones, porque el debe estarse diciendo a si mismo: "Tantos años perdido programando a la Microsoft", al menos yo superé eso bien temprano.

Voy a penas por el capítulo 3, y me vienen a la cabeza tantas cosas. De hecho me provocó agarrar los libros de Tanenbaum (Arquitectura del Computador, Sistemas Operativos, Redes de Computadoras) y comermelos completitos; incluso pensé que el futuro de la cultura hacker depende de su participación en los dispositivos de manos (celulares, pda, etc)[1] y que debería apoyar alguna de las muchas iniciativas que ya existen en este sentido (releyendo esto, me doy cuenta del porder que tienen estos GURUS de la cultura hacker para lavar cerebros).

Para darles un gustaso, deleitesen con estás máximas de la programación de Unix que Raymond sintetizó para este libro basandose en otros Gigantes:

1. Rule of Modularity: Write simple parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Composition: Design programs to be connected to other programs.
4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
8. Rule of Robustness: Robustness is the child of transparency and simplicity.
9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
10. Rule of Least Surprise: In interface design, always do the least surprising thing.
11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
16. Rule of Diversity: Distrust all claims for “one true way”.
17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

[1] En el capítlo 2, sobre las lecciones de la Historia de Unix, una de ellas dice:Never bet against the cheap plastic solution. Or, equivalently, the low-end/high-volume hardware technology almost always ends up climbing the power curve and winning. The economist Clayton Christensen calls this disruptive technology and showed in The Innovator's Dilemma [Christensen] how this happened with disk drives, steam shovels, and motorcycles. We saw it happen as minicomputers displaced mainframes, workstations and servers replaced minis, and commodity Intel machines replaced workstations and servers. The open-source movement is winning by commoditizing software. To prosper, Unix needs to maintain the knack of co-opting the cheap plastic solution rather than trying to fight it.En otras palabras, que el sistema que a más personas llegue, le ganará a sus competidores.