Lo que todo programador de C debería saber sobre el "comportamiento indefinido"

Este ha sido uno de los artículos damnificados por la caída de blogger.com y por eso no lo he puesto aquí antes, pero me gustaría reseñar este What Every C Programmer Should Know About Undefined Behavior 1/3 del blog de LLVM. No solo hace una estupenda introducción al qué y al por qué del comportamiento indefinido en C sino que apunta a una serie de artículos que merece la pena mencionar también: A Guide to Undefined Behavior in C and C++, Part 1, Part 2 y Part 3.

Del primero de esa serie, para que quede claro de qué va el asunto :)

Of course it is physically possible to pick up a basketball and run with it. It is also possible you will get away with it during a game. However, it is against the rules; good players won’t do it and bad players won’t get away with it for long.

Como se puede leer es uno de esos temas que conviene saber (y muy bien) si se pretende hacer código portable. Así que, para leer con detenimiento.

Soy un atento seguidor del blog de LLVM, pero esta vez lo he visto en el twitter de TooManySecrets

Lo mínimo imprescindible para controlar código fuente con subversion

He realizado una presentación para ayudar a un pequeño cursito sobre subversion que voy a dar en breve. Así que publico aquí las transparencias que quizás pueden ser de utilidad para alguien. Está fuertemente inspirado en el manual Version Control with Subversion y concretamente en el apartado del ciclo básico de trabajo con svn con algunos añadidos de gráficos, buenas prácticas, programas auxiliares y algunos enlaces básicos. Por cierto, gracias a Juanjo que le ha echado un vistazo y ha detectado alguna carencia.

Sistemas de control de versiones. Introducción a svn

View more presentations from miguelolivan.

El título de la presentación es "Sistemas de control de versiones. Introducción a subversion" aunque me gustaría más haberlo titulado como este post, "Lo mínimo imprescindible para controlar código fuente con subversion" o como posibles títulos alternativos, dado el público al que va dirigido "Subversion para programadores ocasionales" o "Control de código fuente para científicos". A ver si entre todos podemos hacer que los científicos programen mejor. En beneficio de todos :)

memcpy y la concurrencia

Si el otro día comentaban en barrapunto que en MS marcaban como peligroso el uso de memcpy hoy podemos encontrar otra razón para usarlo con precaución. En memcpy() concurrency curiosities David Dice habla de un comportamiento antiintuitivo de dicha función que sale a la luz en entornos fuertemente concurrentes: sobreescribir la misma secuencia constante en memoria puede tener valores no válidos temporalmente durante su llamada, leídos por otros threads con resultado catastrófico si no se tiene cuidado. Otro caso más en el que las abstracciones que usamos evolucionan a su manera, quizás con explicación pero con resultados que contradicen la intuición y exigen, a veces, conocer que se cuece allá abajo. (No mucho) más en reddit

La misma entrada y más comentarios en memcpy y la concurrencia en barrapunto

Bitácoras de Programación: selección personal

Llego tarde a la discusión generada con la entrada en la bitácora de leonidas en barrapunto que rvr pasó a portada acerca de blogs y feeds en general relacionados con la programación. Salen por supuesto muchos de los agregadores y planetas que consumo, como reddit, hacker news (uhmm, éste no sale), dzone o planeta código. Pero después de leer todas las respuestas me ha entrado la "necesidad" de hacer mi propia selección personal basada únicamente en gustos. Son bloggers que creo que son un poco distintos y, en su mayor parte combinan el bloguerío con un alto nivel técnico que dejan ver el sus posts. Allá van:

• Mbpfernand0's Blog, el nuevo blog técnico de "nuestro" fernand0. El tema fundamental es la programación y la seguridad, aunque creo que no hace ningún asco a temas relacionados. Por cierto, que promete su propia selección de blogs sobre programación. Habrá que estar atento.
• El valle del Viento Helado de Drizzt, el Drizzt de barrapunto también. Sistemas operativos, compiladores, administración y seguridad. Muy interesante.
• .NET o no .NET, esa es la cuestión. Puedes no compartir sus preferencias tecnológicas, pero para mi es uno de los que mejor escribe y destila conocimiento y experiencia por todos los bits.

En inglés:

• intertwingly de Sam Ruby. La web y sus estándares. Para mí, imprescindible.
• jeffr_tech's Journal. Detalles internos del desarrollo de FreeBSD. No actualiza mucho pero merece la pena estar suscrito.
• daniel.haxx.se de Daniel Stenberg. Del autor de curl y Rockbox entre otros, el blog de un desarrollador prolífico.
• Coding Relic de Denton Gentry. Normalmente sobre Software embebido, pero toca otros palos.
• Ulrich Drepper. El blog del mantenedor de la glib. Poco prolífico, pero para no perderse ni una sola entrada.
• Nynaeve: Adventures in Windows debugging and reverse engineering. No se me ocurriría un mejor título nunca
• Y por fin el imprescindible Sutter’s Mill: Herb Sutter on software, hardware, and concurrency

Ahora no se me ocurre ninguno más, pero pueden ser las prisas...

Actualización: He publicado este texto más o menos en un comentario por aquello de completar la información en su sitio. También lo pongo aquí y lo replicaré en mi bitácora en barrapunto, que a su vez se copiará en planeta código, por aquello de que lo que se replica queda y de que hay URLs que desaparecen...

¿Varios pájaros de un tiro?

Vía intertwingly, el blog de Sam Ruby, me encuentro con una cita extraída de una de las listas del W3C que traduzco sin más:

Un error muy común que los ingenieros de software cometen al diseñar una arquitectura es fijarse en cinco problemas, ver lo que tienen en común e intentar resolver los cinco a la vez. El resultado es casi siempre una solución por debajo de lo estándar para todos ellos.

Sí, una tendencia común, más acusada curiosamente en los desarrolladores que se intentan preocupar por la calidad de su trabajo. Para no caer inercialmente en ella habría que evaluar lo económico del desarrollo con lo limitado de las soluciones, algo que demasiadas veces no se hace.

Me ha recordado además a un "cartel motivador" sobre el principio de responsabilidad única que vi hace poco en reddit (Aquí se pueden ver todos los carteles, por si a alguien le son de utilidad :)

Ah, ya que estoy aquí, recomiendo la lectura del blog de Sam y de las listas relativas al HTML5 para ver flames de altura :)


Actualización egórica: A través de una detección automática de referencias Sam se ha enterado de mi enlace y le ha gustado mi referencia al "cartel motivador", que le da más argumentos en el flame. Y me ha enlazado en un comentario. Nunca lo hubiera pensado :)

La misma entrada y más comentarios en ¿Varios pájaros de un tiro? en barrapunto

Epigramas sobre programación

Siguiendo un enlace en technovelty he llegado a un artículo de Alan J. Perlis en el que a través de ciento treinta epigramas trató, en 1982, de capturar algunos de los aspectos más curiosos, desconcertantes y antiintuitivos de la computación en general y la programación en particular. Han pasado más de veintiséis años, pero mucha de su naturaleza creo que sigue intacta. Algunos creo haberlos leído en otra parte y supongo que al que lea esto le pueden sonar, pero me gustan, así que aquí van. Traduzco los que me han parecido mejores:

Epigramas:

7. Es más fácil escribir un programa incorrecto que entender uno correcto.

8. Un lenguaje de programación es de bajo nivel cuando sus programas requieren atención sobre lo irrelevante.

9. Es mejor tener 100 funciones operando sobre una estructura de datos que 10 funciones sobre 10 estructuras de datos.

14. A la larga cualquier programa se vuelve rococó. Después escombros.

15. Todo debería desarrollarse de arriba a abajo, excepto la primera vez.

17. Si alguien parece que está asintiendo cuando le explicas tu programa, despiértale.

19. Si un lenguaje no cambia el modo en el que ves la programación es que no merece la pena.

21. La optimización dificulta la evolución.

31. La simplicidad no precede a la complejidad, la sigue.

40. Hay dos modos de escribir programas sin errores. Sólo la tercera funciona.

57. Es más fácil cambiar la especificación para que se ajuste al programa que al contrario.

58. Los locos ignoran la complejidad. Los pragmáticos la sufren. Algunos pueden evitarla. Los genios la eliminan.

63. En computación, los invariantes son efímeros.

65. No te equivoques: los ordenadores procesan números, no símbolos. Medimos nuestro conocimiento (y control) de una actividad en la medida en la que podemos arimetizar.

75. Debido a su vitalidad la informática está a la busca desesperada de nuevos clichés: la banalidad calma nuestros nervios.

93. Cuando alguien diga "Quiero un lenguaje de programación en el que sólo tenga que decir lo que deseo hacer", regálale una piruleta.

95. No tengas buenas ideas si no eres capaz de responsabilizarte de ellas.

104. La prueba del valor de un sistema es su existencia.

115. Mucha gente encuentra el concepto de programar obvio, pero hacerlo les resulta imposible.

MetaEpigramas:

124. Los epigramas son macros, porque son ejecutados en tiempo de lectura.

125. Los epigramas cristalizan incongruencias.

127. Los epigramas desdeñan los detalles y lo hacen con intención: son una documentación de alto nivel excelente.

El lector atento verá que si se juntan la 8 y la 93 no existen lenguajes de alto nivel. Pero si se mezcla con la 125 ya no está tan claro. Bueno, para pensar un rato. Pero no demasiado, que luego hay que codificar :)


La misma entrada y más comentarios en Epigramas sobre programación en barrapunto

5 Secrets To Ninja Writing

5 Secrets To Ninja Writing. (Vía reddit)

Es mucho más recomendable pinchar en el enlace anterior si conoces el blog de Jeff Atwood, Coding Horror.

Está muy logrado, sobre todo la parodia del abuso de la autorreferencia, un vicio muy de blogstar, muy feo :)

La misma entrada y más comentarios en 5 Secrets To Ninja Writing en barrapunto

Trucos gcc-céntricos y porqué no usarlos

En el estupendo blog Coding Relic el autor, Denton Gentry, ha publicado recientemente dos trucos muy espectaculares pero gcccéntricos. Bueno en realidad uno es específico de la glibc y el otro sí es una extensión de gcc:

• printf-acular en el que se describe cómo personalizar printf para que admita más tipos de datos que los que normalmente admite, en el ejemplo sacar direcciones MAC formateadas.
• Variable Scoping with gcc, en el que se explica el (espectacular) funcionamiento de __attribute__(cleanup), que permite funcionalidades del tipo RAII de C++

Y ahora, después de ver un par de extensiones tan útiles, potentes y elegantes es cuando me toca desrecomendarlas :) Creo firmemente en el valor de los estándares y en desarrollar siempre en el nivel más estricto de estándar o visto de otro modo en el nivel más amplio de disponibilidad, siempre y cuando las soluciones sean comparables. Además, es bueno pensar en la gente que retocará el código y cabe la posibilidad de que si no se documenta resulte de sólo escritura. Yo sólo lo vería admisible en un hack puntual documentado como mínimo con neones. No obstante, hay gente que no opina lo mismo como se puede leer en Uso de extensiones del GCC en (el kernel) Linux.


La misma entrada y más comentarios en Trucos gcc-céntricos y porqué no usarlos en barrapunto

La ley de Postel y los programadores

El otro día leí un comentario acerca de las diferencias en la admisión de parámetros entre los comandos en BSD y GNU. Según se comentaba, los segundos son menos estrictos y se tragan más cosas. El comentarista añadía sobre el comportamiento de la GNU userland: "me gusta a pesar del programador que hay en mi".

Y, por lo que sea, me ha parecido muy revelador: a los programadores no nos gusta, desde un punto de vista egoísta, lo que nos supone la ley de Postel, el principio de robustez. Aquello de ser liberal con lo que se admite como válido da repelús. Y creo que hay más de un motivo:

• Nos gusta la precisión. Si somos estrictos en lo que generamos ¿No vamos a exigir lo mismo?
• Se suele generar más código para tener el cuenta el ser liberal: más trabajo y más testeo
• El comportamiento de nuestro soft no es tan rígido lo que choca con nuestro gusto por las especificaciones precisas, sencillas y breves.

Lo que a veces no vemos es que ser menos estricto mejora la robustez y eso al usuario final, como es normal, le encanta aunque le de igual si se es estricto, si Postel o Dracón, los estándares y todo lo demás.

Este efecto se nota más en ecosistemas heterogéneos con lo que la integración de ese software puede ser más fácil en entornos menos controlados. Así que otra cosa más a pensar antes de desarrollar ¿Nos compensará a la larga el esfuerzo de ser menos estrictos?

La misma entrada y más comentarios en La ley de Postel y los programadores en barrapunto

El código fuente como documento definitivo del diseño

Se trata, cómo no, de Code as Design: Three Essays by Jack W. Reeves. Son unos ensayos muy ilustrativos de la naturaleza particular del desarrollo de software, que por usar la palabra diseño de un modo no usual acaban resultando muy polémicos, pero a mi me parecen más bien esclarecedores. Se recomienda leer enteros antes de opinar :P

Suelo aprovechar cualquier mención para volver a enlazarlo y esta vez ha sido Ricardo Galli en "Los problemas derivados del abuso de las analogías" quien me da la oportunidad de volver a hacerlo :)

Se ha hablado de ellos por aquí en El código fuente visto como diseño y POO, el código como diseño y más cosas.

La misma entrada y más comentarios en El código fuente como documento definitivo del diseño en barrapunto

Las matemáticas 'innatas' en el ser humano

Nota: Para los lectores de PlanetaCódigo. Esta es una entrada sobre ciencia y matemática y no sobre programación. Si no te interesa no tienes más que saltártela :)

Ayer en la cola de pendientes de menéame leí una noticia demasiado escueta que hablaba de niños aborígenes australianos capaces de contar sin números. Rebuscando un poquito encontré la nota de prensa original, que por lo menos es un poco más explicativa.

Y es que este tipo de estudios sacan resultados que al menos a primera vista pueden resultar antiintuitivos: nuestra capacidad matemática parece estar más allá de nuestra capacidad verbal. O dicho de otro modo, parece que la evolución nos ha hecho más viables con un pequeño coprocesador matemático, aparentemente no específica a nuestra especie porque, como decía otro estudio de hace un tiempo, los monos tienen células dedicadas a contar.

También acerca del equipamiento matemático del ser humano se oyó hace un tiempo (quizás Log or Linear? Distinct Intuitions of the Number Scale in Western and Amazonian Indigene Cultures) que las escalas logarítmicas pueden resultar más intuitivas que las lineales a un humano sin formación cultural y/o matemática.

Me parecen muy reveladoras este tipo de investigaciones ¿Conocéis más publicaciones y/o artículos de este estilo? ¿Qué opináis de la relación entre el ser humano y la matemática?


La misma entrada y más comentarios en Las matemáticas 'innatas' en el ser humano en barrapunto

Reescribiendo una cola sin bloqueos

Herb Sutter se quejó en Lock-Free Code: A False Sense of Security(*) de lo difícil que es escribir código sin bloqueos incluso para expertos y lo hizo poniendo un ejemplo de una implementación errónea de una cola. Ahora ha retomado el tema para demostrar como sería una implementación correcta en Writing Lock-Free Code: A Corrected Queue.

(*) Hablamos de este artículo en Varios sobre concurrencia: los peligros de 'Lock-Free' y JVM


La misma entrada y más comentarios en Reescribiendo una cola sin bloqueos en barrapunto

¿Cómo funcionan los cierres de exclusión mutua?

Vía reddit veo un artículo muy didáctico de como funcionan internamente los cierres de exclusión mutua que usamos diariamente y así hacernos a la idea de lo que hay debajo.

La misma entrada y más comentarios en ¿Cómo funcionan los cierres de exclusión mutua? 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

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

La vida privada de volatile

El estándar de C(++) tiene unas cuantas esquinitas. Seguramente volatile es una de ellas. Para aclarar el significado exacto de este calificativo en Coding Relic han publicado La vida privada de volatile, en donde no solo se analiza la letra del estándar sino que se examina el código generado para MIPS en distintos casos.

Conviene recordar los posibles usos de volatile, así como para qué no debe usarse:

• How does the C "volatile" keyword really work? de Ian Lance Taylor. El resumen es bastante claro

  If you are using volatile for anything other than manipulating memory mapped hardware, or for very limited communication between threads, it is very likely that you are making a mistake. Think carefully about what volatile means and about what it does not mean.

• En la misma linea, Volatile: Almost Useless for Multi-Threaded Programming
• Varias discusiones en usenet: C++, volatile member functions, and threads, volatile guarantees? y Memory Barriers, Compiler Optimizations, etc., todas ellas en comp.programming.threads
• Una discusión sobre lo que es, que no es y que quizás debiera ser volatile en Should volatile Acquire Atomicity and Thread Visibility Semantics?, lo que lleva a arreglar el modelo de memoria de C++.

La vida privada de volatile en barrapunto

La aritmética de punteros, su desbordamiento y la seguridad

Me he enterado vía el valle del viento helado de una nueva polémica acerca de gcc y su implementación. El hecho es que gcc cambió su comportamiento en cuanto a comparaciones entre punteros incrementados y ha provocado muchos meses después una alerta de seguridad desproporcionada y según los desarrolladores de gcc, falsa (Se puede oír desde aquí el ruido y la furia)

El caso es que, entrando en profundidad, es una optimización casi "trivial" que hace que p + C1 < p + C2 pase a ser C1 < C2 sin tener en cuenta el posible desbordamiento (overflow) de ambas operaciones. Hay que decir además que el estándar (de C y de C++) declara no definido el valor del resultado de la suma entre un puntero y un entero cuando se sobrepasa el tamaño del objeto al que apunta.

Es muy importante este último punto, porque deja traslucir un error de concepto: la comprobación de overflow propuesta en la alerta(*) es muy burda porque sólo se comprueba el desbordamiento de la operación aritmética, no que nos estamos saliendo del rango permitido. Sin embargo lo que deben saber el programador y el programa a la vez, cuando están manejando aritmética de punteros es cual es el desplazamiento (offset) máximo, de cuanta memoria se dispone. Si eso no lo sabe, es inútil cualquier otra comprobación...

Hay que hacer notar además que la optimización de la que se habla aquí la aplican casi todos los compiladores y lo que provoca la alerta es en realidad el cambio de comportamiento, no que sea incorrecto.

También recuerda esto que es muy mala política basar el código en detalles de implementación específicos de la plataforma. En este caso y en muchos otros, los desarrolladores de gcc tiran de cita del estándar para argumentar sus decisiones. Los usuarios se quejan, llamándoles abogados del lenguaje (language lawyer) pero en momentos como esos hay que recordar que probablemente están defendiendo sus decisiones de implementación y lo importante de esas decisiones para el éxito de una tecnología.

(*)char *buf;
int len;
len = 1 << 30;
if (buf+len < buf){ Overflow }

La aritmética de punteros, su desbordamiento y la seguridad en barrapunto

(Otra) entrevista a Stroustrup

Por si alguien había pensado que me había olvidado de C++0x y de Stroustrup esta entrada viene a demostrar que no :) Uno no tiene porqué estar de acuerdo con Bjarne Stroustrup, incluso puede odiar C++ por las milsetecientascincuetaydos razones por las que puede resultar odioso, pero lo que no se puede negar es que Bjarne ha tenido una gran influencia y sus opiniones son, por lo menos dignas de ser leídas. Algunas de las entrevistas que se le han hecho (incluso alguna que no le han hecho ;) ) me suelen parecer intensas y con elementos para la reflexión.
Pues bueno, en DDJ le han hecho una nueva entrevista. Extractaré lo que me ha interesado (Espero me sepan disculpar que no traduzca esta vez. Si me ha costado más de un mes hacer una nueva entrada no quiero imaginarme cuando publicaría esto con traducción...):

Sobre los distintos paradigmas de programación:

No programming paradigm is best for everything. What you have is a problem and a solution to it; then, you try to map that solution into code for execution. You do that with resource constraints and concerns for maintainability. Sometimes, that mapping is best done with OOP, sometimes with generic programming, sometimes with functional programming, etc.

OOP is appropriate where you can organize some key concepts into a hierarchy and manipulate the resulting classes through common base classes. Please note that I equate OO with the traditional use of encapsulation, inheritance, and (run time) polymorphism. You can choose alternative definitions, but this one is well-founded in history.

Sobre C++0x:

The progress on standard libraries has not been what I hoped for. We will get regular expressions, hash tables, threads, many improvements to the existing containers and algorithms, and a few more minor facilities. We will not get the networking library, the date and time library, or the file system library.

The standard will be finished in late 2008, but it takes forever to go through all the hoops of the ISO process. So, we must face the reality that "C++0x" may become C++10.

C++0x y el multithreading:

The new memory model and a task library was voted into C++0x in Kona. That provides a firm basis for share-memory multiprocessing as is essential for multicores. Unfortunately, it does not address higher-level models for concurrency such as thread pools and futures, shared memory parallel programming, or distributed memory parallel processing.

Consejos para el desarrollo en el mundo real. Me gusta especialmente cuando se recuerda el carácter complejo y casi orgánico de los sistemas (como Richard P. Gabriel en Objects Have Failed):

Think. Discuss with colleagues and potential users. Get a good first-order understanding of the problem domain. If possible, try to be a user of an existing system in that field. Then, without too much further agonizing, try to build a simplified system to try out the fundamental ideas of a design. That "simplified system" might become a throwaway experiment or it may become the nucleus of a complete system. I'm a great fan of the idea of "growing" a system from simpler, less complete, but working and tested systems. To try out all the tool chains before making too grand plans.

Sobre las habilidades que les suelen faltar a los estudiantes:

I saw so many students who simply didn't have the notion that code itself is a topic of interest and that well-structured code is a major time saver. The notion of organizing code to be sure that it is correct and maybe even for someone else to use and modify is alien: They see code as simply something needed to hand in the answers to an exercise.

Vía programming.reddit.

"(Otra) entrevista a Stroustrup" en barrapunto

(Otros) problemas con la memoria y (otras) soluciones

Alguien en programming.reddit hizo una pregunta de esas difíciles: ¿Cómo manejar en un programa en C los casos en los que la memoria se agota? Y digo que es una de esas preguntas difíciles porque depende del tipo de software que estás haciendo, de su criticidad y del nivel requerido de robustez. Ya se sabe, el difícil compromiso de la gestión de errores críticos.

Y como se ve en las respuestas de los redditenses no sólo depende de nuestro sistema, sino de detalles de implementación de más abajo, como suele ser usual en los casos no del todo raros en los que las abstracciones que usamos comienzan a flaquear. En este caso se habla del comportamiento de Linux (el kernel) a la hora de tratar la falta de memoria, que por defecto usa una estrategia optimista que deja reservar (pero no usar, claro) más memoria de la disponible. No obstante este comportamiento se puede cambiar a uno un poco más controlable a través del parámetro overcommit_memory, que se introdujo no hace tanto... El comportamiento por defecto es llamar al OOM Killer que es un método tan drástico como poco predecible. Todo esto esta muy bien explicado en When Linux Runs Out of Memory que vi referenciado por aquí en tiempos de mayor intensidad técnica :)

Además en las respuestas se apunta a un libro online de los que vienen bien cuando las condiciones son más extremas de lo usual: Small Memory Software. Patterns for systems with limited memory. Apuntado en éste mi del.icio.us particular.

(El título es "(Otros) problemas con la memoria y (otras) soluciones " porque no hace mucho escribí Problemas de memoria (y algunas soluciones), sobre el cuello de botella que supone la gestión de memoria sobre todo en sistemas multicore)

"(Otros) problemas con la memoria y (otras) soluciones" en barrapunto

Los usuarios y la primera impresión

Repasando la pila de cosas pendientes de leer me he encontrado con un inspiradísimo Larry O'Brien en una frase que es solo lateral en su razonamiento de que se nota más a los programadores muy malos que a los muy buenos

Medir la satisfacción [para medir la calidad de un desarrollo] es un indicador insuficiente, porque la satisfacción tiende a ser un delta de la última experiencia, no un valor absoluto.

Y es curiosísimo, porque tengo exactamente esa percepción tanto en un lado como en el otro, de programador y de usuario: no importa lo que ocurra posteriormente a un error fatal del sistema; el sistema llevará para siempre ese estigma. Da igual que se corrigiese para siempre, en la siguiente versión. Para no ser absolutamente pesimistas, a nivel interno ayuda muchísimo que exista (y se use) un sistema de seguimiento de incidencias, que esté documentado cuándo, dónde y cómo se producía el problema y cuándo (desde que versión) y cómo se solucionó. A nivel externo... ya digo, un estigma :/ Aunque una labor continuada de comunicación, que tal mal se les suele dar a los desarrolladores, puede ayudar bastante...

Es también por el miedo a que la primera impresión no sea buena por lo que muchos programadores se resisten al famoso release early, release often. Pero no publicar versiones también es fuente de mala imagen, de eso los desarrolladores deben de ser conscientes... Y es que es difícil conjugar el causar una buena impresión con publicar pronto. Yo tengo en esto una política que no sé si es la más acertada, pero es la mía: minimizar la funcionalidad de la primera iteración, limitarla a lo esencial, que sea mínima pero bien testeada. Por cierto, que Joel no está de acuerdo con esta estrategia desde el punto de vista estratégico/comercial/ISV... Mucho que discutir desde distintas vertientes, incluido el modelo de negocio y de desarrollo de software, claro :)

Por cierto que este mismo tema, desde el punto de vista estrictamente estético, fue tratado por Jeff Atwood con un ejemplo muy desafortunado, comparando Frets on Fire con Guitar Hero. No puedo ser imparcial en este caso porque estoy enganchado al FoF en el que uno se puede creer que toca con el teclado como Stevie Ray Vaughan con su guitarra en Texas Flood. Aquí, al menos para mi, es el sonido y no la imagen lo importante :)

Los usuarios y "la primera impresión" en barrapunto