Programación funcional en Java: ¿será bueno o malo?
AbrahamCon Java SE 8 la plataforma va a pasar a tener soporte para cierta funcionalidad del ámbito de la programación funcional. Parece haber un debate ahora mismo sobre qué significa esto para la plataforma y si es bueno o malo. Una minoría de gente piensa que puede ser problemático, porque va a llevar a los programadores Java a cometer errores, algunos de los cuales pueden incluso ser fatales para la máquina virtual Java. Además afirman que debido a la arquitectura de la máquina virtual Java el estilo de programación funcional no va a tener un buen rendimiento.
Esta opinión no es compartida por todo el mundo. En este post ebatan todos los argumentos del post anterior.
¿Cuales vuestra opinión al respecto? ¿Será positivo o negativo el contar con closures en Java 8?
Reader Comments (31)
Entiendo que la programación funcional es potente (aunque no la conozco bien, creo que es la misma que utiliza Lisp).
Es una nueva carcaterística, desde mi punto de vista, y eso aumenta las posibilidades del lenguaje. Si que veo a priori que, al no estar orientada previamente Java a dicha programación, puede no tener el mismo "cuidado" de la JVM que la PO, aunque estoy simplemente intuyendo, no tengo razones de experiencia ni teóricas al respecto, simplemente intuitivas.
Mi primera opinión: es una buena noticia, más potencia, lo que obligará a tener más responsabilidad de los programadores, y sí que, en casos no controlados, podrá bloquear o generar problemas previamente no contemplados. Al fin y al cabo, es un cambio.
prácticamente todo el código que se escribe en java es basura (boilepart + archivos de configuración + "arquitectura empresarial" + interfaces vacías + dtos + service service imple + modelos anemicos + empty delegates + "verbosidad de java" ) cualquier cosa que haga que escriba menos lineas inútiles es bienvenido ya tenemos demasiadas
Más que problemas de la JVM, es una cuestión de problemas de los programadores. La programación funcional puede ser muy elegante y "potente" por concisa, pero tiene sus pegas y todos sabemos que "un gran poder conlleva una gran responsabilidad". Para lo bueno y para lo malo, no todos los programadores son Spiderman, y eso es lo que teme la gente.
Es algo así como lo que pasa con Hibernate o pasó con los EJBs... si lo haces todo fáil y transparente, la gente lo usa sin saber que pasa por debajo y luego resulta que "el rendimiento es penoso", "consume mucha memoria" etc. etc.
Ese ejemplo del primer enlace ha sido abundantemente contestado, tanto en el mismo post, como en otros. No tiene ninguna relación con las lambdas de JavaSE 1.8
Es una manera, bastante burda, de "imitar en Java" lo que pueden hacer otros lenguajes, sin tener en cuenta las diferencias.
La arquitectura de la VM se está modificando, sustancialmente, para soportar los nuevos lambdas; por lo que, hacer especulaciones, como se hace en ese post, es una demostración de pura ignorancia, al confundir las capacidades actuales de las VM, con la nueva en desarrollo.
Las lambdas en JavaSE 1.8 usan todas invokeDynamic. No se crean "clases" al estilo de las clases anónimas actuales. La VM es la responsable de "traducir" a código ejecutable, las "especificaciones" de las lambdas en el código fuente. Nada que ver con lo que hacen las VM hasta ahora.
En mi opinión hay demasiada fanfarria, nuestra industria siempre está ansiosa de hypes y ese ansia puede producir fácilmente insultos a la inteligencia, no digo que sea el caso, el problema no está en las ideas de la programación funcional sino en algunos de sus defensores que encuentran en el agua la solución a todos los males normalmente despreciando las demás opciones.
No hay apenas nada inherentemente "nuevo" en la programación funcional, por ejemplo las closures "por debajo" muy probablemente no sea más que inner classes de un cierto tipo predefinido, para cualquiera que haya creado miles de listeners de eventos lo de las closures como la solución del hambre en el mundo da un poco de risa, las closures son "buenas" siiii, pero aportan POCO MAS que escribir un poco menos.
En otro orden de cosas, si en el día a día uno hace algo así:
for(T obj : lista)
{
Hacer algo 1
}
for(T obj : lista)
{
Hacer algo 2
}
for(T obj : lista)
{
Hacer algo 3
}
Pues CUALQUIERA que se quiera un poco a sí mismo y crea en la reutilización de código como una religión (de las pocas cosas en el mundo del software en las que hay que "creer ciegamente" terminará haciendo algo así:
iterameloSam(List<T> lista, Funcion<T> func)
{
for(T obj : lista)
{
func.doIt(obj);
}
}
Y empezará a usar:
iterameloSam(lista,unafunc);
en vez de repetir una y otra vez, una y otra vez bucles for y así sin quererlo habrá modelado objetos Funcion que representen diversos algoritmos aplicables a un cierto tipo de lista (o tipos de lista).
Si le añades un poco más de orientación a objetos (un List con un forEach o similar) y closures para reducir el ruido de una clase-con-un-sólo-método pues tienen ya algo más bonito aún y así como "más funcional" (por no decir "más de lo mismo").
Y como parece que las funciones molan y hay que usarlas para todo llega la moda de primar la forma recursiva de procesar una lista de cosas en vez de la forma iterativa, y es ahí en donde este tema puede ponerse MUY PELIGROSO, porque por mucho tail-optimización a mayor número de llamadas recursivas más stack, y por tanto el uso del stack está ligado al número de llamadas o "iteraciones recursivas", por no hablar de que hay cierta moda de crear al menos un objeto temporal en cada llamada recursiva y por tanto llenar la memoria (pila o heap porque eso lo decide la JVM) de objetos para un simple algortimo que con un simple for iría sobrado (eso sí encapsulado en un forEach para que no se vea que ahora parece que queda feo). Si a eso le añades la tentación de usar cachés "para evitar tanta llamada" pues es posible que machaques la memoria total para un simple for de un sumatorio de números.
Hago mucho incapié en este último punto porque es el más controvertido, y el más "funcional", pero que sin cuidado y por ir de guay y de modernos puede mandar a tomar por saco tu programa,
Por ejemplo:
http://www.ibm.com/developerworks/library/j-ft1/index.html
En el tercer comentario al artículo:
"Thanks for this article. I ran a performance test on both the versions (functional and non functional). Functional took 12167 milliseconds and non functional took 77 milliseconds. Is this due to the way functionaljava library is implemented? Is there anybody who use functionaljava in production systems or are they just for fun?"
Me huelo que la causa es un método range() de la librería FunctionalJava definida internamente de forma recursiva y que crea un objeto por cada recursión.
http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/Stream.html#range(int, long)
¿A qué es más pesado usar un StringBuilder que concatenar cadenas en plan += ? no siempre lo más "elegante" y "moderno" y "sucinto" es lo mejor.
@jmarranz
¡Hombre!, las lambdas en Java aportan algo más que "escribir un poco menos" ;)
Mucha gente cree que se trata de una "solución sintáctica", para ahorrar "desgaste de dedos en el teclado", y presumir de "mira lo que hago con una única línea" ;D
Como si las funciones de autocompletado y de generación de templates no existiesen en los IDE desde hace lustros.
Claro está que los maniáticos del teclado, que creen que codificar es esencialmente una "cuestión de dedos volando bajo sobre un teclado", están siempre de enhorabuena con esas minucias. Me gustaría ver cómo se las arreglan para desarrollar proyectos con miles de clases, y centenares de miles de líneas de código, con esa obsesión incomprensible anti IDE.
Las lambdas en JavaSE 1.8 van a reducir considerablemente el número de clases: adiós a las conocidas Clase$1.class; y también van a permitir la paralelización de las Collections, usando internamente Fork&Join.
Cuando se dice que algo es una ventaja porque se puede hacer lo mismo en menos lineas el objetivo no es ser más productivos por "escribir menos" más bien se trata de ser más productivos por "leer menos", es más, se trata sobre todo de eliminar ruido de forma que el código refleje el problema a resolver con los menos artificios posibles. En otras palabras, eliminar complejidad accidental, el desarrollo de software es una eterna guerra contra la complejidad, y cada batalla es importante.
Y hombre jose maría, la programación funcional se puede criticar por algunas cosas, pero precisamente por "moderna" no creo yo... que tiene más años que matusalen. Otra cosa es que ahora este de más actualidad por el relativo fracaso de los lenguajes OO en muchos escenarios (aunque yo creo que el fracaso es más bien de la propia industria y la educación, pero eso es otra historia) y de la reciente importancia de la programación multi-hilo, donde un lenguaje funcional puede simplificar bastante las cosas. Yo no termino de ser muy fan de la PF quizá porque no tengo suficiente experiencia en el paradigma y no me siento comodo, por otro lado de lo que si soy fan es del código legible y el código funcional (lisp, clojure, haskell...) siempre me ha parecido difícil de leer, aunque de nuevo puede ser más debido a mi inexperiencia en el paradigma que a otra cosa.
Aunque sea un poco off-topic, al respecto de los IDE's generación de código con templates y tal. Si un IDE puede generar cierto código es porque ese código se puede inferir de forma directa, es decir, si se puede inferir mejor sería que lo hiciera el compilador o el runtime y eliminar del lenguaje todo el ruido. En java trabajar sin IDE puede ser un infierno, yo en groovy llevo más de un año con un editor (sublime text que mola tela) y tan feliz, no echo de menos al IDE en absoluto. Personalmente no me compensa usar un IDE, que cada día me parecen más pesados, para lo poco ofrecen en un lenguaje dinamico, prefiero algo más rapido. Y mi proyecto tiene centenares de miles de lineas, usar un IDE no tiene mucho que ver con el tamaño del proyecto, más bien con el lenguaje que uses, las practicas que sigas etc,etc. (no tienes compilador on the fly ni debugger, pero haces TDD por ejemplo). Por cierto, ¿habéis probado un multi-proyecto maven de unas 500k lineas en eclipse?, yo si, no se lo recomiendo a nadie, te puedes morir... todavía con netbeans o idea es otra cosa.
"¿habéis probado un multi-proyecto maven de unas 500k lineas en eclipse?, yo si, no se lo recomiendo a nadie, te puedes morir... todavía con netbeans o idea es otra cosa.''
Hola se a lo que te refieres multi proyecto con maven a pesar de quitarle todos los analizadores de xml y demas tips es la muerte al final termine usando Sublime text u maven por consola y me va bien
@alfredocasado "Y hombre jose maría, la programación funcional se puede criticar por algunas cosas, pero precisamente por "moderna" no creo yo... que tiene más años que matusalen"
Hombre nada más empezar el comentario escribo "No hay apenas nada inherentemente "nuevo" en la programación funcional" :)
Y el uso de la palabra "moderno" se usa con mucha ironía y un poco de mala leche :)
Y criticar, criticar realmente no critico gran cosa, quizás lo único que "critico" es que ciertas obsesiones (recursividad y creación de objetos función en cada iteración recursiva) pueden acabar dando lugar a monstruos curiosos pero muy poco KISS y con un rendimiento PENOSO.
Y respecto a la programación multihilo ¿alguien tiene algún problema en su aplicación web convencional en donde lo único compartido es la BD y la gestión de la concurrencia en ese caso la gestiona la propia BD a través de transacciones y sus respectivos locks y multiversiones?
Ahora bien, habrá casos de datos cacheados en memoria por la razón que sea (rendimiento normalmente) que serán compartidos entre hilos, cualquiera con un mínimo sentido común sabe que cuantos menos datos compartidos mejor que a lo mejor ese caché se acaba convirtiendo más en un problema que una solución, que el proceso de datos compartidos entre hilos debe ser sincronizado y que dicho proceso tiene que ser el mínimo posible pues el precio es parar los demás hilos y que puede convenir hacer una copia de dichos datos, procesarlos y consolidarlos, pues claro, y que si los datos que tenemos son inmutables pues no tendremos problemas de concurrencia de hilos, pues si, ojala fuera siempre así pero va a ser que no, y que si tenemos varias tareas pesadas podemos paralelizarlas en varios hilos, pues bien. Pero la clave es la inmutabilidad de los datos compartidos o la existencia de una copia de los mismos por hilo no en donde se ponen los datos si en atributos de objetos, si en parámetros de funciones o donde sea, tampoco donde se ponen los algoritmos, sin en funciones puras como el agua del manantial o agrupadas en objetos que ahora resulta que son malos para algún guru (como si los objetos meramente funcionales sin atributos fuera algo nuevo) etc, pero para eso no hace falta tanto ruido, tanto iluminado y tanto guru anunciando la buena nueva.
Con todo esto tengo que reconocer que me pone la obsesión muy funcional por la separación ortogonal entre los algoritmos y las estructuras de datos , pero es algo tan antiguo y tan retro (¿a alguien le suena la programación genérica, Alex Stepanov y las STL C++?) que flipo cuando se enseña como algo "nuevo" (el típico forEach) cuando ya existen clases como Collections en Java que es básicamente eso con más con años que la tos.
Vamos a ver, por nueva característica no quiero decir que es un nuevo paradigma, si no que sería algo nuevo dentro de Java, pasando a tener dos paradigmas: orientación a objetos y funcional. Lo que desde mi punto de vista da más potencia a priori, al fin y al cabo, son dos paradigmas, y por definición inicial, darán más recursos a los desarrolladores, siempre que éstos sepan utilizarlos.
Ahora bien aumentará el nivel de dificultad del aprendizaje. De paso, incluyo una definición de wikipedia para fomentar el debate, ¿alguien es capaz de explicar qué es la programación funcional y contar qué puede aportar?
"En ciencias de la computación, la programación funcional es un paradigma de programación declarativa basado en la utilización de funciones aritméticas que no maneja datos mutables o de estado"
A priori: más matemáticas, no estado. A mi que me gustan las matemáticas veo que es algo que personalmente me motiva mucho.
Es curioso, por qué esa es la línea que lleva Scala, ¿no?
Creo que añado otro punto al tema de debate que es el del manteamiento, quizás sea todo muy bonito, muy de moda y muy de rendimiento perfecto pero.......
Que pasa cuando ese pedazo de código con tanto potencial que es una línea de código haces 20.000 cosas y funciona a la perfección, y hay que hacer modificaciones sobre ello.
Pues a bote pronto mucho miedo en tocarlo y habrá que hacerlo con mucho mucho cuidado, creo que mantenerlo llevará más tiempo y en consecuencia dinero.
Si ya a los desarrolladores no nos gusta heredar código de otros, ahora es posible que nos guste mucho menos.
Por lo demás no le veo más problemática, pero esto creo que también hay que tenerlo en cuenta.
Pues mi unico contacto con la programacion funcional fueron unas practicas de la universidad en Lisp y las recuerdo con mucho dolor... Pero bueno, mientras sea una posibilidad que añaden al lenguaje, con no usarla ya esta.
No obstante, los de Oracle deberian darse cuenta de que lo que tienen entre manos no es un juguete, que es un lenguaje con presencia en medio mundo y que antes de añadir mas cosas se deberian preocupar un poco de evitar sustos como los de estos dias pasados, que el que recomienden desinstalar Java de los ordenadores no deberian tomarselo a broma. Que lo de que Java sea el nuevo Cobol esta muy bien porque eso garantiza trabajo, pero seria mejor que Java siguiera siendo Java, a secas.
Y en cualquier caso, si tengo que elegir entre programacion funcional y lambdas por un lado, y un delete para decirle al GC que borre cosas cuando yo le digo sin esperar, no lo dudo ni un momento. El delete. Eso es una caracteristica del lenguaje, y lo demas no deja de ser azucar sintactico. El delete te permite hacer cosas que hasta ahora no puedes hacer (crear una Hashtable de 20 millones de objetos y meter y sacar muchas cosas de ella) porque el GC va acumulando objetos caducados hasta que te quedas sin ram, mientras que lo otro facilita cosas que ahora mismo ya puedes hacer.
Y estoy de acuerdo con jmarranz en todo, para variar. La POO puede aportar aun muchas mas cosas de las que se usan, aunque no casen con el calendario de novedades de la gente de marketing.
@jmarranz, yo no lo veo asi. El meter colecciones que acepten lamdas permite hacer cosas como colecciones perezosas o concurrentes, lo cual esta genial para aplicaciones que no sean web o para cuando se quiere hacer una iteracion y acabar en un existe o un paratodo (no en el sentido de "haz esto para todo" sino en el de "que se cumpla esto para todo").
Os recomiendo a todos este articulo:
http://cr.openjdk.java.net/~briangoetz/lambda/sotc3.html
@antuasoft, desde mi punto de vista, los cambios generan estas cosas. Por ejemplo, Scala tiene la ventaja de reducir líneas de código (pasar de 2000 de Java, a por ejemplo, 500), sin embargo, eso requiere que tú sepas Scala, porque si lo hereda una persona que no sabe el lenguaje... pues tiene que aprenderlo. Eso por un lado.
Por otro lado, lo de que no nos gusta heredar programas de otros pues creo que nos ha pasado a todos, pero vivimos en un mundo donde tenemos que tocar el código (y cuidar) de otras personas, al fin y al cabo, es parte de nuestro trabajo como desarrolladores, ¿no? Aunque entiendo perfectamente a nivel emocional lo que comentas y genera un debate interesante a nivel personal (ya no técnico) ;)
Saludos
Yo estudié un cuatrimestre de programación funcional con Haskell en la facultad y me gustó mucho el enfoque. Además, entronca directamente con los tipos abstractos de datos. La programación funcional es mucho más que incluir 'closures' en un lenguaje. Por ejemplo, Clojure es un lenguaje funcional al estilo de Lisp implementado sobre la JVM. Y Frege también, pero al estilo de Haskell.
@golthiryus
Estamos de acuerdo, somos programmers nos gusta lo que hacemos y es parte de nuestro trabajo.
Yo a las nuevas incorporaciones las suelo poner en los proyectos de manteamiento para que se vayan acostumbrando a como trabajamos, la metodología, la manera de hacer las cosas, etc... y muchas veces para ellos es su primer trabajo.
Es parte de la curva de aprendizaje que tienen que llevar a cabo, inevitable para todos, sólo digo que esta será más grande.
@antuansoft Muy comprensible lo que comentas, los mantenimientos, al ser más grandes, implican o bien una reestructuración, o bien el mantenimiento del antiguo software, teniendo el peligro de no sobrevivir al cambio (haciendo buena la frase de reonvar a morir). Esto es: en nuestro caso, trabajamos con una aplicación basada en Java 1.5 porque tenemos un servidor de aplicaciones que no soporta una JVM superior. Es probable que más adelante nos veamos obligados a realizar una migración porque podemos quedar expuestos a quedarnos obsoletos.... el cambio siempre es necesario, aunque si lo que has mantenido durante mucho tiempo te ha dado de comer y lo has mantenido bien, pues la lucha se enfoca en conservar lo que uno tiene, ¿no?
Estoy de acuerdo en que el cambio es grande, porque implica un mayor aprendizaje. Ya no es una nueva clase, o un nuevo paquete, es la inclusión de un nuevo paradigma... y vaya, ya era hora de que Java evolucionara de manera significativa. Yo creo que es hora de ponerse las pilas cuanto antes con la programación funcional.
Un saludo,
Por aclarar lo que se puede malentender la "tail-optimización" lo que hace es que el agoritmo que tu escribes como recursivo, el compilador lo transforma en iterativo, así que sí que tiene mucha importancia. Por que si no lo puedes optimizar, quiere decir que es iterativo "puro" y ojo con el stack. Por eso se le da tanta importancia a esa optimización: por que así consigues escribirlo "elegantemente recursivo" pero sin renunciar al rendimiento o "ligereza de stack" de una solución recursiva.
Por cierto: el curso de Functional Programming in Scala de Coursera se vuelve hacer en breve, por si alguien quiere una intro ordenadita.
¿Alguien se atreve a intentar contar en pocas palabras y con ejemplos prácticos qué es la programación funcional?
@jcarmonaloeches
Para saber lo que es la programación funcional, creo que lo mejor es ir "a las fuentes":
http://www.haskell.org/haskellwiki/Functional_programming
Sobre el "cambio de paradigma", igual viene bien recordar que lo que sigue es un lambda, aunque no lo parezca ;)
EventQueue.invokeLater(new Runnable() {
@Override
public void run() {
// estamos dentro del EDT
}
});
Es evidente que la sintaxis es muy "peculiar", y que carece de la potencia expresiva y funcional de los lambdas escritos en otro lenguaje, y en JavaSE 1.8; pero es lo que es.
¿Pero de verdad estamos hablando de un "paradigma"? ¿o de un estilo de programación?
Yo entiendo un paradigma como una serie de técnicas de programación que exigen una serie de facilidades sintácticas y no veo muy claras las deficiencias de cualquier lenguaje imperativo respecto al estilo funcional (o paradigma) aunque no digo que no se puedan añadir elementos nuevos por ejemplo se me ocurre "la congelación de objeto" (para hacerlo inmutable) o similar, por ejemplo el C y el C++ clásico no tiene nada de captura de contexto que es la raíz de las closures pero Java tiene captura de contexto desde Java 1.1. Esto no quita que la ausencia de funciones de primera clase en Java haga que la chapucilla de las innerclases de un sólo método pues deje un poco que desear desde el punto de vista de la programación funcional, pero es más un problema de verbosidad que de "impedancia" ¿me equivoco?.
Para los que nunca han visto nada de programación funcional un vídeo de ejemplo:
pelin largo porque el hombre se lía un poco pero como concepto creo que vale.
http://www.youtube.com/watch?v=3XZRTasjUJM
El ejemplo de @jmarranz que está por arriba también es bueno
si en el día a día uno hace algo así:
for(T obj : lista)
{
Hacer algo 1
}
for(T obj : lista)
{
Hacer algo 2
}
for(T obj : lista)
{
Hacer algo 3
}
Pues CUALQUIERA que se quiera un poco a sí mismo y crea en la reutilización de código como una religión (de las pocas cosas en el mundo del software en las que hay que "creer ciegamente" terminará haciendo algo así:
iterameloSam(List<T> lista, Funcion<T> func)
{
for(T obj : lista)
{
func.doIt(obj);
}
}
Y empezará a usar:
iterameloSam(lista,unafunc);
@jmarranz
No creo que te equivoques, sino que estás muy en lo cierto ;)
Cuando se quita de en medio la "verbosidad", se dejan a un lado las "florituras sintácticas", y se va al fondo de la cuestión... asoma la "sorpresa" que usar lambdas en Java no es ninguna novedad.
Solo hay que esperar a que se lance JavaSE 1.8 para que desaparezcan las limitaciones a la fecha.
@jmarranz, si te vas a un extremo, todo lenguaje de programación es "azucar sintáctico" del ensamblador o código máquina.
El tema es ver qué ventaja tiene un lenguaje funcional frente a otro OO o imperativo. Según muchos autores es básicamente ¡lo que no tiene!, que es la mutabilidad de las variables.
Esta inmutabilidad es la que provoca que se deba pensar cada algoritmo de modo diferente al "habitual" en OO o imperativo, pues no hay iteradores como tales, en general, sino recursión (tail recursion, etc..) así como otras muchas implicaciones.
Al final, Scala, en un "compromiso" para no espantar del todo al "javero" típico, permite tanto val como var.., lo que puede llevar quizás a más líos que otra cosa.
En cualquier caso, mi opinión es que el incluir demasiado tema funcional (o dinámico) puede llevar a problemas de mantenimientos, y no pienso en la gente con cierta motivación que normalmente curiosea en Javahispano o similares, sino en el programador "average" con motivación de cárnica que recibe un mantenimiento de tercera mano.
Saludos.
asertus amén
Después del amén, asertus, ya por fin tengo un rato para seguir el tema.
Los hype-makers suelen tener como misión, para volver a ser estrellas con su nuevo hype y llenar sus cuentas con sus "consultorías" y ponencias en congresos, el oponer el hype de turno con el hype anterior y que el hype nuevo es lo más y el hype antiguo (del que sacaron todo lo posible en su momento) pues no mola, es lo peor y hay que dejar de usar.
Esto va por lo de "qué ventaja tiene un lenguaje funcional frente a otro OO o imperativo", yo veo el rollo funcional como una vuelta de tuerca más el tema de la reutilización de código y por ahora no mucho más porque lo de la inmutabilidad, trabajar en copias de datos etc pues aparte que de "nuevo" tiene cero, como que no veo que el tratamiento de eso tenga que ser siempre a través de funciones de primer nivel y tirar a la basura 30 años de OOP por el interés de un guru de turno, ya sea guru de academia-no-hago-nada-en-el-mundo-real o guru de conferencia-yo-ya-no-hago-nada-en-el-mundo-real. Digamos que me pilla mayor para creer en "ideas puras" (funciones puras sin estado y sin efectos laterales).
A donde quiero llegar es que veo algunas ideas funcionales como pura micro-programación (programación a bajo nivel) y como un sobreesfuerzo por la modelización algorítmica (que a eso último desde luego me apunto), pero llevado al extremo las ideas del mundo funcional terminan en un mundo tipo C pero con más glamour (quizás me equivoque pero no lo veo) y por mi parte va a ser que no, por lo menos por ahora, esto lo digo por los que quieren, interesadamente, contraponer la programación funcional con la programación orientada a objetos.
A lo más que se va a llegar en Java es a:
- "esconder" los iteradores y las restricciones tras métodos
- usar un "fluent api" para "concatenar" todo lo anterior
- eliminar las clases anónimas
- todo ello aderezado con una sintaxis "closure"
Los "fluent api" ya se están utilizando: véanse el "builder pattern", que no es ninguna novedad, y el "factory pattern" combinado con el anterior, que es menos novedad todavía.
De ahí querer deducir que Java deriva hacia la programación funcional, es una pirueta sin red. Y plantearse problemas de mantenimiento a causa de ello, es otra pirueta a más altura, y con menos red.
Cada vez que el lenguaje cambia, y se añaden "cosas nuevas", siempre habrá problemas, primero de diseño, y después de mantenimiento. Pero ambos están directamente relacionados con el conocimiento detallado de las novedades. Como siempre ha sido.
Lo que no puede un lenguaje, bajo ningún concepto, es quedarse estancado porque se avizoran "problemas" en la implantación y mantenimiento de las novedades.
Al ver este post he recordado este vídeo de JetBrains, http://tv.jetbrains.net/videocontent/memoization-for-java , donde básicamente incluyen, con anotaciones y su MPS, la inmutabilidad y "caché" de resultados de funciones en Java.
Saludos
Creo que las cosas están un poco mezcladas. No me parece que la idea sea migrar Java aun modelo de programación funcional, sino mas bien utilizar conceptos de la programación funcional que puedan hacer mas sencillas ciertas tareas. Concuerdo con aquellos que mencionan que el hype es alto, pero eso no debería ser suficiente como para descartar cualquier idea nueva. Como bien alguien explico anteriormente, el tail recursion puede ser muy beneficioso, al igual que conceptos simples como map o reduce. Si, ya existe el soporte de definiciones como las closures pero, ¿Alguien puede realmente creer que es la mejor manera con la que se cuenta actualmente? Creo que en el software hay un común denominador muy simple, el de evolucionas o mueres. No creo que el soporte de criterios funcionales en Java sea una prioridad, pero si los mismos son bien creados, estoy seguro que van a sumar posibilidades mas que restringirlas. Siempre ha sido responsabilidad de quien usa una herramienta el saber usarla. No me gusta la idea de un lenguaje que se interponga ante una solución simplemente porque creen que quien lo usa puede cometer un error.
Saludos.
@choces
Respecto a lo que comentas de "Lo que no puede un lenguaje, bajo ningún concepto, es quedarse estancado porque se avizoran "problemas" en la implantación y mantenimiento de las novedades."
Estamos de acuerdo en ello sólo planteamos la dificultades que creemos que aparecerán, en ningún momento estamos planteando decir "Quietorrr no lo toques".
No voy a leer todos los comentarios, la programación funcional es más vieja que la programación OO y fue todo un paradigma de altísima evolución, el problema principal de la programación funcional es que requiere PENSAR ANTES DE ESCRIBIR.
Los paradigmas como la OO son muy lindos haciendo dibujitos, pero son terriblemente difíciles de verificar, la mayoría de los que pretenden hacer algo bien se ven atados de manos dado que es ultra difícil garantizar que algo hace lo que tiene que hacer.
En ello ha ido que desarrollaran esa niñada de estudiante universitario de los "test cases" en implementaciones como junit y otros cientos de equivalentes. ¿Y qué resultado les ha dado eso de los tests? ¿por tener 100 o 200 tests es más o menos fiables? ¿ponen las manos en el fuego por sus propios programas?... yo creo que no.
La programación funcional se extrapola directamente a la lógica, con verificaciones completas aún de secciones parciales del programa, es posible garantizar que algo hace lo que tiene que hacer, es posible probar que una pieza de código equivale a otra e intercambiarla sin ningún efecto lateral... bah es algo que realmente es avanzado, útil y donde el tiempo se usa para pensar, porque luego escribes un programa en 3 líneas...
Java (y su hermanito gemelo .Net) desde hace tiempo que vienen introduciendo cosas de la programación funcional: funciones anónimas, listas por extensión y comprensión, notaciones con pattern matching...
La realidad es que los programadores Java van a usar los pedacitos de programación funcional que incorporen como una especie de macro para hacer dos boludeces y van a seguir inmersos en sus suites de testeo inmensas e incompletas, produciendo software sin ninguna garantía y metiendo cada vez más productos "enlatados" en sus proyectos porque "tengan una xxxx que va de bien para hacer yyyy"