Barrapunto

En general las desventajas que veo a lenguajes como Haskell (no tengo experiencia en otros) es que las operaciones que no sean una función en el puro estricto matemático son un poco más coñazo. Por ejemplo, una función que te devuelva un número aleatorio (que debe ser distinto cada vez). Ahí es dónde entran en juego las mónadas, que suelen aprenderse mal y luego usarse mal.

En favor de estos lenguajes debo decir que he visto gente que aprendió haskell como primer lenguaje y son PUTOS AMOS en programación.

El problema es que tiene tantas cosas buenas (ver el artículo para tener más referencias) que uno se acostumbra y luego le da por saco no poder pasar funciones anónimas como argumento, no poder hacer pattern matching, evaluación perezosa,...

Y por último, os dejo una pequeña perlita para que veáis a dónde llega Haskell:

Una lista de enteros se representa como [Int].

+ (el operador) es en realidad una función que toma dos argumentos numéricos del mismo tipo y te da un tercer valor.

Pero si a + le das un argumento, "se convierte" en una función que recibe un argumento (el segundo sumando), y te da un valor.

Por ejemplo, (1+) es una función (y esto es sintaxis Haskell) que recibe un sumando y le suma 1.

Existe una función llamada map que toma una lista de elementos del mismo tipo (a), una función que toma elementos de tipo a y devuelve elementos de tipo (b) (es decir, no necesariamente el mismo tipo que su entrada), y la aplica a todos los elementos de la lista.

Por lo tanto:
map (1+) [1,2,3] es [2,3,4]
map (2*) [1,2,3] es [2,4,6]

¿Cómo haces un map genérico en Java?

El problema es que he leído que la mayoría de los ordenadores actuales no están preparados para esta clase de lenguajes, por lo que suelen usar demasiada pila y desaprovechan muchos recursos de las computadoras que están mas bien pensados para la programación imperativa. (no se si estoy dando palos de ciego, que alguien lo confirme o lo rebata)

Personalmente he programado en CAML y tras unas dos semanas de dolores de cabeza todo empezaba a salir solo, creas funciones pequeñitas que luego las llaman más funciones pequeñitas y al final el programa entero es una función de poco mas de una linea jeje viene bien para luego cuando programas en lenguajes, como dirían los ceceros "de verdad" por que esa mentalidad luego es buena por que elimina muchos malos hábitos como variables globales, gotos y demás, lo malo es que las funciones que haces son muy pequeñas y hay demasiadas llamadas a subrutina, por lo que la eficiencia se resiente algo, aunque el mantenimiento es sencillísimo

Lo que no me veo es creando un programa de transferencias bancarias en CAML xDDDD

Que no es muy buena.

Tuve una asignatura llamada "Programación Declarativa". Empecé aprendiendo Prolog. Al principio muy bien, me sorprendió mucho el nuevo enfoque y resultaba emocionante.

Pero cuando tuvimos que hacer cosas más avanzadas, lo que hicimos fue aprender cómo funcionaba el intérprete, para simular sentencias de control de flujo (whiles, for, ...). Para eso, uso C.

Después dedicamos un poquito de tiempo a Lisp. Su rasgo más sorprendente es que no existía operador de asignación. Así que lo primero que aprendimos fue a simularlo.

En resumen, aprendimos cómo programar imperativamente en un lenguaje declarativo. Como decía otro profesor, para esos viajes no necesitábamos esas alforjas.

Da igual con que programes. Los lenguajes de programación no son más que una herramienta, y el código que ejecuta la CPU es imperativo. ¿Y si me coche funciona con gasolina, para que echarle agua o queroseno (por muy bueno que sea)? O, ¿si me da por hablar con una persona que sólo habla Castellano en Inglés, por que éste es más eficiente? Pues pasan cosas como éstas [debian.org] Claro que hay lenguajes que facilitan ciertas tareas, que son mas metódicos en ciertos aspectos, o simplemente son otros modelos de programación. Cada uno tiene sus virtudes y sus defectos, y uno tiene que conocerlos para saber en que campos se pueden utilizar, y así sacar provecho de cada uno. Pero no olvidemos, que al final, todos se puede hacer con los lenguajes de siempre. ¿A qué venia todo esto? Pues que ahora está muy de moda hablar de ciertos lenguajes "nuevos" magnificando un sus virtudes. Así que un apoyo desde aquí a los de toda la vida! :D PD: Muy completo el articulo de Functional Programming :)

Imaginad... un compilador que, a partir de un algoritmo (formulado en C++, Pascal, basic) fuera capaz de generar un binario consultando bases de datos de códigos ya generados de comportamiento idéntico y rendimiento óptimo. ¿Existe algo similar?
Por otro lado, ¿existe algún tipo de guía para seleccionar las mejores herramientas según el proyecto a llevar a cabo? del tipo "este lenguaje mejor para este micro y este otro mejor para proyectos científicos"

Vaya manera de comentar un post, sembrando más dudas...

Decide tus objetivos.

Evalua las herramientas.

Y elige una.

Los lenguajes funcionales tienen un nicho que está enfocado al objetivo del programa que se esté haciendo. Matemáticas intensivas, programacion de algoritmos geneticos, evaluacion semántica y similares.
Me encantan los lenguajes funcionales (principalmente lisp y prolog, que es como un ser mixto). Pero NUNCA he tenido que elegir uno para ninguna de las tareas que he realizado en los últimos 12 años. (vamos, nunca fuera de una practica de universidad)

¿te gusta haskell? pues encantado. Pero el gusto no tiene nada que ver (salvo para elegir lenguaje cuando la tarea lo requiera).

La mayoría de los problemas triviales en el 99.9 por ciento de los programas que se hacen se vuelven monstruos incongruentes si se intentan realizar con programacion funcional.

Igual que cualquier problema trivial para el que la programacion funcional es perfecta se puede convertir en imposible de solucionar fuera de ella.

Pero en fin, esto me recuerda a la disyuntiva sobre programacion recursiva/no recursiva. Es exactamente lo mismo. No sirven para hacer las mismas cosas.

Haskell Tutorial for C Programmers - http://www.haskell.org/~pairwise/intro/intro.html [haskell.org] Un excelente recurso cuando has contaminado tu manera de pensar con los lenguajes imperativos e intentas empezar a programar con algún lenguaje funcional. (dirigido a haskell, pero es indiferente)

En su día vi una librería de java que interpreta Lisp, pero usando incluso los objetos de java (en freshmeat.net he visto esto pero no estoy seguro que fuera la que vi en su día: http://freshmeat.net/redir/jacol/20454/url_homepag e/jacol.sourceforge.net [freshmeat.net]). Lo bueno sería poder usar desde un lenguaje otro para hacer una función aparte si necesita otro estilo de programación.