18/05/2009
02/06/2009
18/06/2009
Joshua Bloch es en la actualidad el "Chief Java Architect" de Google; durante su paso por Sun Microsystems fue responsable de diseñar, entre otros, el framework de colections y buena parte del paquete java.util. Recientemente ha hecho una presentación Javapolis a la que ha titulado "la controversia de los closures" en la que, resumiendo en una frase, defiende que todavía es muy pronto para plantearse añadir closures a Java ya que hay que estudiar en detalle todas las implicaciones y los pros y los contras.
En la presentación defiende que la propuesta BGGA para crear closures complicaría excesivamente el lenguaje de programación Java y crearía otra fuente de potenciales códigos incomprensibles como es el caso de los wildcards en generics si se abusa de ellos. También defiende que al añadir una característica nueva a un lenguaje de programación la complejidad que va a añadir a ese lenguaje incrementa exponencialmente respecto al número de otras características con las que la nueva característica interacciona. Y las closures interactuarían con prácticamente todo.
Por otro lado, si queremos usar "function types" en Java, es decir, poder tratar un método una función como si fuese una variable más, o poder "pasar un cacho de código" a una librería sin necesidad de implementar una interfaz podemos hacerlo dentro de la plataforma Java empleando el lenguaje Scala.
Bloch defiende que en vez de usar BGGA sería más prudente apostar por la unión de las propuestas CICE+ARM, mucho más conservadoras y con menos poder expresivo pero que añadirían menos complejidad ha lenguaje. La desventaja de estas dos es que en la actualidad sólo son bocetos, mientras que ya existe una implementación casi completa de BGGA realizada por Neal Gafter, principal responsable de Javac cuando trabajaba para Sun e (irónicamente) compañero inseparable de charlas de Bloch hasta que comenzó la polémica de las closures.
Bloch también afirma que se haga lo que se haga debemos esperar varios años todavía y experimentar con los prototipos. Todavía es muy pronto para proponer un JSR.
¿Cuál es vuestra opinión al respecto?
Pues... no sé por qué pero últimamente tiendo a ver los "problemas" desde más lejos pero a la vez más grandes.
Si nos quedamos en el tema de las closures, me gusta bastante este comentario [bluej.org] de Michael Kölling. En general tiendo más a pensar que están añadiendo una complejidad excesiva para el programador medio (sobre todo porque creo que en el caso de Java el programador medio está empezando a ser cada vez "más medio").
Y si me alejo un poco, realmente me ocurre que creo que el tema de fondo no es el simple hecho en sí de las closures si no... ¿es/tiene que ser el futuro de Java ser el lenguaje del programador medio? ¿es posible tener un lenguaje que sirva para el programador medio pero también para el experto o el gurú? ¿Es tan fuerte la relación entre un lenguaje y el nivel medio de los programadores que lo usan? ¿Es el momento de... Ohm, bueno cosas mías, perdón xD
Como dijo Aristoteles, la virtud está en el justo medio.
Que se dediquen mejor a arreglar la genericidad...
¿es/tiene que ser el futuro de Java ser el lenguaje del programador medio?
Lo que distingue (en parte a Java de C++ y Perl) es que el lenguage es dominable en su totalidad por un mortal. (No hay tiempo material en una vida para dominar todas las APIs de cualquier lenguaje ...). En mi opinion, la gente deberia integrar varios lenguajes sencillos en su desarrollo ... Y el consejo de Scala me parece util, lo que no entiendo es porque a Sun parece joderle Scala (al menos lo ignora con mucho interes, como ya hizo con Nice) ...
Personalmente me gustaria tener APIs mas potentes y simples (y eso es lo que pretenden Generics y Closures), pero consiguen, desgraciadamente, crear 2 clases de desarrolladores (ya las habia con inner classes ...): Los que pueden hacer APIs decentes con toda la parafernalia y los que (yo me incluyo modestamente aqui) debemos limitarnos a usar ... Puedo petar el compilador de Java con solo 10 lineas aparentemente razonables con Generics :) :(
Aprovecho para parafrasear algo que lei: cualquier idiota puede generar codigo que entienda una maquina (de hecho la maquina lo hace todo los dias), se requiere un buen programador humano para generar codigo que otros humanos puedan entender ...
Que "funcione de alguna manera" es el principio de todos los males en los productos que otros tienen que usar o tocar
Escribe tu comentario