QuarkBlog_2.0

Voy a responder con un post enterito a javangeligo que el otro día me decía en un comentario que acabaría utilizando Java tarde o temprano. Bien, el caso es que ya utilizo Java; no tanto como PHP y JavaScript, pero si lo suficiente como para discutir las cosas que no me gustan de él.

Para empezar Java es mastodóntico, tan grande que se hace imposible utilizarlo efectivamente sin recurrir a un IDE que escriba código por ti (véase Eclipse, Net Beans, Sun Studio, etc. ). De esto adolece también .Net + Visual Studio: a ver quien es el guapo que programa sin utilizar el IntelliSense!

Aunque claro, es mas sencillo poner a una docena de juntaletras con los conocimientos básicos delante de un Visual Studio/Eclipse y que buceen por la API de cientos de clases "con el punto" a ver cual es la combinación correcta, antes que encontrar a doce tios que se hayan empapado del Code Complete, Pragmatic Programmer, los ensayos de Joel Spolsky, los posts de Jeff Atwood, que sepan qué diablos es un patrón de diseño y que tengan un mínimo de sentido crítico al hacer su trabajo para ver qué herramienta utilizar en cada caso. Pero bueno esa es otra batalla …

Creo que la productividad viene de mano del programador y su manera de hacer las cosas no del lenguaje o el IDE utilizados; y ojo, no digo que no ayuden ni que no sean útiles, pero los IDEs no son la panacea: si no hay metodología ni rigor la misma mierda sale del notepad que del Eclipse.

El código de alto nivel se hizo para que lo leyeran (y entendieran) los seres humanos no las máquinas, entonces ¿por que Java (y su copia, .Net) se empeña en hacerlo todo tan exageradamente abstracto? ¿Cuando van a quitar los cientos de deprecated del JDK que se arrastran desde el JDK 1.1 o el 1.2? ¿los getters y setters que tanto abundan no chocaban frontalmente con el principio de encapsulación del diseño orientado a objetos?

Cito a Rich Skrenta:

El código es malo. Apesta. Requiere mantenimiento periódico. Tiene fallos que requieren ser encontrados. Nuevas funcionalidades significan que el viejo código tiene que ser adaptado. Cuanto más código tienes, más sitios hay dónde pueden esconderse los bugs. Todo el tiempo que tarda en compilar. Todo el tiempo que tarda un nuevo empleado en encontrar sentido a tu sistema. Si tienes que refactorizar hay un montón de cosas que mover de un sitio a otro.

El código lo producen ingenieros. Para producir más código necesitas más ingenieros. Los ingenieros tienen un coste en comunicaciones de n², y todo el código que añaden al sistema, mientras expanden su capacidad, también incrementa los costes. Deberías hacer lo posible por incrementar la productividad individual de tus programadores en términos de la expresividad y potencia de lo que escriben. Menos código hace lo mismo (y posiblemente mejor). Menos programadores que contratar. Menos costes en la organización de las comunicaciones.

Y es que el mejor código posible es el que no escribes.

No voy a decir que Java es un mierda porque no es así y sería de imbéciles siquiera pretenderlo, pero lo que está claro que no es una bala de plata.

Por ejemplo, durante este mes he estado programando varios applets y sólo $DEITY sabe lo mucho que he tenido presente a la familia del que ideó el retorcido sistema de layouts para los GUI en Java, y eso que empleaba Swing que representa un adelanto bastante importante frente a AWT.

En un principio no parece tan horrible, hasta que lo comparas con el mejor sistema para diseñar GUIs: Qt (también disponible para Java), que no sólo hace el código más sencillo y legible sino que además es mucho más compacto. Lastima que no me dejen meter Jambi como dependencia

En fin para qué vamos a discutir … me mola más el tipado débil y multi paradigma, que le vamos a hacer.