A raíz de una entrada en la web de JavaHispano sobre unas declaraciones de Gosling en las que decía que poco le importaba ya Java como lenguaje quería comentar de forma más ampliada mi impresión sobre ello.
Lo cierto es que estamos en un punto interesante en la evolución de la plataforma Java: la desvinculación entre la máquina virtual y el lenguaje en sí mismo. Esto es algo que se tenía claro desde el mismo día en que se diseñó pero que no ha comenzado a tener fuerza hasta que han aparecido alternativas creíbles como lenguajes de desarrollo al propio Java.
Es difícil emplazar en el tiempo un momento concreto pero sí han existido varios eventos interesantes que parecen haberlo impulsado:
- La lentitud en la evolución de Java como lenguaje. Después de todos los cambios drásticos incorporados en Java 5 poco o nada nuevo llegó en Java 6. La versión 7 se hizo esperar y, con la compra de Sun por parte de Oracle, aún más -y ni hablar de la ya celebre falta de innovación de esta compañía, conocida por su impresionante fuerza comercial pero no por sus alardes técnicos-. Algunas personas se mostraron además partidarias de congelar la especificación del lenguaje -capturado muy bien en el podcast de Java Pose de comienzos del 2008 por Bruce Eckel- frente a quienes creían que debía continuar evolucionando. Era un caldo de cultivo ideal para quienes deseaban nuevas opciones.
- La aparición de otros paradigmas de desarrollo para los que Java no estaba preparado. Y especialmente los lenguajes funcionales en un mundo en donde la concurrencia era cada vez más importante -incluso en las máquinas de usuarios finales-.
- La aparición de Rails como framework para Ruby. Rails comenzó a ocupar desde el principio un espacio que pertenecía hasta el momento a Java y PHP. Su creador, David Heinemeier Hansson -más conocido en la comunidad como DHH-, una persona con opiniones muy fuertes, atacó directamente la complejidad y el coste de los desarrollos en Java. Muchos programadores comenzaron a usar este framework con Ruby, descubriendo este lenguaje de forma activa y las virtudes prácticas de emplear otro tipo de lenguajes más eficientes para el desarrollo Web. Es precisamente la plataforma Java desde donde llegaron una gran número de desarrolladores a Rails. Aunque, obviamente, existió también una corriente crítica con el recién llegado, nadie negó la elegancia y claridad de Rails y Ruby. Era un framework que explotaba las ventajas de un lenguaje muy flexible y cercano al desarrollador de una forma que era imposible de alcanzar desde Java.
A partir de su presentación en sociedad se pudo comenzar a leer todo tipo de opiniones en los blogs de reconocidos desarrolladores y líderes de la industria: defensas a capa y espada, ataques frontales, etc. Lo único cierto es que Rails no fue en forma alguna ignorado. Ahora ya existía una alternativa popular y comercial que mostraba las claras deficiencias de la programación en Java. El daño estaba hecho.
- Se había llevado al límite el lenguaje. Java, siendo diseñado específicamente para ser sencillo, no es tan moldeable como otras alternativas. Desde las primeras aplicaciones, los métodos encadenados (típicos de Hibernate y otras librerías y frameworks) para formar DSLs, la inclusión de complejos ficheros XML como pseudo-lenguajes para suplir las carencias existentes y los usos creativos de su capacidad de introspección, se había llegado al techo. Lo que se estaba viendo era lo que permitía el lenguaje y no era sencillo ir más allá.
El resultado en cualquier caso fue el sentimiento de que se escribía demasiado código en Java, el código no era tan legible como podría ser, no cubría los nuevos paradigmas de desarrollo, y por otro lado gestionar los DSL's camuflados como XML era un infierno. Si bien eso ya se sufría desde hacía tiempo, ahora había otros lenguajes y frameworks con aplicaciones en producción que facturaban millones para demostrarlo. Y, desde luego, siempre ha existido un deseo por explorar y avanzar en la comunidad Java. Que sería sin ese "deseo patológico por la complejidad" en la comunidad Java del que hablaba Rod Johson hace poco.
Varias razones:
- El valor de la marca 'Java' es indiscutible. Sobre todo en grandes corporaciones y la Administración. Se identifica como algo seguro, consolidado. Si en los 80 era típico el "nadie ha sido nunca despedido por contratar IBM" y en los 90 "Tampoco nadie ha sido nunca despedido por contratar Microsoft" durante la primera década del 2000 lo mismo era aplicable con Java como plataforma corporativa de desarrollo.
- Un conjunto de librerías disponibles increíblemente alto. Junto con C, Java es uno de los lenguajes con mayor número de librerías disponibles. Su número, en prácticamente cualquier escenario, es simplemente abrumador.. El coste de penetración de un nuevo lenguaje es absurdamente alto si hay que desarrollar todo desde cero pero, si es posible emplear la impresionante base de código existente (de la misma forma en que Ruby o Pythonemplean librerías en C), el escenario es completamente distinto.
- Facilidad de desarrollo entre diferentes arquitecturas de hardware. Toda la potencia de las librerías de Java se puede emplear en la mayor parte de las arquitecturas de hardware actuales sin apenas cambios. No hay que pasar por la pesadilla de las librerías en C, que deben ser recompiladas no sólo para cada plataforma sino para cada sistema operativo. Con Java disponer de un nuevo lenguaje es poderlo emplear inmediatamente en todas las máquinas. Y en la mayoría de los casos es tan sencillo como añadir un nuevo JAR.
Hay muchos lenguajes disponibles para la JVM, cada uno es un estado de madurez distinto. La situación es, sin embargo, muy diferente a cuando se incorporaron nuevos frameworks y librerías como herramientas "casi obligadas" de desarrollo en el pasado. O'Reilly acuñó el término "Alpha geeks" para referirse a las principales personas apasionadas por la tecnologías que definían el futuro de una tendencia en un sector. Un consenso entre ellos solía significar que una tecnología tenía muchísimas posibilidades de ser adoptada. Ocurrió contínuamente: cuando determinadas personas que eran consideradas "gurus" en la comunidad comenzaban a adoptar en conjunto ciertas soluciones, éstas llegaban al entorno corporativo: Struts hace años, Hibernate, Spring, ANT para luego pasar muchos de ellos a Maven, JPA cuando se aceptó que era una alternativa válida a Hibernate, etc, etc.
En su momento existió un consenso sobre que esas eran las mejores opciones en su campo y se comenzaron a implantar en entornos de producción reales. La diferencia es que no existe ese consenso en relación a los lenguajes.
No obstante hay dos que están presentes en muchos blogs, podcasts y foros: JRuby, una implementación de Ruby, y Scala, un lenguaje mixto funcional-orientado a objetos. Ambos con sus méritos y también ambos extremadamente interesantes. El último en llegar haciendo ruído ha sido Cylon, una evolución de Java a manos de Gavin King. Estoy seguro de que vamos a oír hablar mucho de ellos a la espera de que llegue una alternativa totalmente nueva, aunque también es cierto que mucha gente lo ha asociado a JBoss -RedHat- por venir de él. Esta "marca" no ha abandona nunca a Seam, por ejemplo, que no ha conseguido llegar tan lejos como podría por méritos propios.
Un ejemplo interesante sobre los problemas en la adopción de un nuevo lenguaje se pueden escuchar en el podcast de hace unas semanas de Java Pose. En él un grupo de desarrolladores con perfiles altos evalúan la idoneidad de añadir un nuevo lenguaje -en este caso Scala- en un equipo de desarrollo muy motivado y dispuesto a invertir tiempo personal en ello (uno de los mejores escenarios posibles). En esencia comentan cuatro problemas en el caso de Scala: falta de desarrolladores en el mercado para ese lenguaje, falta de experiencia ya no con el propio lenguaje -que se puede aprender relativamente rápido- sino en programación funcional, cambios contínuos en la propia definición del mismo (falta de madurez) y alto riesgo de incluir un nuevo elemento fundamental en el desarrollo que todavía está sin consolidar en una aplicación de misión crítica que deben mantener y continuar desarrollando.
Sin entrar en necesidades específicas de entornos concretos, hay algunas cosas que se han demostrado muy útiles y productivas en los escenarios que habitualemnte cubre Java. La fantástica capacidad de crear DSL's internos de Ruby ha llevado por un lado a crear un código increíblemente conciso y legible, con una reconocida productividad (aunque aquí habría que hablar de otras cosas, como su capacidad para redesplegar en caliente -el demoledor "turnaround" en el despliegue- sin traumas a pesar de JRebel -se dice que han encontrado a programadores fosilizados mientras introducían cambios en una clase-), que es algo que se echa muchísimo de menos en Java. Esta facilidad ha llevado a crear ficheros de apoyo escritos directamente en Ruby sin necesidad de XMLs infernales, difíciles de escribir y aún peores de entender cuando un equipo entero trabaja con ellos.
En relación a Scala y lenguajes funcionales, creo sinceramente que la búsqueda de opciones de concurrencia sencillas preocupan a un número bastante limitado y especializado de desarrolladores. No obstante las otras virtudes de Scala (evitar el exceso de código de Java, su flexibilidad para crear DSLs, ser un lenguaje estáticamente tipado -que lo hace más atractivo a los ojos de algunos desarrolladores-, su magnífica integración con las librerías existentes, etc) son extremadamente interesantes. Su complejidad -que algunos ya llegan a definir como el C++ de la JVM- puede ser sin embargo un problema para programadores casuales.
Hay que estar atentos a Scala y JRuby, con Cylon en el radar como potencial opción de futuro cuando esté disponible. El lenguaje que más tracción parece estar ganando es, sin embargo, Scala, con una notable diferencia frente a los demás.