Parece un chiste, pero no lo es. Acabo e ver el capítulo 9x03 de South Park, donde una mujer china canta ridícula y desafinadamente canciones pop con un falsete insoportable y un acompañamiento que parece la demo de un órgano de $10.

Al final del capítulo hay una placa que recomienda visitar el sitio de Wing, y nos enteramos que ya tiene editados 12 discos y comprobamos una vez más, que la realidad supera a la ficción.

Hace unos días, un ayudante de Algoritmos 3 se quedó horririzado al ver mi remera de Syn/Ack: claro se veían desde lejos los GOTOs típicos del código de kernel. Le expliqué que eran necesarios y que mejoraban la claridad del código, y hasta confesé que los he usado en situaciones especiales, el tipo de argumentos visto en lkml; por supuesto que no lo convencí ni un poquito.

Hoy tuve una discusión similar con compañeros de trabajo, horrorizados porque usaba break para salir de un while, en vez de usar un flag que determine la salida en la próxima iteración. El argumento era que eso está mal en un paradigma de programación orientada a objetos (?), lo que creo que muestra lo peor de la universidad, imponiendo dogmas y no sentido crítico. Por supuesto que nadie se queja de los return prematuros, que son la misma cosa.

Para refutarme, mencionaron al goto como otra cosa que "está ahí, pero no hay que usarla porque es mala, mala, mala". Mi defensa del vapuleado goto los dejó incrédulos de mi ignorancia. Todo esto me hizo ponerme a buscar la opinión de otra gente, y sobre todo, la de los Grandes Maestros.

Terminé leyendo artículos de los 60 y 70, en especial algunas cosas de Donald Knuth y Edsgar W. Dijsktra, que resistieron muy bien el paso del tiempo.

Empecé por buscar el famoso artículo con el cual se inicia todo ataque contra el goto: Go To Statement Considered Harmful -del cual Dijkstra no parecía estar muy contento, a pesar de ser una de los bases de la creación de la programación estructurada (término inventado por él)-. Vuelto a leer, junto con las críticas que recibió y notas posteriores, es razonable en su contexto y -por sobre todo- no me parece dogmático. Creo que el dogma se fue formando a su alrededor, echándole toda la culpa a la herramienta, cuando el problema eran los programadores mediocres; llevando al goto al infierno mismo de la ciencia de la computación.

Buscando otros puntos de vista, me hallé con un artículo de Knuth publicado en el '74 que parece que el mismo Dijkstra recibió bien: Structured Programming with Goto Statements. En él, Knuth hace una defensa razonable y sustentada de la instrucción del pecado, además de escribir la tan citada frase (que en realidad es de Hoare) "We should forget about small efficiencies, say about 97%25 of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%25."

Después de haber "perdido" unas cuantas horas de mi vida leyendo todo esto, me enteré un poco sobre este Holandés tan particular, del que todos podemos aprender bastante. Al viejo Knuth hace rato que lo tengo en el pedestal... Sería bueno que aprendiésemos más de esta gente en la facultad y que hubiese más discusión, pero no veo mayor interés. Al fin y al cabo, uno puede terminar poniendo gotos en un trabajo práctico y justificándo su uso...

Como yapa, siguen algunas citas memorables de Dijkstra que encontré. Esta es para los que van atrás del último grito de la moda:

Testing is a very inefficient way of convincing oneself of the correctness of a program.

Otra:

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, “Dijkstra would not have liked this”, well that would be enough immortality for me.

Un comentario sobre Dikstra, encontrado acá:

Dijkstra's life in the deeper sense was spent in the pursuit of making people think. Making people think through a problem before they put pen to paper. He was popular, but his students sometimes disliked him as much as they--grudgingly one would think-- respected him, because he insisted on handwritten papers and would not accept output from a word processor. His reasoning: by the number of corrections he could see if the person was thinking before they wrote, something he considered an essential skill in programming. So he lived what he taught, and made his students do the same.

Mi notebook (Dell Inspiron 6400) viene con un DVD+-RW SATA, por lo que se usa con la nueva interfaz SCSI. Aparentemente había un bug en el kernel disparado por -al menos- cdparanoia y sound-juicer al tratar de hacer extracción digital de audio (la única manera de escuchar música en esta máquina), que causaba un bloqueo en el bus PCI: freeze total.

Después de dos horas en el teléfono jurándole al soporte técnico de Dell que esto tenía que ser un problema de hardware, encontré la discusión en LKML y el bug report en Debian. Así que ya saben, en etch el único kernel que no tiene este problema es el 2.6.18-3.

La publicidad siempre funciona, de algún modo. Ya tengo las orejas quemadas de tanto oir la promoción de The Who en la radio (Grinbank, me tenés las pelotas llenas, cada vez escucho menos radio).

De modo que me agencié la discografía completa de los ingleses estos; no puede ser que hoy día siga sin haber escuchado a una de las bandas fundamentales del rock. Es raro, nunca pasé de My generation: ni la radio, ni algún amigo que me pase los discos... Resulta que esta semana empecé a conocer a The Who, no vaya a ser cosa que me arrepienta de no haber ido al recital (todavía me lamento por no ir a ver a esos raros de Dead can dance). Y, por supuesto, si voy a meterme en el mundo Who, es necesario ver Tommy, así que anoche me dediqué a verla.

Para muchos será una obra maestra, para mí a Towshend le hacían mal las drogas. El argumento es cualquiera, está filmada de una manera bastante desagradable por momentos (la secuencia de I'm free es triste, con Daltrey haciendo como que corre sobre unos fondos sacados de algún documental) y está lleno de chivos muy evidentes. La sueca Ann-Margret lo hace más llevadero, de tan buena que está.

Acabo de escribir un pequeño HOWTO sobre implementación de políticas de claves de las que se suelen pedir en ambientes empresariales, ya que tuve que hacerlo estos días para cumplir con los requerimientos de una auditoría. Ojalá a alguien le sirva.

Lo pueden leer en el wiki del GlugCEN, tengan paciencia que el servidor es lento :-).