Barrapunto

La verdad es que leyendo el artículo en más profundidad, creo que el que lo escribe no es para nada un experto, o al menos a mí (que tampoco lo soy) no me gusta mucho su metodología:

Problema N2: Productividad en el desarrollo de interfaces web.
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.

Para empezar, no me gusta la filosofía de "picarte" una aplicación en 3 días. Por esa filosofía, y la del Visual Basic en sí, te encuentras las barbaridades que te encuentras por ahí.

¿El lenguaje de marcas sólo funciona si te lo editas con el Ultraedit? También valdrán otros, ¿no? ¿O te refieres a no poder dibujar directamente las ventanitas?

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?

Porque el borrado lógico no te va a solucionar los problemas de integridad referencial. El día que los gestores implementen el borrado lógico, y le hagan pasar por las mismas restricciones que el físico, su manejo será igual de complejo. Lo único que cambia es la posibilidad de recuperación.

Esto me hace pensar que este tipo, para evitar comprobaciones de integridad, se contenta con poner el campo de borrado a 0. Para eso no uses claves externas.

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.

Las clases de acceso a bases de datos son estándar, ya están incluidas en java. Lo que tú tienes que añadir es la biblioteca que implementa el acceso. Obviamente los desarrolladores de los javas no pueden implementar todos los accesos a cualquier gestor de bases de datos, porque sería un trabajo titánico, y porque no creo que muchas estén dispuestas.

También tendría cosas que objetar al resto de párrafos, pero estos son los que veo más claros, y tampoco voy a hacer un comentario más largo que el de la Manesa.

Estoy de acuerdo contigo. No es un maestro.

El problema N2 y hablando sólo de diseñar la interfaz se debe a que las aplicaciones de ejecución local están preparadas para correr en una máquina con un bus de datos muy veloz y aunque el programa diseñador de la interfaz genere código extra porque el diseñador humano ha pulsado varias veces el botón que no debía, la pérdida de rendimiento por ejecutar cosas inútiles no se nota demasiado al ejecutar la aplicación.

En cambio en aplicaciones web el "bus de datos" es la línea telefónica que es bastante limitada en velocidad y la carga de la página tarda lo suyo si el código de la interfaz no está optimizado y hay marcas redundantes (La nueva web del congreso es, o era, un buen ejemplo).

Ahora que cada vez tenemos más ancho de banda se puede empezar a desoptimizar la generación del código web con programas que automaticen y reduzcan la tarea de creación de la interfaz si esto mejora su velocidad de desarrollo y por ende el precio de las aplicaciones aunque en mi opinión por donde habría que tirar para aplicaciones remotas es en protocolos tipo X que permitan enviar al cliente sólo las partes de la interfaz que cambien y dejar el HTML sólo para documentos de hipertexto. Pero claro, con la de recursos invertidos en tecnología web no veo claro que alguien saque un protocolo nuevo y el mundo se vuelque en él. Igual con las iniciativas de Adobe y Microsoft sobre interfaces ricas a través de http veamos un cambio o quizás salga un churro peor que lo que hay ahora.

Sobre el problema 5 acerca de la integridad referencial, no en todos los casos tendrían las mismas restricciones que un borrado físico. Te pongo un ejemplo:

Una BD en la que se almacenan en las tablas los usuarios que modifican cada uno de los registros. Si en algún momento un usuario causa baja, utilizando un borrado lógico se seguiría manteniendo la integridad.

¿Pero este tío no ha oido hablar del delete on cascade? Problema 11, la falta de cultura.