Sobre Java II (o ¿Esta muerto java?)

En el anterior post intentaba explicar porque no se me había ocurrido escribir sobre java. Al hacerlo realizaba una critica sobre el aduciendo que era lenguaje obsoleto e incapaz de adaptarse a los cambios debido su exito. Se podría deducir mis palabras que me adhiero al creciente numero de los que se apuntan al lema "java is dead" (213.000 resultados en google). Algunos van mas allá y se cuestionan no solo java sino la misma jvm y dando un paso el mismo paradigma de la programación orientada a objetos cuyos lenguajes estrellas han sido precisamente java y c++.

En este tema soy mas bien pragmático, sobre todo cuando hablamos de hacer negocios con un lenguaje de programación. Como comentaba en el post anterior java es muy utilizado en la empresa y no puede haber tanta gente cuyo objetivo principal es ganar dinero equivocada. Ha sido así hasta ahora y lo sera durante mucho tiempo así que no temáis los javahispanicos que tenemos java para rato, nos guste o no.

Sin embargo tampoco se puede ignorar los cambios que se están sucediendo que han hecho que se empiecen a elegir otros lenguajes en algunos campos de la empresa debido a que se ajustan mejor a su problemática especifica. Por ejemplo twitter ya se hizo en su día en ruby, y no hace mucho cambio la parte "backend" a scala, manteniendo ruby para la parte web. En el mundo de la jvm, claramente influido por la pionera en este sentido plataforma .net, se esta afianzando la idea del paradigma del multilenguaje, por el que los lenguajes se convierten, como las librerías, en herramientas disponibles para poder elegir la mas adecuada en función del problema a resolver. También es verdad que añades otras fuentes de problemas entre ellas la interoperatibilidad entre los diferentes lenguajes. En ese sentido java podría convertirse con el tiempo en el lenguaje de bajo nivel básico de la jvm, primitivo rápido y lo mas cercano al bytecode. O sea lo que seria c para las plataformas unix/linux y windows lo sería java para la plataforma jvm. La verdad es que no me imagino un servidor j2ee programado en groovy o en jython (mm tal vez si en scala). Stuart Halloway escribió una serie de posts sobre el tema que no se pueden pasar por alto respecto a este tema.

La jvm no es igual a java y tiene ventajas que han hecho por ejemplo que Rick Hickey y otros la hayan usado como plataforma destino de su lenguaje en lugar de ponerse a a hacer compiladores en c para cada uno de los sistemas operativos mas usados. Es independiente del hardware, esta muy optimizada a nivel de compilador y probada en ámbitos donde un fallo puede costar mucho dinero (aunque siempre queden flecos) y tienes miles de lineas de código y librerías disponibles para hacer casi cualquier cosa en casi cualquier ámbito de la programación. Cierto es que se creo ligada a java (y por tanto la tradición imperativa de c y c++) y eso ha hecho por ejemplo que algunos desconfíen del carácter innovador de scala y clojure ya que por debajo siempre arrastraran los limites y defectos de la misma jvm. Sin embargo hay que ser demasiado puro para ignorar las ventajas de escribir en un lenguaje compatible con todo el codigo disponible en java o en c#.

Sobre java (o por qué no sobre java)

Pensando justificaciones iniciales sobre las razones que tiene uno al escribir sobre un determinado tema se me ocurrió que tal vez debería detenerme en explicar porque no elegí java o un tema especializado que tenga que ver con java al decidir el tema central de mi blog.

Y en principio habría razones de peso para hacerlo: es el lenguaje con el que aprendía a programar en serio y el que me da de comer y dentro de mis limitaciones es el lenguaje sobre el que mas conocimientos tengo. Por tanto sería el tema sobre el mas podra compartir con los lectores y ademas le tengo cariño, el mismo que se tiene a tu primer amor aunque haga tiempo que no lo sea.

Sin embargo ya no es la herramienta con la que mas a gusto estoy por mucho cariño que le tenga. Tal vez, el que sea mi herramienta de trabajo diaria y la que tengo que sufrir ha influido en ello. Por otro lado al ser un lenguaje maduro (casi diría ya que un poco decrépito) hay miles de blogs y fuentes de información y no creo que pudiera aportar nada nuevo sobre él, ni siquiera en aquellos aspectos mas especializados de la J2EE.

Dejando aparte las razones personales y mis circunstancias el haberme juntado ultimamente con malas compañias funcionales ha hecho que vea mucho mas claramente sus limitaciones y rigidices y que palidezca comparandolo con cualquiera de los lenguajes o dialectos mas modernos desde python hasta clojure pasando por groovy o scala.

Parte del cambio de mi punto de vista se ha debido a esta mala compañia y sus ensayos sobre la historia y futuro de los lenguajes de programación y en concreto sobre java. En ellas compara a java con cobol, no tecnicamente, sino funcionalmente en el sentido de su función "social". Java es el actual lenguaje de programacion estrella del mundo de los negocios y se mueve mucho dinero a su alrededor. A medida que un lenguaje gana en popularidad es mas dificil realizar cambios sobre el y estos cada vez son mas leves (como le esta pasando a python). Si encima los "protectores" del lenguaje son Oracle e Ibm es totalmente explicable que java ya apenas pueda variar y adaptarse a los nuevos tiempos recogiendo los nuevos avances en el campo de los lenguajes de programación.

PD: Hace unos días y ante el clamor popular se ha anunciado oficialmente que finalmente java 7 tendra closures, contradiciendo mis argumentos en parte, cosa de la que me alegro muy sinceramente. El unico problema es que en mi trabajo diario todavia estoy peleandome con el 1.4 pero todo llegara...

Qué es una closure

Bueno casi parecía obligada una entrada que explicara el título del blog ya que closure podria traducirse como cierre clausura y con un poco (o un mucho) mas de licencia al traducir "cerradura".

Cuando estudiaba la carrera hubo un ejercicio en java en el que me vi obligado a iterar varias veces sobre una estructura de datos para realizar operaciones sobre ellas. Entonces me vino la idea de porque no se podría pasar un método como parametro para no tener que repetir una y otra vez la estructura de iteración.

En mi mente lo que queria era algo así:

    public void doForAll (Collection coll,Method m) {
          for (item in coll) "ejecutar codigo de m 
           sobre cada elemento de la coleccion";
    }

Le pregunte a mi profesor y su rapida respuesta fue NO.
Y no tenia razon claro porque en el mismo java se puede hacer algo así con clases anónimas. Usando el Commons Collection de Apache:

   CollectionUtils.doForAll (coll, new Closure () {
              public void execute(Object arg0) {
                    "ejecutar codigo sobre cada 
                     elemento arg0 de la coleccion"
              }});

Este "hack" se basa en las clases anonimas, implementaciones ad hoc normalmente de una interfaz. Gracias a ellas podemos implementar codigo justo en el sitio que lo necesitamos (si solo lo vamos a necesitar en un sitio y no va a hacer falta reutilizarlo)

Sin embargo aunque la interfaz se llama "closure" solo se parece y es una opción muy limitada si la comparamos con las closures reales de los lenguajes funcionales.

En javascript, python, ruby, groovy y la familiar de los lisp entre otros el codigo organizado en bloques es un "objeto" de primera clase. O sea puedes asignar a una variable un bloque de codigo, pasarlo como parametro y devolverlo en una funcion y ejecutarlo en el momento y lugar necesario.

En el caso de java con las clases anónimas puedes encapsular el código en una clase (con lo que se añade un elemento totalmente prescindible que hace de intermediario), crear una instancia y pasarla como parámetro y devolverla.

¿Donde esta la limitación? en la capacidad de las closures (por definición) de "capturar" las variables del contexto donde son definidas. Para que las clases anónimas puedan usar las variables externas a su bloque estas deben ser marcadas finales, es decir no modificables. Sin embargo con las closures reales el código mantiene una referencia a la variable en el momento de la definición del bloque de código y esta puede ser modificada antes y despues por el codigo y por la propia Closure.

Veamos un ejemplo en javascript (tomado de esta interesante página en Inglés):

function say667() {
 // Local variable that ends up within closure
 var num = 666;
 var sayAlert = function() { alert(num); }
 num++;
 return sayAlert;
}

var f=say667();
f();

¿Que nos alerta la función? como es previsible por el nombre de la función "madre" que la ha creado nos pone "667" (Podeis comprobarlo en la pagina)

Bien todo esto de capturar las variables es muy bonito pero así de primeras no se le ve una gran utilidad. Sin embargo sí la tiene ya que en java esto es imposible de hacer:

(defn make-adder [x] #(+ x %1))
(def add5 (make-adder 5))
(add5 8)
; Nos pintaria 13

Un ejemplo ya clásico de Paul Graham en su magnifica introducción a Lisp: On Lisp implementada en el dialecto de lisp Clojure.

Para los que sienten extrañeza, temor o repelus a los parentesis (aunque son bien parecidos a las llaves) habrá que explicar que make-adder es una función que genera funciones de suma. Que add5 es una variable que apunta a una función creada con la anterior que suma 5 a un numero dado y que al ser llamada con un parámetro de 8 nos devolvería 13.

...precioso verdad.

Para los que todaváa no esten convencidos veamos las closures otra vez en acción:

(filter #(> %1 5) '(1 2 3 4 5 6 7 8 9))

Esta funcion filtra los datos de una lista usando una funcion ("#(> %1 5)") que compara cada uno de los elementos de la lista y los mete en otra solo si cumplen la condicion.
En este caso la devolucion seria (6 7 8 9).
Claro como el agua, breve como un parpadeo y picante como una guindilla si me permitis calificar asi un codigo.

Os dejo a vuestra imaginación las posibilidades que se abren con estos cierres.

PD: Expongo el ejemplo en haskell, otro de los lenguajes estrellas del paradigma declarativo funcional (mas lejano y puro todavía que clojure)

>let makeAdder :: Int -> (Int -> Int);makeAdder x=(x +)
> let add5=makeAdder 5
> add5 6
11

El lado oscuro del Javascript: JScript

Bueno no todo iba a ser un camino de rosas. Al igual que Mario tiene su Wario Javascript tiene su lado oscuro nacido en los pozos y hornos de Redmond: JScript. Su principal caracteristica defectuosa es el ir a la contra. En otros aspectos eso me produciria simpatia pero programando NO.

JScript cumple la especificacion ECMAScript pero en varios huecos la implementacion es al reves que la del resto de motores (Opera,Mozilla,Chrome). Una buena manera de no quedarse atrancado en las compatibilidades es echarle un vistazo a como las diferencias pueden afectar a tu codigo en quirksmode.

I ♥ javascript

Fruto de mis devaneos funcionales he caido en el amor a javascript en su faceta mas funcional. La celeberrima libreria jquery ahonda en esa faceta de javascript y tambien la reintroduccion que aparece en el developer center de mozilla.

Por ejemplo con javascript puedes hacer virgueria como esta:

function call (functionName) {
 try {
  if (functionName) func=eval(functionName);
  if (func && func instanceof Function) 
   return func.apply (null,rest(arguments));
 } catch (e) {}
 return null;
}
function rest (list) {
 var result=[];
 for (var i=0;i<list.length;i++) 
  if (i!=0) result[length]=list[i];
 return result;
}

Esta funcion evalua un String pasado como primer parametro y si el resultado es una funcion retorna el valor de esa funcion pasandole el resto de parametros.

Clojure cumple su primer cumpleaños

O sea, se ha publicado la version 1.0 despues de un prudente periodo sin bugs ni problemas en el nucleo del lenguaje. Como el mismo creador exponia en el foro de la comunidad las razones tienen que ver mas con la divulgacion del lenguaje que otra cosa. Esperemos que la evangelizacion prosiga y pronto sea una religion dominante.

Inauguracion del barco

Hello world my dear friends. Al final me he animado a iniciar las entradas de este blog, orientandolo hacia un tema sobre el que todavia no hay mucho material escrito en castellano: el lenguaje de programacion Clojure y el renaciente interes de la comunidad de programadores por el paradigma funcional, marginado del mainstream durante mucho tiempo.

Intentare reproducir en sucesivas entradas tanto los motivos de este interes como mi recien iniciado aprendizaje en este hermoso lenguaje.

Y como una imagen vale mas que mil palabras: