Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM

Ración de varios sobre concurrencia:

• "Lock-Free Code: A False Sense of Security" de Herb Sutter que viene a decir algo que por aquí intuíamos:

  [Lock-free code is] hard even for experts. It’s easy to write lock-free code that appears to work, but it’s very difficult to write lock-free code that is correct and performs well. Even good magazines and refereed journals have published a substantial amount of lock-free code that was actually broken in subtle ways and needed correction.

  es decir, entre otras cosas, recordar ser humildes.
• Si aún siendo humildes queremos saber más sobre estos temas podemos echarle un vistazo a "Just What-the-Heck is a 'wait-free' algorithm?" de Cliff Click en el que repasa este tipo de algoritmos que según los que saben de ésto aún son más difíciles de codificar que los 'lock-free' (son un subconjunto de ellos no obstante)
• The Java Memory Model in 500 Words Un breve resumen, casi chuleta, del modelo de memoria en Java.
• Si lo que nos interesa son más las implementaciones que las especificaciones podemos echar un vistazo a The Hotspot Java Virtual Machine, una completa presentación con detalles de implementación de dicha máquina virtual. Repasa compilación, sincronización, recolección de basura y posibles direcciones de investigación.

La misma entrada y más comentarios en Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM en barrapunto

Sobre los aspectos estéticos de la programación

Jonathan Edwards en una entrevista en un webzine de reciente creación, Wheel Me Out, ha tocado uno de los temas que le hacen a uno seguir teniendo pasión por esto de la programación. Cito (traduciendo) lo que más me ha gustado(*):

Veo la programación como una actividad profundamente creativa, pero no exactamente como una forma de arte en el sentido usual del término. Los programas no expresan sentimientos humanos entonces no creo que tengamos derecho a llamarlos arte. Los programadores desarrollan cierto sentido estético que hace de un programa bien diseñado un programa bonito, pero es una clase de belleza fría y matemática. De hecho sostengo que la estética puede ser una mala guía para los programadores.

[...]

La belleza de la programación es intelectual. Es el placer que sentimos cuando un problema complejo de pronto se revela bastante simple visto desde la perspectiva adecuada. Esta sensación de profundidad es la que motiva a algunas personas a ser matemáticos o físicos. [...] Programar es también un tema de poder. Es la lucha del programador para crear orden del caos. Somos como pequeños dioses en nuestros universos de bolsillo. Estamos limitados solo por nuestra imaginación. Desgraciadamente nuestra imaginación es más limitada de lo que nos gusta admitir, lo que en mi opinión es el trágico defecto de la programación, aunque esta opinión no es compartida ampliamente.

Obviamente, se resalta el aspecto más sublime, cuando todos los que nos dedicamos a esto sabemos que el día a día puede ser bastante distinto, bastante poco elevado. No obstante, en lo que a mi respecta me sigue enganchando la posibilidad de simplificar lo complejo, de encontrar una buena solución y el poder de hacerlo en el universo de bolsillo :)

(*)Pedí permiso para traducirlo íntegramente y me pidieron la dirección del blog. No me contestaron después. Espero que me ampare el derecho de cita...(Actualización: desde Wheel Me Out me han dado permiso para traducirlo, pero creo que con el extracto ya traducido será suficiente. Gracias al webzine de todos modos por el permiso y por generar la entrevista)

La misma entrada y más comentarios en Sobre los aspectos estéticos de la programación en barrapunto

Varios sobre D

Se acumulan cosillas sobre D que me he ido guardando, así que, haciendo un dump:

• El enlace que me ha hecho juntarlos todos: "Grafting Functional Support on Top of an Imperative Language - How to D 2.0 implements immutability and functional purity" de Andrei Alexandrescu. Muy interesante aunque no se vaya a usar D ni programación funcional por aquello del manejo de los invariantes y su aproximación a la concurrencia, además de hacer notar las "limitaciones" del const de C++. Más en reddit.
• The A-Z of Programming Languages: D, entrevista a Walter Bright, el creador de D, extendida en reddit con respuestas del propio Bright, asiduo por esos lares.
• También vía reddit, D Postmortem, en el que se analiza los problemas que se encontró un usuario de D en un proyecto no trivial. También tuvo muchas respuestas en reddit, algunas también del equipo de desarrollo de D, Bright incluido

La misma entrada y más comentarios en Varios sobre D en barrapunto

Bugs antiguos y moralejas

A veces coinciden en el tiempo sucesos de los que se puede sacar una especie de moraleja común y la serie reciente de errores con muchísimos años de historia me parece una de ellas. La grave vulnerabilidad en el protocolo DNS, que ha hecho actualizar a toda internet ha sido el ejemplo más claro, pero no el único y las tres historias son muy instructivas...

El primero, hace unos dos meses detectó un bug de 25 años en los BSD, en seekdir()[1] en el que, en algunos casos seekdir() no daba el resultado correcto. Como comentan en la propia historia, un bug muy difícil de encontrar y muy fácil de corregir.

El segundo es un bug con 33 años de antigüedad en yacc, encontrado por Otto Moerbeek[2], quien curiosamente también ha tenido un papel muy relevante en el descubrimiento del bug anterior.

El último es más peliagudo: problemas de diseño en el protocolo DNS permitían a un atacante hacer DNS cache poisoning de modo más efectivo que anteriores técnicas[3]. El descubridor de la vulnerabilidad, Dan Kaminsky, hace comentarios muy interesantes al respecto (las negritas son mías):

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that's no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got "lucky" here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don't have any information about. And so we are deploying this excellent design to provide no information.

Es muy curioso seguir los enlaces, porque la historia del parche es muy poco común y puede enseñar de la parte técnica y de la parte social del ecosistema internet.

Creo que la moraleja de todos ellos es clara, sobre todo leyendo las historias. Pero por recopilarlas (aún a riesgo de decir obviedades):

• El DNS o SMTP son protocolos pensados para una Internet que ya no existe: ninguno de ellos se diseñó pensando en la seguridad.
• Que lleve muchos años funcionando no significa que funcione en todas las circunstancias.
• Si se va a usar un software de un modo poco usual, aunque sea uno muy estable, conviene prepararse mentalmente para encontrar bugs.
• Los errores de diseño son más difíciles de arreglar (si es posible)
• Un buen diseño sobrepasa las expectativas del diseñador.
• Abierto no implica seguro, ni libre de fallos (Cerrado tampoco, claro[4])

[1]Un buen resumen en castellano, con interesantes conclusiones en El valle del viento helado "Un bug de 25 años en los BSD: seekdir()"
[2]Comentado en barrapunto en Corregido un error de hace 33 años en Yacc
[3]Comentado en barrapunto en Un agujero de seguridad en el protocolo DNS causa gran alarma
[4]Me ha llamado la atención el caso de un bug casi trivial en el en interop de .NET desde C++ nativo que lleva la menos seis años sin ser resuelto. No es el único caso ni el más grave ni la única empresa donde sucede eso, por supuesto. Sólo me ha parecido un ejemplo ilustrativo...

La misma entrada y más comentarios en Bugs antiguos y moralejas en barrapunto

Parámetro "lo digo en serio" en Content-Type para IE8

Pues esa es la propuesta que se puede leer en el blog de desarrollo del Internet Exporer 8: añadir un authoritative=true al Content-Type, o sea, fiarse de cual es el tipo de contenido que está proporcionando el servidor, pero sólo si lo dice en serio...

Por supuesto esta propuesta ha levantado bastantes reacciones. Unos, como Sam Ruby en authoritative=true, lo ven desde el punto de vista pragmático como un mal menor al evitar content-sniffing. Otros, como Daniel Stenberg en This is the type and I mean it se lo toman con humor. Más en las listas de la w3c y en reddit: Microsoft's "I mean it" content-type parameter

La misma entrada y más comentarios en Parámetro "lo digo en serio" en Content-Type para IE8 en barrapunto

Lenguajes de la A a la Z: Entrevistas

En Computerworld están publicando extensas entrevistas acerca de un montón de lenguajes de la A a la Z. La verdad es que había visto alguna referencia, pero después de la de Stroustrup (y sus repercusiones en Slashdot y reddit) le he prestado más atención y parece que pueden ser bastante curiosas. También en LtU - The A-Z of Programming Languages prometen seguirles la pista, enlazando a su vez a las pasadas:

• Ada - S. Tucker Taft
• ASP.NET - Microsoft
• AWK - Alfred V. Aho
• Bash - Chet Ramey
• C++ - Bjarne Stroustrup
• Forth - Charles Moore (Actualizado (27/06/08) -No creo poder seguir el ritmo de actualizaciones ;)-)

Actualización: La entrevista a Stroustrup también se comenta en la portada de barrapunto

La misma entrada y más comentarios en Lenguajes de la A a la Z: Entrevistas en barrapunto

Propuesta para introducir C++ en gcc

Volviendo al tono un poco menos noticioso de esta bitácora, me gustaría referenciar la propuesta de Ian Lance Taylor de permitir determinadas características de C++ en el código de gcc, sobre todo aquellas que permiten hacer el código más compacto y mantenible. Nombra explícitamente STL, polimorfismo y punteros inteligentes en contraposición a la recolección de basura que se usa en gcc. Hay que hacer notar que la propuesta debería ser aprobada (no sin antes haber pasado por el adecuado flame C vs C++) aunque Ian propone crear una rama gcc-in-c++ para experimentar.

Me ha parecido una propuesta muy razonable, con una exposición muy clara de lo que se ganaría con el cambio. Es precisamente el (moderado) uso de las características de C++ lo que me ha parecido más reseñable. C++ es un lenguaje grande y no todas son adecuadas a todos los problemas, con lo que hay veces que es sano delimitar como se usa. Esto da lugar no obstante a estándares de codificación con casi obsesivo nivel de detalle, pero de los que se puede aprender si se lee con atención crítica.

Por cierto que para evitar dependencias indeseadas (y que C++ se convieta en el caballo de troya que potencialmente es) se propone un enlazado estático con la libstdc++. No sé que opinará Ulrich Drepper.

Se puede leer más sobre el tema en el propio blog de Ian , en reddit (posteado por un servidor), en LWN y (con poco éxito de crítica y público) en menéame.

La misma entrada y más comentarios en Propuesta para introducir C++ en gcc en barrapunto

Reddit abre su código

Reddit, el sitio colaborativo de promoción de enlaces, que cuenta con una gran sección de programación, ha abierto su código, disponible en code.reddit.com. La licencia elegida ha sido la Common Public Attribution License (CPAL)

La misma entrada y más comentarios en Reddit abre su código en barrapunto

code_swarm: visualización del desarrollo de proyectos libres

Acabo de ver vía slashdot (y me lo perdí en reddit) un proyecto de visualización del desarrollo de proyectos libres: code_swarm. A partir del control de fuentes genera vídeos en los que se puede seguir la evolución histórica del desarrollo de Python, PostgreSQL, Eclipse o Apache httpd. El autor promete además liberar el código para que cualquiera lo pueda aplicar a otros proyectos. Bonito, hipnótico y hasta revelador...

Actualización: Ya ha liberado el código en codeswarm - Google Code. A disfrutar...

La misma entrada y más comentarios en code_swarm: visualización del desarrollo de proyectos libres en barrapunto

Elizabeth Loftus y los recuerdos falsos

Vía El psicoanálisis ¡vaya timo! de El cerebro de Darwin me he encontrado con los estudios de Elizabeth Loftus acerca de un tema tan atractivo como los recuerdos falsos. En particular hay un buen resumen en "Our changeable memories: legal and practical implications". Me quedo con la cita de Eduardo Galeano a modo de resumen (que no he podido encontrarla en castellano, la traduzco de la traducción :\)

La memoria nace cada día, brotando del pasado y contraponiéndose a él.

La misma entrada y más comentarios en Elizabeth Loftus y los recuerdos falsos en barrapunto