Barrapunto

Que lista más divertida, vayamos a comentarla por partes (se nota que últimamente tengo poco trabajo ;)


Problema N1: Programación colaborativa distribuida.
El nóbel de la informática práctica se lo llevará quien invente una metodología sólida para desarrollar código igual que funcionan las redes P2P, dividiendo el trabajo en tareas de no más de 1 hora que puedan ser ejecutadas redundantemente por varios programadores geográficamente dispersos. Por ahora disponemos de herramienta de recogida de requisitos, diseño UML, control de versiones, testeo, bug trackers, etc. Pero los mejores programas (y casi los únicos que funcionan bien) siguen siendo desarrollados por un grupo muy reducido y cohesionado de programadores. No existe un genuino "divide y vencerás" aplicado a la producción de código. A más programadores implicados, menor productividad por programador y menor predictibilidad del resultado final del proyecto.


Esto se podría crear si la especificación fuese totalmente cerrada y no cambiante como son ahora los desarrollos creo yo.


Problema N2: Productividad en el desarrollo de interfaces web.
El uso de HTML y JavaScript supuso un retroceso de 10 años en el estado del arte de las herramientas de desarrollo. Cuando ya teníamos VisualBASIC 4.0 con el cual te picabas una aplicación operativa en 3 días, volvimos a usar diseño con lenguaje marcas que sólo funcionaba bien si lo editabas a pelo con UltraEdit, por no hablar de que el JavaScript ni siquiera tiene un debugger decente. Ahora los frameworks AJAX prometen el oro y el moro. O tienes la opción de casarte con Microsoft .NET. Mi amigo Javier Gallardo incluso dice que a ellos les va bien con Adobe Flex pero con cualquiera de estas cosas te la juegas a quedarte pillado a medio plazo.


Por fin alguien que me entiende¡¡¡, sigo pensando que usar la interface web para hacer programas es una aberración, aunque este de moda, algún día esto cambiara, y espero que pronto.


Problema N3: La temporalidad en el modelo relacional.
¿Porque nadie ha implementado aún un modelo relacional extendido que incluya manejo de la temporalidad? Para poder expresar con naturalidad cosas como que un empleado perteneció a un departamento dado entre tal y cual fecha, por ejemplo. Los históricos y los solapamientos de fechas hay que manejarlos a mano en la base de datos. Lo cual resulta muy engorroso.


Ahora los campos Memo del nuevo SqlServer 2008 ya traen historico de cambios (se puede desactivar), quizá dentro de poco veamos extender eso y llevar un control de cambios de todas las celdas, quien sabe.


Problema N4: La multimoneda.
¿Porqué no existe un tipo moneda que funcione bien en las bases de datos? Me refiero a uno que te permita sumar 3 con 5$ y te dé el resultado correcto en función de un tipo de cambio dado externamente.


Eso si que no, realizar la conversión de las monedas no es tan trivial como aplicar un tipo de cambio. Existen incluso brokers on-line que permiten jugar con la cotización diaria de las mismas y especular con ello. Sumar euros con dolares es como sumar peras con manzanas. La solución pasa por usar una moneda única en la aplicación y convertirlo todo a la moneda final, pero claro, las cotizaciónes cambian y nos encontramos con el problema anterior.


Problema N5: Integridad referencial en los borrados.
¿Cómo borrar algo de una base de datos si infringir las reglas de integridad referencial? En realidad, la solución es simple ¡nunca borrar nada! sino en cambio dar bajas lógicas. Pero entonces ¿porqué no tenemos un procedimiento predefinido para las bajas lógicas?


quizá pase por la solución anterior, guardar historicos de cambios.


Problema N6: Empotrar SQL y XML dentro del lenguaje.
¿Porqué seguimos usando APIs como JDBC? Acaso es tan difícil integrar el acceso a base de datos dentro de la sintaxis de un dialecto de un lenguaje multipropósito como Java. ¿Y porqué hay que seguir usando herramientas como Castor para generar un porrón de clases para leer un simple documento XML? Si XML es un estándar bien definido, incorporar su tratamiento en el lenguaje sería muy útil.


La solución es LINQ, aunque a mi no me acaba de convencer.


Problema N7: Punteros nulos e índices fuera de rango.
La mayoría de los programas escritos en lenguajes modernos siguen estando plagados de punteros nulos e índices de arrays fuera de rango. En Java al menos el recolector de basura te evita las pérdidas de memoria, y existen posibilidades para reemplazar con iteradores todos los accesos por índice. Pero ya sería hora de que existiese un procedimiento formal para garantizar que al menos estos dos errores tan típicos no tumbarán nuestro programa.


Visual Basic solucionaba ese problema con una inicialización automatica, lo cual era una pesadilla porque no te permitia detectar esos errores. Dejemos esos errores que aparezcan por favor, no me gustaría volver al caos de Visual Basic.


Problema N8: Scripts sucios para tareas cotidianas.
Cada maestrillo tiene su librillo, en forma de un puñado de subrutinas y programillas en lenguajes de scripting para cosas rápidas. Lo que se suele echar mucho de menos son herramientas realmente potentes para manipular ficheros de texto y cambiar cosas rápidamente en la base de datos, o generar informes, que es en lo que consisten la mayoría de las operaciones de mantenimiento rutinario de la programación de un sistema.


Los asistentes de los Cristal Report y Reporting Services hacen maravillas, creeme. Por otro lado, PERL es una maravilla en el manejo de expresiones regulares, aunque es complicado, por tanto esas herramientas ya existen, creo yo.


Problema N9: La documentación.
Vale, ahora tenemos Javadoc. Eso fue un verdadero avance. Pero, para documentar el modelo subyacente y la estructura del programa ¿qué usas? Y no me refiero a 4 diagramas UML muy bonitos pero que a la postre no te explican nada de nada en realidad sobre los entresijos del programa.


Este si que es un problemon, la estrategia de Microsoft pasa por la autodocumentación. Por ejemplo, los nuevos WF o Windows WorkFlow Foundation implementa un lenguaje de dominio (XAML) que permite implementar WorkFlows con XML, el cual realiza dos funciones, te genera el código y te genera una documentación chulisima [webinfo.es], de hecho, puedes implementar arrastrando iconos sobre la documentación, aunque es un poco lento y es más rápido teclear todo el esquemita (si te sabes los tags de memoria)


Problema N10: La mentalidad del de arriba.
Una herramienta para demostrar indiscutiblemente al de arriba que no tiene ni idea, que la informática no es la puñetera tienda del todo a veinte duros, donde cualquier cosa puede hacerse para mañana "tocando un poquito por ahí".


Quizá con un relevo generacional donde ponga a los que llevamos desde abajo del todo, un poco más arriba, se solucione el asunto. Tambien influye los enchufismos y todas esas cosas que tanto sabemos en españa.