estebanlm

Java ya fue

Y... son demasiados problemas: que si el application server, que si las excepciones son unhandled, que si hay que poner una capa para aislarse de otra capa que se aisla de otra capa, que si esto lo tengo que hacer en jsp con taglibs, en jsf o tapestry y que pongo una capa entre el cliente y el servidor, y la configuro con xml, usando spring o lo que sea. Y si tengo que pensar en el acceso a datos y entonces necesito una capa de DAOs que me maneje el acceso a los mismos. Ni hablar de que el modelo de datos hay que mapearlo, con xdoclets o annotations y como estoy transformando una base relacional en un modelo de objetos tengo varias complicaciones extras; y ya que hice el mapeo y tengo un modelo, mejor hago unos controllers o managers para meter la logica de negocio, así no se me mezcla con los mapeos, aunque, claro, con eso deje en la practica de programar a objetos. O le pongo un "aspecto" que me maneje los logs o la auditoría, aunque con eso este no solo abandonando OOP (que no sería malo, si me diera una ventaja) sino que este volviendo, casi, casi, a los GOTOs que siempre dijeron que eran pésimos.
En fin, son demasiados problemas. Y todavía no empecé a hablar del problema real que tengo que resolver, por el cual me pagan.
¿Cuanto tiempo pasa además, con todo este quilombo a resolver antes de poder mostrarle al cliente algo en lo que pueda reconocer que estamos trabajando para resolver su problema?
Es evidente que hay que solucionar este quilombo o no vamos a lograr nunca tazas de productividad razonables.
Lo primero que uno pensaría es: ¿Y si hacemos las cosas en .Net?
El problema es que .Net tiene el mismo tipo de concepto. Y aunque haya menos fwks a escoger, de cualquier forma son muchas cosas, y muchas capas.
Podemos, entonces, avanzar un poco estandarizando la arquitecura de una aplicación java: limitamos las posibilidades, pero ganamos en startup. Barbaro, avanzamos un poco. Pero el problema sigue estando, sigo teniendo que manejar un monton de cosas, antes de poder resolver el problema de negocios.

En este momento, tenemos un panorama similar en ambos mundos, .Net y Java.
Y no estamos un ápice mas cerca de encontrar una solución.

A partir de la llegada de Java 6 (que incluye groovy en su especificación) y del hecho de que lenguajes dinámicos como ruby o python han ganado algo de "momento" me hice la pregunta: ¿Y si es el momento de empezar a pensar en el próximo paso?
¿Y cual sería este próximo paso?
Bien, evidentemente, el universo de problemas que quiero resolver me indica para donde tengo que empezar a pensar... los lenguajes dinámicos permiten un acceso más rápido a la construcción y, bien usados, permiten encarar algunos de estos problemas fácilmente.
Como todo nuevo comienzo es una vuelta a las raices, terminé con el primer lenguaje dinámico existente, y con el primer lenguaje realmente orientado a objetos: Smalltalk.
Y tomé Squeak y empecé a jugar... no se puede tener una opinión concluyente, pero creo que voy a empezar a escribir sobre la experiencia al respecto, sobre todo porque hay muchos prejuicios preestablecidos que es preciso comabatir, o corroborar (no se puede hacer algo realmente productivo con esto, es uno de ellos), pero también porque trabajar con algo de forma "fresca" puede permitir aprender fortalezas y debilidades, que pueden llegar a aplicarse en otros ambientes.

En fin... veremos que sale.

posted by Esteban @ 11:09 AM