Communicating Sequential Processes (CSP)

Hace unos días leyendo una noticia de Slashdot me llamó la atención un comentario en el que se hacía referencia a "Communicating Sequential Processes" (CSP), que según la wikipedia inglesa es un lenguaje de descripción de patrones de interacción en sistemas concurrentes (que dicho así todo seguido suena casi peor...) Según la propaganda ayuda tanto a especificar correctamente el modelo de concurrencia como a verificarlo y depurarlo. Tiene una página oficial, Using CSP en la que se puede descargar el libro Communicating Sequential Processes de 1985 en pdf. Además existen implementaciones para usarlo tanto en Java, JCSP, como en C++, C++CSP. No he tenido tiempo de estudiarlo con tranquilidad, pero lo dejo por aquí por si resulta interesante. Si alguien lo ha estudiado o usado puede ofrecer su opinión al respecto...

La misma entrada en BP

Un vistazo a C++09

Acabo de ver referenciado en OSnews:What's Coming in C++ '09 un artículo que resume las últimas decisiones acerca del nuevo estándar de C++: C++09: A Glimpse into the Future. Como decía Ion Gaztañaga parece que la x de C++0x se despeja: intentarán que sea en 2009. Por lo demás, lo que se viene hablando por aquí, rvalue-refrence, conceptos, deducción de tipos en las inicializaciones (¡que bien!, usar auto, ver "Un vistazo a C++0x" por Bjarne Stroustrup), delegación de constructores...

La misma entrada en BP

Enlaces varios (IV)

En la linea de cantidad sobre calidad, ración de enlaces apresurados:

• What Makes A Programming Language? ¿En que escribimos? ¿Adonde va nuestro código? ¿Son lenguajes? ¿Frameworks? ¿Patrones? ¿Hacia donde vamos? No responde a todo, por supuesto, pero a veces las preguntas son más interesantes que las respuestas ;)
• Miguel de Icaza sobre El pacto de Novell con Microsoft y sobre la liberación de Java. Queda muy políticamente correcto, pero me gusta lo de que esto no es un juego de suma cero. Agitados para él estos últimos días :)
• Patronitis: N. fem. Dícese de la enfermedad propia de programadores que consiste en querer aplicar patrones de diseño a todo.. Una de los síntomas de creer haber encontrado la dichosa bala de plata. Hay quien opina que los patrones de diseño son síntomas de defectos en los lenguajes de programación Bueno, seamos prácticos, usemos lo que tenemos a mano, pero con criterio...
• Recopilación de los mejores artículos de 2004 según Joel Spolsky accesibles en la web Best Software Writing I (la lista de 2005 sigue abierta)
• Behind the Scenes of Objective-C 2.0 ¿También Objective-C evoluciona?

La misma entrada en BP

Análisis estático de código: flawfinder

Gracias a una entrada en el valle del viento helado de Drizzt, "Algunos enlaces de seguridad", he conocido la existencia de flawfinder, un analizador estático de código (C/C++). Te da alertas de código potencialmente inseguro, sobre todo de la utilización de funciones y prácticas con largo historial de vulnerabilidades. No añade nada que no debiéramos saber ya, pero siempre es diferente saber que tal o cual práctica es potencialmente peligrosa y otra es verlo en tu código ;)

Por dar alguna información más acerca de este tipo de programas en la propia página de éste vienen enlaces a otros similares: splint, cqual.... si hubiese seguido la bitácora de fernand0 como se merece, me habría enterado hace un año: " Análisis estático del código fuente y seguridad"

La misma entrada en BP

Concurrencia y librerías reusables

Vía Thinking Parallel: News for Weeks 43 and 44 / 2006 me encuentro con un extenso artículo acerca del impacto de la concurrencia en las librerías: Concurrency and the impact on reusable libraries.

Es algo sabido que el diseño de las librerías debería tener en cuenta si su uso va a ser concurrente. Y debido a que los tiempos están cambiando es muy probable que lo sea. Si nos damos cuenta a posteriori necesitaremos usar muletas :)

La misma entrada en BP

Linux event handling

Escribe Ulrich Drepper en "Linux event handling":

El código multihilo es absolutamente necesario para avanzar. Todos los procesadores crecen horizontalmente, porque tienen cada vez más contextos de ejecución (cores, hyper-threads)

Hace un repaso a los problemas que se encuentran los programadores a la hora de abordar el tema y propone un interfaz de gestión de eventos (para linux) que se adapte a la situación. Algo está cambiando, efectivamente y no sólo en los lenguajes de programación...

La misma entrada en BP

Noticias sobre Ruby 2.0

Vía Lambda the ultimate: Ruby 2.0 News me entero de lo que se va cociendo en el desarrollo de la nueva versión de Ruby, Ruby 2.0. Parece que no va a soportar temporalmente(?) continuaciones ni green threads. Hay distintas visiones sobre el tema: "Ruby Might Be Sucking Less?" (anteriormente titulado "Ruby Sucks?") y Two Excellent Things for Ruby at Microsoft

Actualización: En More on Ruby Implementations se habla de las distintas implementaciones de ruby y de lo que se hace para evitar su balcanización...

Actualización2: Parece que otros no son tan optimistas con esto de las diferentes implementaciones del entorno de ejecución de ruby. En The Impending Ruby Fracture de David Pollak se repasa el tema. Para él, si sigue todo como hasta ahora, dentro de dos años habrá incompatibilidades entre ellos. Espero que se equivoque...

La misma entrada en BP

Entrevista a Ion Gaztañaga sobre C++0x

Andaba yo leyendo un nuevo artículo acerca de C++0x, Ad-Hoc Meeting on Threads in C++ que repasa los temas abiertos para estandarizar los threads en el nuevo C++ cuando, entre tantos nombres ilustres, como Hans Boehm o Herb Sutter nombraban a Ion Gaztañaga y su papel Memory Mapped Files And Shared Memory For C++. Como me ha parecido muy interesante se me ha ocurrido hacerle una entrevista, y aquí está:

P. ¿Puedes hacer una introducción a tu persona y como has llegado a escribir una de las propuestas del C++0x que ahora se debaten para su estandarización

R. Hice una librería para Boost y ahí establecí contacto con Howard Hinnant. Howard, actualmente es el que dirige el grupo de trabajo de librerías (Library Working Group, LWG) del comité de estándar C++ y es realmente una persona muy dialogante y que sabe escuchar las ideas de todo el mundo. Le ayudé un poco con alguna de sus propuestas y de ahí surgió la idea de presentar un artículo propio. Howard me invitó a ir a la conferencia sobre threads y ha sido un auténtico honor estar ahí. Esta semana, el comité está reunido en Portland en sesión oficial y espero estar presente en la próxima reunión que se celebrará en Oxford, el mes de Abril.

P. Las propuestas que se están haciendo para el nuevo C++ ¿las ves todas positivas? ¿cuales te gustan más? ¿y menos? (a mi particularmente me gustan las de los threads, los sockets, las de las expresiones regulares y las incializaciones de contenedores... como escribí en Un vistazo a c++0x por Bjarne Stroustrup y Más sobre C++0x)

R. En general, no hay ninguna propuesta que me disguste, excepto la del Garbage Collector. En mi opinión el garbage collector no encaja en el actual C++ y me chirría bastante. Puede ser debido a prejuicios o a experiencias no muy satisfactorias con otros lenguajes que lo implementan, pero en general, no lo veo necesario y creo que no encaja en la filosofía C++. Pero será un tema muy discutido, sin duda.

Respecto a las demás propuestas, me parece que los threads son esenciales. No tengo conocimientos para evaluar seriamente un modelo de memoria, ya que yo estoy más centrado en estructuras de más alto nivel. En ese sentido, me gusta mucho la propuesta N2094.

También soy un gran fan de rvalue-reference. Creo que solventa un gran problema de rendimiento de C++, que es la generación de temporales, aunque no los elimina completamente. Mi otra debilidad es la propuesta de templates variadicos.

Hay otras propuestas que también me gustan bastante, como los conceptos o los módulos. De todas formas, creo que estas propuestas son menos necesarias que librerías esenciales para usos comunes de programación: funciones de red (sockets), memoria compartida, mapeo de ficheros, manejo de directorios, xml...

P. Crees que los compiladores tardarán menos en implementar estas características que lo que se tardó en implementar el C++98? ¿y los programadores en usarlas?

R. Creo que los programadores los usaran en cuanto estén disponibles. Creo que con la actitud actual de Microsoft de implementar el estandar, la adopción será más rápida que la del estándar C++98. Gcc ya tiene ramas experimentales que implementan templates variadicos, rvalue-reference y conceptos. Metrowerks ya ha implementado rvalue-reference.

P. ¿Crees positivo que un lenguaje se defina a través de un 'comité de estandarización'? ¿qué opinas del estilo 'software libre' de debate/implementación (tipo perl/python)?

R. El estilo "comité" es realmente largo y tedioso. Pero también es una garantía de estabilidad. Me asusta la posibilidad de que como Java, de
una versión a otra se declare obsoleta la mayor parte de la librería estándar. Estos es realmente desastroso para algunos sectores que usan C++, como sistemas críticos de larga duración donde la estabilidad es esencial. Para dar mayor dinamismo, creo que sin Boost, C++ estaría en una situación muy comprometida. El empuje de Boost ha sido clave para recuperar el dinamismo de C++ y creo que C++ está más fuerte que hace
unos años.

El estilo software libre es, en mi opinión, muy interesante, porque es muy dinámico y da buenos resultados e ideas. Creo que no es aplicable a C++ porque necesita una estabilidad mayor, pero podría pensarse en un
modelo híbrido donde se desarrollan librerías y nuevas funcionalidades en un estilo software libre (por ejemplo, gcc es pionero en implementar algunas propuestas) que luego pueden ser estabilizados y estandarizados si se consideran adecuados. Tener una implementación de referencia es muy importante para la estandarización, por lo que no considero ambos
métodos como incompatibles.

P. Añadir tantas cosas al lenguaje y a su librería estándar ¿no es demasiado ambicioso? ¿demasiado complejo?

R. Bueno, más complejo es implementar las librerías estándares de otros lenguajes, porque tienen un tamaño muy grande. Creo que la librería estándar no será un problema porque hay implementaciones libres como Boost que las empresas pueden usar y adaptar para su propio producto. El tema del compilador es más complejo, pero creo que el cumplimiento del estándar se ha convertido en un tema esencial para los usuarios del compilador. De hecho, este deseo de los usuarios fue lo que forzó a Microsoft a implementar el estándar.

P. Parece que una gran parte de las nuevas características van en la linea de aumentar la portabilidad entre sistemas ¿se conseguirá realmente facilitar la vida al programador en esa faceta?

R. Creo que vamos en el buen camino. Los threads serán una muestra de ello. Para el conjunto de librerías TR2, se va a proponer una librería de red, basado en Boost.Asio, que es un tema esencial, en mi opinión para la credibilidad de C++. Quedan todavía funciones como lanzamiento de procesos, comunicación entre procesos, mapeo de ficheros en memoria y otros.

P. ¿Qué opinas de C++/CLI?

R. No lo he usado, porque trabajo principalmente en aplicaciones portables ANSI C++. No me gustaría que fuera un nuevo episodio de "abrazar, extender y exterminar" de Microsoft y creo que la presencia de Herb Sutter ha sido vital para un trabajo leal entre ambos estándares. Así lo han manifestado muchos miembros del comité. Pero creo que no ha conseguido su objetivo de "revolución". Primero apostaron por C# y luego han cambiado a C++/CLI. La limitación de su portabilidad, ya que es un sistema basicamente Windows (Mono es una opción, pero no creo que pueda seguir el ritmo de Microsoft) hace que no sea interesante para mí.

P. Cuando se estandarizará C++0x? (en tu opinión) ¿cuando sabremos que número es la equis? :)

R. No tengo ni idea ;-) La intención es que sea C++09, pero prefiero que sea un buen estandar que incluya threads y otras propuestas que un estandar que salga antes pero no incluya esto. Mientras tanto, siempre está Boost.

Sólo me queda darle las gracias por su amabilidad así como por la cantidad y calidad de sus respuestas.

La misma entrada en BP

Diseño sencillo contra implementación correcta

Diseño elegante y sencillo frente a implementación correcta. No siempre están enfrentados, pero muchas veces si.

El tema me ha surgido leyendo un blog muy interesante, Thinking parallel, en el cual se discute si los mutex recursivos son buenos o no, que apunta a un excelente post en comp.programming.threads Recursive mutexes by David Butenhof. Las dos tesis contrapuestas son:

• Los mutex recursivos son buenos, porque ayudan a modularizar y a abstraer (diseño elegante y sencillo)
• Los mutex recursivos son malos: Del post de Butenhof:"Un diseño correcto y bien pensado no requiere mutex recursivos" (implementación que puede ser no correcta)

Lo cierto es que la tesis de Butenhof está muy bien argumentada y nos da pistas de cuando estamos haciendo las cosas mal:

El problema más grande de todos los problemas de los mutex recursivos es que animan a perder la pista de tu esquema de bloqueos y su ámbito (scope). Esto es mortal. Nefasto. Es el "comedor de threads". Has de coger los mutex durante el tiempo más corto posible. Punto. Siempre. Si estás llamando a algo con un mutex cogido es porque no sabes si está cogido o porque no sabes si la llamada lo necesita, entonces lo estas cogiendo demasiado tiempo.

Abstrayendo... ¿Que caracteriza (entre otras cosas) un buen diseño?

• No se repiten conceptos (fácilmente modificable)
• Es elegante (desde lejos, desde arriba, a nivel de relación entre objetos, módulos ...)
Es sencillo (en lo posible, para no complicar o entorpecer la implementación)

¿Que caracteriza (entre otras cosas) una buena implementación?

• No se repite código (mantenible)
• Es elegante (el código, de cerca, a nivel de función)
• Es correcto
• Es óptimo

Entre la sencillez del diseño y la optimización y corrección de la implementación es donde suele haber más problemillas. En lugar de rediseñar cuando se detectan errores de rendimiento el camino más fácil son los hacks, que cuando no son excelentes suelen embarullar el código y distorsionar el propósito del diseño.
En estos casos no habría que tener miedo de refactorizar el código y rediseñar si es preciso, aunque en un caso ideal habría que haberlo tenido en cuenta antes, como requisitos no funcionales, pero sin caer en la sobreingeniería. Difícil verdad ;)

Se podría decir que los mutex recursivos son un hack y por ese motivo usarlos con mucha precaución. Como dice el propio Butenhof (extensible a todos los hacks)

Los mutex recursivos son un hack. No hay nada erróneo si se usan, pero son una muleta. ¿Tienes una pierna rota o una librería? Bueno, usa una muleta. Pero al menos sé consciente de que la estás usando y porqué.

La misma entrada en BP

Programación y mantras

Todos tenemos los nuestros. Bueno, igual todos no. Pero es útil a veces recurrir a mantras, adagios, frases... esto de la programación es un arte, una intuición, una ciencia, un camino hacia la iluminación.. :) en ese camino nos ayudarán dichos que condensan la sabiduría de nuestros predecesores. Frases que sobre todo te avisan de los peligros, que te recuerdan que debes estar alerta y no caer en un descuido, un error de diseño o implementación que deberás mantener y hacer compatible hacia atrás ;)
Un repasillo a las que más me gustan:

• KISS (Keep it Simple Stupid!, mantenlo simple, estúpido)
• DRY, Don't Repeat Yourself, no te repitas
• No hay bala de plata
• Elige la herramienta adecuada a cada tarea
• Las variables (y clases) son sustantivos, las funciones (y métodos) verbos
• Si no está probado, no funciona (If it's not tested, it's broken)
• No escribiré un Daily WTF ;)

Lista actualizada:

• Libera pronto, libera a menudo

Lista actualizada(2):

• Chequea las entradas
• Los fallos, cuanto antes mejor (Fail Fast)(esta más controvertida...)

(Se admiten sugerencias para completar la lista...)

Se pueden encontrar más recomendaciones breves en la lista de reglas de "The Pragmatic Programmer" (libro por cierto muy recomendable)
Ahora sólo hay que ser lo suficientemente listo para saber aplicarlas correctamente ;)

(Actualización: Gracias a Juanjo-Blackshell por el meneo en Menéame: Programación y mantras ;))

La misma entrada en BP