¿No es el paradigma funcional demasiado divergente con el hardware subyacente para ser generalmente eficiente?

Hay un gran malentendido en la inmutabilidad.

La inmutabilidad es una característica de la semántica, pero no implica inmutabilidad en la implementación.

Un ejemplo simple es la implementación de la pereza.

Cuando los cálculos son perezosos, el resultado de una expresión es conceptualmente un valor, pero la implementación subyacente es un procesador que contiene los argumentos que deben evaluarse y una función para crear el valor, así como una ranura para almacenar el valor. .

La primera vez que solicitará (en el idioma) el valor, el cálculo se realizará, se evaluará su resultado y se le devolverá el valor (o un identificador).

Esto es transparente en la semántica del lenguaje, y todo lo que sabe es que esta variable se ha vinculado a un valor (o un valor futuro) y que una vez que está listo, no puede cambiar el valor que se devolverá. La representación de la memoria subyacente cambiará, pero usted no lo sabrá.

La misma diferencia semántica / de implementación existe en casi cualquier idioma y, de hecho, está en el corazón de la optimización . Cualquiera que sea el idioma, la semántica garantiza algunas cosas, pero deja otras sin especificar para dejar espacio para la optimización.

Ahora, es cierto que los lenguajes prácticamente funcionales no son tan rápidos como C ++, por ejemplo. Sin embargo, Go (que todavía es bastante exagerado) es más lento que Haskell o Lisp, y también lo es C # Mono ( source ).

Cuando vea cuán poco confiable puede ser C ++ o C para obtener esas actuaciones, es posible que desee dejar pasar un poco.

Cuando se da cuenta de que Haskell está creciendo rápidamente hoy en día, y todavía hay mucho espacio para la optimización en su compilador / tiempo de ejecución (GHC acaba de cambiar recientemente a LLVM, por ejemplo, Microsoft Research está financiando activamente las mejoras en tiempo de ejecución), podría estar dispuesto apostar a que va a mejorar pronto.

Diversión: Un juego con expresiones regulares o cómo un equipo de Haskell creó un comparador de expresiones regulares que supera a re2 , la biblioteca de C de Google, en varios escenarios.

El paradigma funcional es útil para dividir cosas en un ámbito estrecho. Esto es algo realmente bueno considerando la evolución de la computadora.

La CPU multinúcleo tiene grandes problemas relacionados con los recursos compartidos y los costos de sincronización son realmente elevados. El paradigma funcional permite una manera natural de expresar programas que no tienen estos problemas. Esto es realmente bueno para el paralelismo.

Además, estamos utilizando granjas de servidores cada vez más con SaaS y cloud computing. Por lo tanto, la misma aplicación tiene que ejecutarse en varias máquinas. En esta posición, los costos de sincronización son aún más costosos. Google ha realizado algunos trabajos y ha publicado algunos trabajos de investigación sobre la programación funcional y el algoritmo que puede escribir. Esto es clave para ellos porque tienen un problema de escalabilidad.

Además, puede hacer fácilmente una pila en el montón de la computadora, e incluso una no continua utilizando listas vinculadas. Esto se hace para generar un seguimiento de pila en muchos lenguajes de programación. Así que esto no es un problema.

OK, la programación funcional implica algunas limitaciones. Pero también brinda una forma natural de expresar las problemáticas que tenemos en la informática moderna, que son extremadamente difíciles de manejar en los paradigmas a los que estamos acostumbrados. La escalabilidad es uno de ellos, y se está convirtiendo en un verdadero negocio.

Todos los que ya se ocupan de un sistema paralelo complejo saben de lo que estoy hablando.

Así que mataría la respuesta. Sí, la funcionalidad tiene problemas con el hardware moderno, pero la programación tradicional también la tiene. Como siempre, encontrarás ventajas y desventajas. El punto es saber cuáles son para que pueda tomar la decisión adecuada cuando sea necesario.

Realmente no tengo una respuesta, ya que no conozco el estado actual o incluso lo difícil que sería, pero solo porque el compilador asegure esas cosas desde la entrada, no significa necesariamente que la salida los tendría En teoría, un compilador lo suficientemente inteligente podría pasar por alto todos estos problemas, pero en la práctica, probablemente siempre existirá.

Sin embargo, otra forma de verlo es mirar el historial de la máquina Lisp. Si recuerdo correctamente, originalmente fueron diseñados para superar los mismos problemas que Lisp tuvo con la diferencia de las máquinas en ese momento. El desarrollo de estas máquinas finalmente se detuvo, ya que las computadoras de escritorio se volvieron lo suficientemente rápidas para hacer que las ineficiencias sean más baratas para vivir que para soportar otra máquina.

En general, a excepción de la aplicación más crítica de rendimiento, los lenguajes de FP aún son lo suficientemente rápidos. Al elegir cualquier idioma de nivel superior, estará dispuesto a disminuir la prioridad en el control y el rendimiento del ajuste fino para que sea más seguro, más fácil, más fácil de mantener o alguna otra prioridad.

Al final, la programación tiene que ver con las compensaciones, por lo que solo hay que elegir lo que más importa para el proyecto en cuestión.

Es cierto que el paradigma funcional implica inmutabilidad y apatridia, pero no tenemos ningún lenguaje de programación completamente puro. Incluso el más puro, Haskell, permite efectos secundarios.

Dicho esto, para responder a tu pregunta sobre la eficiencia, he usado tanto Haskell como Clojure, y tampoco he notado ningún problema de rendimiento.