Barrapunto

No se hizo la miel para la boca del asno.
Yo, por mi parte, veo un hueco interesante en el que poder reciclarme y dedicarme a hacer algo interesante, dentro de lo enormemente aburrida que es la informática laboral.
Si eres capaz de convencer a tu jefe de que esto merece la pena, eres bueno y se pone de moda, será un trabajo muy valorado (porque en cosas como la programación funcional es donde se diferencia un picateclas de un ingeniero) e interesante.
Además, es especialmente adecuada la utilización de este tipo de lenguajes en entornos de gestores de BD, porque ya ofrecen un interfaz muy declarativo. Me parece un ambiente en que la programación funcional encaja de modo muy natural y que puede ser extremadamente potente. Desde crear triggers para actualizaciones de vistas hasta poder devolver estructuras de datos complejas (árboles de todo tipo) directamente desde las tablas relacionales; si además hacen estop último con evaluación perezosa, la cosa puede ser pa cagalse.

No niego las cosas buenas de scheme, pero...
¿Tiene sentido tener que acceder al tercer elemento de un vector con expresiones como esta?

(car (cdr (cdr color)))

Es un vector de tres elementos, y así se accedería al tercero. Ni me imagino como será para acceder al elemento 160. Mi opinión, es que sería más fácil acceder al elemento 3 mediante color(3), color[3], color.3 o expresiones similares.
Por supuesto que los lenguajes como scheme tienen sus ámbitos de utilidad, pero yo lo que critico es el lenguaje en si, el no disponer de un sistema de manejo de vectores mejor.
scheme básico para GIMP [gimp.org.es] (ni os digo como será scheme avanzado...)
Para los que sigais pensando que me equivoco, pensad en cómo se resolvería un complejo árbol sin perder horas en corregir bugs.

No creo que el PH critique a la programación funcional en sí, si no a las S-expresiones. En mi opinión, están muy bien para representar datos, pero para el código... Dios, la sintáxis de los diversos dialectos de Lisp es amargante, para cualquier cosa hay que escribir millones de paréntesis.

En cuanto a las estructuras de datos potencialmente infinitas, eso viene dado por la evaluación perezosa, no porque el lenguaje sea funcional. Por diversos motivos, normalmente sólo se usa con lenguajes funcionales puros, como es el caso de Haskell (lenguaje que cada día me gusta más).

Por cierto, Common Lisp no es funcional, es un híbrido extraño entre varios paradigmas.

La teoría difiere de la práctica. El conocimiento previo de programación también. La mayoría de las personas que manejan bases de datos hoy en día tienen unos conocimientos y bagaje en programación imperativa mayor que en funcional, lo cual debería tomarse en cuenta. Conviene tener en cuenta que pese a que a la programación funcional muy probablemente *no* es más difícil que la imperativa entérminos generales, en términos prácticos puede que lo sea.

Pero lo que me ha impulsado a contestarse ha sido sin duda aquello de "los lenguajes no son fáciles o difíciles (en mi opinión)". Pues yo opino que si. Brainfuck por ejemplo resulta intratable (dificil de usar) debido a su poca (sencilla) capacidad expresiva. Y los hay aun peores! Más bien diría "los paradigmas de programación no tiene porqué son fáciles o difíciles per se", y aun así no estoy muy seguro de ello. Cada lenguaje usa un paradigma u otro (o varios) de distinta manera, con mayor o menor complejidad de aprendizaje y manejo, con mayor o menor éxito facilitando el desarrollo de éste o este otro tipo de programas. Pero para la mente humana, hay lenguajes más difíciles que otros. Supongo que también habrá pardigmas más complicados de entender que otros, al igual que ocurre con las leyes de newton respecto a las teoría de la relatividad de Einstein. Un lenguaje tipo INTERCAL [wikipedia.org] con sus famosos COMEFROM (en vez de GOTO) es un claro ejemplo de "lenguaje más difícil que otros".