Índice
Elliott Rusty Harold está anunciando en su blog que la programación funcional en Java es peligrosa. Está equivocado, y ya perdió su turno — Está viniendo con Java le guste o no. Un resumen de las razones que menciona en su artículo son:
- Java no es un lenguaje de evaluación perezosa. En Java, los programadores pueden enredarse y terminar generando errores con heap y stack.
- El artículo presenta una implementación simple de código Clojure que al pasarla a lenguaje Java falla en tiempo de ejecución.
- A partir de esta idea los programadores pueden lograr cosas muy malas, por ello tendríamos que evitarla.
- Y por último, afirma que es “peligrosamente ineficiente” en Java/JVM, reconociendo que no tiene referencias para respaldar esta afirmación, y que de algún modo está ignorando si Clojure y Scala corren en la JVM aparentemente sin problemas.
Esos puntos son básicamente un resumen del artículo.
Mira, como Elliott señala, Java no es Haskell. Ni Lisp. Es su propio lenguaje, basado en una historia imperativa y orientada a objetos, pero no por ello menos apta a incorporar características funcionales dentro de su desarrollo que la aptitud de Lisp para incorporar características de programación orientada a objetos. Sin embargo, si haces sandeces, como intentar regenerar una lista infinita (implícitamente de evaluación perezosa) en Clojure mediante la creación de una lista actualizada que se extiende hasta el infinito… vas a reventar la JVM. Uh. Ni siquiera el supercomputador en USS Enterprise de dentro de 500 años tendrá la posibilidad de construir esa lista.
Migrar código de un lenguaje a otro no es un ejercicio trivial. Si intentas migrar línea-a-línea y expresión-por-expresión, puedes esperar que tu código traducido no sea idiomáticamente correcto. (Ya lo se, habiendo hecho la prueba.) La raiz del problema en el código traducido es doble. Por un lado, (el más necio y poco elegante) simula de muy mala forma cómo debería verse una lista infinita en Java — un comentador hizo un mejor trabajo mostrando cómo un Iterator puede crearse para realizar la misma tarea que Haskell, de hecho, ya hace produciendo el valor siguiente bajo demanda, en lugar de intentar crear una lista de Integers extendiéndose hasta el infinito. Para alguien que profesa tener experiencia y amor por Haskell, es impactante que Elliott cometa este tipo de error, lo cual genera la impresión de que está intentando crear una falacia del hombre de paja. Además asume que cualquiera que programe en Java funcionalmente tendrá que crear todas sus herramientas funcionales a mano, y honestamente, usando Guava o FJ en este caso haría este código ejemplo MUCHO más facil de digerir. El hecho de que ignore ambas en su falacia nuevamente reafirma la idea de que está deliberadamente tergiversando ideas para mostrar su punto.
Su cuestión subyacente parece ser simple: “Trabajo con malos programadores, que no parecen entender cómo escribir código funcional en Java sin enredar todo.” Hermano, estás en la peor… “Los malos programadores removerán cielo y tierra para hacerlo mal.” -Glenn Vanderburg.
Pero lo que es realemente patético es que esas funcionalidades vienen en Java 8, incluyendo expresiones lambda y soporte de librerías incluyendo una interface Stream para precisamente permitir que este tipo de código sea escrito sin dolor. Esos programadores con los que Elliott está trabajando van a estar incluso más exitados por usar sus funcionalidades (y todas las ventajas asociadas por hacerlo, incluyendo composición y mucho más) en su código Java. Lo que puede hacer a Elliott más feliz es que al menos él no tendrá que haberlo escrito; va a estar escrito por personas más inteligentes que cualquiera.
Referencias
- DZone »» On Functional Programming in Java – It’s Coming…
¿Has visto algún error?: Por favor, ayúdame a corregirlo contactando conmigo o comentando abajo.