Barrapunto

El problema 1 es coser y cantar si miran en el kernel de linux :-), el problema 6 está resuelto casi desde el principio de los tiempos con la norma "SQL embedded" (para múltiples lenguajes como C) y ahora con esa nueva rueda inventada llamada LINQ, el problema 7 depende del lenguaje pero en Java hay que ser muy retorcido para acabar con una referencia nula. Otros lenguajes como Ada se toman la molestia de volver a poner a NULL los punteros una vez son liberados, el 8 es de alguien que todavía no conoce perl :-P, etc.

En el kernel Linux, efectivamente, hay aportaciones de mucha gente, pero date cuenta de lo que pasó cuando se comprobó que "Linus Torvalds no es escalable": muchos parches (incluso correctamente escritos) se perdían incluso si se enviaban repetidamente. Esto llevó a la aparición de los "lugartenientes", Bitkeeper y git. Y el problema sigue sin estar resuelto. Yo opino que el problema 1 no es un problema de programación, sino de descripción: para poder "tareas de no más de 1 hora que puedan ser ejecutadas redundantemente por varios programadores geográficamente dispersos", como se pide en el artículo, es imprescindible tener una declaración sin ambigüedades de dichas tareas. No necesariamente de su implementación, pero sí de lo que se espera de la misma. Y probablemente hagan falta aún más cosas.

Cambiando de problema, no veo sentido al problema 3: no es un problema específico del modelo relacional (el modelo jerárquico o el modelo en red tienen los mismos problemas) y en la mayoría de SGBDs modernos hay soluciones parciales (como los trigger) bastante eficaces que no requieren estar haciendo el trabajo "a mano".

No sé que pensar del problema 4: ahora va a resultar que el sistema debe conocer todas las monedas del mundo. No, hijo, no. Las monedas que se gestionen en la base de datos estarán anotadas en algún sitio, con su cotización respecto a una moneda de referencia, y basta. ¿Cuántas aplicaciones requieren sumar euros y dólares y sacar el resultado en rublos? Que yo conozca, ninguna: lo que se hace es convertir las dos cantidades a rublos y se suman como tales, que para algo tenemos el punto flotante y/o la precisión arbitraria.

El problema 5, como ya se ha indicado, está resuelto con la reglas de integridad en cascada. Estoy de acuerdo con la conveniencia de tener mecanismos de baja, pero la variabilidad de este mismo concepto según necesidades (sí, se pueden considerar diferentes tipos de baja) dificulta sobremanera una solución general.

El problema 6 adolece de escasez de miras: ¿qué hacemos mañana cuando salga una alternativa a SQL o una revisión de XML? Es muy seductora la tentación de añadir características nuevas al lenguaje, pero esto hay que hacerlo como se ha hecho siempre, con librerías externas. Porque ¿qué versión de SQL metemos? ¿La de la norma? Ya podemos olvidarnos de los desarrolladores que quieren aprovechar (con razón o sin ella) características específicas de un SGBD (Oracle, Mysql, PostgreSQL, Firebird... todos tienen sus idiosincrasias).

De nuevo, el problema 8 busca generalizar algo que es excesivamente específico: ¿Manipular ficheros de texto? Yo pensaba que teníamos cosas como sed, awk o Perl [wikipedia.org], por citar tres opciones más o menos emparentadas. ¿Qué quiere decir "cambiar cosas en las bases de datos"? No sé si se refiere a actualizaciones en masa de registros, modificar las tablas, o qué, pero me da la impresión de que quiere un Haz Lo Que Quiero (y no lo que digo) [wikipedia.org].

Problema 9: si el problema son los modelos, no sirve demonizar a toda la documentación. Quizá al autor del artículo UML no le explica nada, o quizá es que no le han dado UML bien hecho. O BON o algún otro lenguaje/sistema de modelado. Una de las razones por las que los lenguajes de modelado no suelen ser capaces de representar bien la realidad es porque suelen tener reglas de representación, y la realidad no. Como dice la cita, "la realidad es más increíble que la ficción, porque la ficción tiene que tener sen