Barrapunto

No se, pero yo he visto un poco la programación en scheme, y me parece masoquista. No tanto como brainfuck o blank, pero si demasiado simple.
Para empezar, los vectores y matrices no son ni de lejos tan cómodos como otros lenguajes, para continuar, los comentarios son de como mucho, una linea (no como C, que con cuatro caracteres puedes invalidar muchas lineas de código, y así comprobar que el fallo no esté ahí), y para colmo, todo son paréntesis, cuando en C (y otros lenguajes), tienes paréntesis, corchetes y llaves, para no hacerse lios de paréntesis.
Personalmente, creo que scheme es un lenguaje muy complicado. Y en el caso de Script-fu de GIMP, me parece aún peor, porque script-fu debería perseguir la sencillez, para permitir a la gente hacer sus propios scripts fácilmente. En este último caso, un lenguaje como Basic, hubiera sido mejor (al menos en la sencillez de programación), y para otras aplicaciones, no se que ventaja puede tener scheme respecto a otros lenguajes.

Es sorprendente ver a la gente intentar comparar un lenguaje funcional como Scheme, Lisp o ML con los lenguajes imperativos estilo C, C++, C#, Java, ADA, Pascal o PL/SQL. Utilizan paradigmas diferentes, es decir, a la hora de programar debes pensar de forma diferente.

Programar en lenguaje funcional es muy diferente a hacerlo en un lenguaje imperativo. De hecho debes volver a aprender a programar. La ventaja es que luego según que cosas resultan mucho más fáciles de implementar en funcional que en imperativo. Por ejemplo, la implementación de una estructura de árbol balanceado en C o cualquier otro lenguaje imperativo es una cantidad de código considerable (no me refiero a usar una biblioteca que implemente un árbol, sino la programación del mismo desde las primitivas del lenguaje). En un lenguaje funcional se puede hacer con menos de cinco líneas de código (no ofuscado).

Por supuesto, PL/scheme no supone demasiadas ventajas para los programadores de lenguajes imperativos, pero para los programadores de lenguajes funcionales debe de ser una auténtica delicia.

Sinceramente no sé que le veis de complicado a Scheme, especialmente a su sintaxis. Os insto a que construyais una consulta con dos subquerys anidadas en SQL, y entonces diréis: "Coño, esto es igual a Lisp, hasta tiene la misma cantidad de paréntesis (excepto los más externos, que en realidad podrían ser retirados también de los intérpretes de Lisp, si no me equivoco demasiado... aunque tampoco tendría mayor relevancia).

La sintaxis de Lisp, y especialmente de Scheme, no sólo no es compleja, sino simplísima. Piensa que en otros lenguajes tienes llaves, paréntesis, corchetes, puntos, punto y comas, dos puntos, etc., y en Scheme tienes... paréntesis. Punto. Además, en este último no tienes por qué usar sólo paréntesis, también puedes emplear corchetes, y no recuerdo si algún otro símbolo también vale. De hecho, el problema de Lisp, para la mayoría de los que se quejan -a veces con razón, todo sea dicho-, es que su sintaxis es demasiado simple. A mí tampoco me gustaba nada la fricada de los paréntesis al principio, pero cuando le das una oportunidad al lenguaje, te acostumbras enseguida.

Y los paréntesis no están ahí gratuítamente. Por un lado, intenta programar con un paradigma pseudo-funcional en C, o (casi) funcional en Python. Dejando de lado que C no tiene un tipo "función" -lo que te obligaría a trabajar con punteros a funciones-, acabarías con expresiones del tipo:

f(x(g(a(b,c,v(z,2)),m)),d,4)

sencillísimo, oiga (¿alguien había dicho algo de paréntesis?). Por otro lado, una de las cosas más potentes del lenguaje está en que el código es muy fácilmente expresable como datos. He ahí la que quizá sea la mayor razón de ser de los paréntesis. Ello te permite la potencia de las macros -que no tienen casi nada que ver con lo que se entiende por macro en el resto de lenguajes-, o poder construír el operador amb mediante llamadas a call-cc, escribiendo la infraestructura necesaria para varios tipos de programación declarativa en apenas diez o veinte líneas.

¿Programación funcional? Ya la tienes. ¿Quieres programación iterativa? La construyes. ¿Quieres programación declarativa? Lo mismo. ¿Un sistema de objetos? Ídem. ¿Sistemas distribuídos basados en agentes? Tengo un amigo que ha hecho el proyecto de fin de carrera sobre el tema, y al final decidió usar Scheme. Desde esa, es un acérrimo defensor del lenguaje. Afirma que, por ejemplo en Java, como había pensado inicialmente, le habría llevado el triple de tiempo, y siendo optimista. Por su culpa yo también he aprendido algo de Scheme, y ¡aún sin haber programado absolutamente nada de provecho en dicho lenguaje!, cuando uso cualquier otro, estoy continuamente echando de menos alguna característica (casi siempre, las macros: los patrones de diseño serán muy útiles, pero son una mierda cuando tienes cosas más potentes :-)

Al final, la verdadera utilidad de Lisp reside en poder construir, sobre el mismo, un lenguaje específico a tu problema, para a continuación -o para ceñirnos mejor a la realidad, de forma paralela- resolverlo en él. Y sí, es cierto que algunas clases de problemas se resuelven mejor en otros lenguajes. Pero para eso están. Los lenguajes de programación NO SON EQUIVALENTES. Siempre podrás resolver tu problema en cualquier lenguaje Turing-completo si dispone de unas bibliotecas de comunicación con el exterior adecuadas (E/S, red, BB.DD., web, GUI, etc.). Las dos cuestiones a plantearse son: a) la eficiencia de cara a los humanos / programadores / desarrolladores / etc. y b) la eficiencia de cara a la máquina. Y la segunda es importante, pero lo es mucho más la primera.

Estoy de acuerdo en algo: Scheme no es para principiantes -y puede que tampoco para gente ya con cierto bagage-. No, al menos, para los que vienen desde la programación "clásica": la mayoría. Pero los que aprenden a usarlo siempre aprecian que esté ahí. No creo que sea un problema tener un Lisp a tu disposición en cosas como Emacs, Autocad, Gimp o bases de dato