sábado, 12 de enero de 2013

Lo que amo de Scala: su cercanía a Java

Estoy en el proceso de registrar lo indispensable de Scala para el día que mire seriamente a otros lenguajes  "Mirar seriamente" es hacer un poco más que leer un tutorial y programar un "hello world", o sea demanda algo de esfuerzo.  No tengo el tiempo de revisar todos los lenguajes que se inventan así que debo filtrar los potenciales candidatos.  Por el momento, son Kotlin, Ceylon e Xtend porque todos comparten la cercanía con Java.

Esta cercanía con Java es importante por varias razones.

Por la JVM, los servidores de aplicación y en general los middleware basados en la JVM

No todos tenemos la suerte de trabajar para una startup que puede escoger completamente su arquitectura y, por ende, debemos negociar con el cliente la tecnología que se usará.  Casi todos los clientes tienen una plataforma definida y resulta más o menos difícil alterarla según lo que esta definición cubre.

Casi siempre, la definición de plataforma incluye la arquitectura física (servidores, redes, sistemas operativos, estaciones clientes) y la arquitectura de ejecución, o sea los middleware como los servidores de aplicación, servidores de mensajería y las bases de datos.  Es muy frecuente poder usar un middleware basado en la JVM

Otras veces la definición de plataforma incluye la arquitectura de desarrollo o sea, los lenguajes, las API, los frameworks, patrones y hasta el IDE de desarrollo.  En este caso, si el cliente pide Java+Spring-*, hay que tratar de convencerlo.  En la practica, es más fácil negociar cambiar la arquitectura de desarrollo que las arquitecturas físicas y de ejecución.

En resumen, la JVM y sus middleware (Tomcat, Websphere, Weblogic) son importantes por un tema de oportunidad laboral   

He leído que otros destacan la robustez, el performance, la seguridad y en general, la madurez de la JVM.  Estoy de acuerdo con estos argumentos y son las razones por las cuales, hay middleware basados en la JVM en todas partes.

Por las toneladas de API's y framework para Java

La popularidad de Java permite que haya soluciones para todo y a menudo de bajo costo.  No recuerdo cuando fue la ultima vez que me preocupe de encontrar un driver JDBC compatible con la versión de mi base de datos: no quiero pasar por lo mismo si me salgo de la JVM.

Poco a poco, hay API y framework que son optimizados para Scala, pero siempre habrá necesidades de usar esta vieja API Java que saca de apuro.

Por la sintaxis

Java hereda muchas ideas archi probadas en distintos lenguajes y que son familiares para muchos programadores.  Scala sigue usando:
  • la sintaxis básica de C usando bracket y donde una llamada a una función "f" se escribe como en las matemáticas básicas: "y = f (x)"
  • strong typing.  Me gusta que el compilador y el IDE trabajen por mi y no al revés
  • orientación al objeto.  Definitivamente no es la solución para todo, pero es necesario tenerla.
  • programación genérica. Hace el código más legible.
  • estilo imperativo.  No siempre se puede programar al estilo funcional en forma elegante.  El estilo imperativo saca de apuros, lo tengo comprobado.

Por los entornos de programación

Es tiempo ganado si no tengo que cambiar mi IDE (Netbeans, Eclipse), mi build automation (ant, maven), etc.

Lista de lenguajes que descarte

Todos los criterios anteriores me hicieron descartar:
  • los derivados de Lisp como Scheme, Clojure.  No hay ninguna razón para mantener una sintaxis que va contra años de enseñanza de las matemáticas.  Yo creo que usar estos lenguajes para tutoriales de programación funcional crea una barrera completamente absurda.
  • Ruby, Python: son dinámicos, su entorno "natural" no es la JVM.
  • Haskell, Erlang: no corren sobre la JVM y su sintaxis me recuerda demasiado a Lisp.
  • fantom: no tiene programación genérica.





No hay comentarios: