¿Como convencer que es tiempo usar Scala en lugar de Java?

Argumente en una entrada previa que se vienen nuevos tipos de aplicaciones que van a requerir cambios de arquitectura de software, o sea, cambios en los lenguajes y los middleware como servidores de aplicación y bases de datos.  Tengo la suerte ahora de participar en un proyecto asi: es de tipo CEP (Complex Event Processing) y podre usar Scala DSL de Apache Camel.

Esta bien, pero no es suficiente.  Quiero también usar Scala en proyectos web más tradicionales, porque no es todos los días que tengo la suerte de participar en proyectos realmente innovadores.  Por ejemplo, ahora mismo, estoy terminando un proyecto con J2EE 1.,4, Struts y EJB 2.0 para un cliente bastante conservador.  Pensando en este proyecto y el tipo de profesionales con los cuales tuve que interractuar, tengo que aprender a convencer que es el momento de mirar soluciones no 100% basadas en Java y JEE.  

Buscando lo que dicen los pundits en internet me encontré con este articulo de Bruce Eckel.cuyas conclusiones me hacen sentido: 

• Java llego en una etapa donde agregar nueva sintaxis como "closure", va a costar de vez en más . "...the adoption of new Java versions and features is going to continue to slow"
  
• La JVM y sus toneladas de bibliotecas van a ser heredadas por otros lenguajes. "The JVM will be the most important legacy that Java contributes to the computing world. "
• Scala y Groovy estan al acecho para re-utilizar la JVM y sus bibliotecas. "...Scala and Groovy (which play well with Java right out of the box)..."
  
• Hay Java para rato.   "Java itself will continue to be a core workhorse, just as C++ has been..."

No obstante, no estoy completamente de acuerdo en como Bruce fundamenta estas conclusiones. El hace una serie de criticas sobre Java y el rol que cumple Sun de las cuales algunas no son 100% justificadas o otras no son tan graves.

• el mensaje principal es que no se puede confiar en una organización con fines de lucro.  Es probable que si no había existido la necesidad de contrarrestar el dominio que tenia Microsoft sobre los desarrolladores, Sun no habría regalado su lenguaje e IBM no lo habría adoptado con tanta facilidad.   Entonces, compro este argumento pero solamente en parte, porque:
• existe muchos contra-ejemplo de lenguajes que no fueron apoyados por grandes empresas y que tampoco llegaron a un buen destino.  Perl es el primero que me viene en la mente.
  
• esta en las manos de los desarrolladores hacerse desear por las grandes empresas de TI.  Mientras no exista una sola tecnología dominante y que exista competencia por conquistar nuestro interés, estamos bien.

• no haber incluido closure y programación genérica desde el principio.  A mi, me parece una buena decisión de Sun haber aprovechado el boom de la internet.  Un año más tarde habría pasado la vieja, nadie habría sabido de Java y capaz que estaríamos criticando Visual Basic.

• haber mantenido compatibilidad hacia atrás cuando implementaron la programación genérica.  Me parece super razonable la decisión de Sun. Además, la programación genérica es muy practica para usos simples y la eche de menos en mi proyecto J2EE 1.4.

• No se cumplió a 100% el WORA (la portabilidad del binario Java).  Mi experiencia es que un proyecto razonablemente bien hecho es super portable.  En eso, Java esta muy encima de cualquier otra tecnología, incluyendo estándares como SQL, HTML, CSS y Javascript. 

• Implementación en Java de algunas funciones en punto flotante en lugar de usar el coprocesador.  OK, quizás para algunas rutinas matemáticas afecta un poco pero, la semana pasada vi una demo de un software de predicción estadístico con visualización en 3D. Estoy seguro que este software usa muchos cálculos en punto flotante y estaba hecho en Java/Eclipse RCP.  Al agua el argumento excepto para aplicaciones realmente fuera de lo común.

• Finalmente, Bruce termina argumentando que Python es la raja.  Quizás tenga razón, pero Python es más antiguo que Java y solamente orientado al objeto.  Yo creo que se necesita ideas realmente nuevas como la fusión de la programación funcional y la orientación al objeto para realmente dar un salto interesante.

Entonces, no me queda más que buscar otros argumentos.  Parece que va a ser difícil.

Evolución de los servidores de aplicación

Un tipo de SpringSource tiene un articulo muy interesante sobre la evolución de los servidores de aplicación.  SpringSource tiene un talento para hacerme reaccionar en forma negativa y no tengo una admiración incondicional por Rod Johnson .  Entonces, si estoy recomendando leer este articulo es porque lo encuentro realmente bueno.

Antes de propagandar su propia solución, el autor llega a la siguiente conclusión:

A new breed of application server is emerging. This new application server has a small, in-memory footprint. It starts fast and runs fast. It has a highly modular architecture and it can host a variety of services and domain-specific containers. It can respond to directives from a "grid controller" and it can provision, deploy, start, stop and tear down services on the fly. It runs efficiently in an elastic topology that may span heterogeneous physical hardware and virtualized hardware.  

En español:

• los servidores de aplicación se usan ahora para algo más que aplicaciones web dinámicas.  Por ejemplo, algunos productos ESB se montan sobre un servidor JEE para usar el manejo de transacción, la gestión de conexiones SQL/colas JMS, la administración vía JMX/consola Web, etc.  Estos ESB se programan con lenguajes no Java como BPEL, XPath, XSL o algún lenguaje de enrutamiento y enriquecimiento de mensajes propio.
• Un cluster con un número constante de servidores ya no es suficiente.  Se necesita soluciones "elásticas" donde una aplicación puede desplegarse automáticamente sobre nuevos nodos cuando crece su uso y decrece su SLA.  Al contrario, cuando baja el acceso a la aplicación, el sistema controlador de la grilla desactiva la aplicación para dejar más recursos a las demás.

Todo bien, pero no puedo dejar de criticar un poco el articulo, para no perder mi costumbre cuando se trata de SpringSource.

• habría sido bueno que el escritor diga desde el principio que trabaja para SpringSource.  Al principio, creí que era otro apostole de Rod, porque usaba el argumento liviano versus pesado de una forma super marketera.
• a pesar que estoy 1000% de acuerdo que la suite IBM Webpshere es la campeón de la pesadez. hay que señalar que lo que esta logrando SpringSource ahora, IBM lo tiene desde hace 3 años con productos como Webpshere ESB y Websphere XD.  Algunas veces, el pesado le gana al liviano y me parece suicidio dejar 3 años de ventaja a la fuerza de venta de IBM.

El futuro de las bases de datos SQL

Martin Fowler opina que vamos a ver cambios en el mercado de bases de datos.  Ver también el reporte en Infoq.

Su argumento central es que no necesitamos más a las bases de datos para integrar la información de una empresa.  Eso se debe que existen otras tecnologías (XML, Web Service, REST, JMS) que facilitan la integración entre aplicaciones y reemplazan a SQL.  

Es cierto que era una practica en la época cliente-servidor tratar de consolidar todas las tablas en un solo motor de base de datos, porque facilitaba hacer joins entre las tablas de las distintas aplicaciones.  La otra opción era conectar varios motores entre si, con facilidades de store-procedure remotos y SELECT remotos.  El hecho de tener un lenguaje estándar como SQL hacia fácil estos tipos de solución.  Entonces, para variar Martin tiene un buen punto,

La lógica de negocio se fue de los motores SQL hacia los servidores de aplicaciones y como lo menciona Martin la capa de integración también.  Hay una oportunidad de mirar por el lado para ver si hay algo mejor que SQL en algunos casos: SQL ya no manda el mundo TI como solía hacerlo.