functional programming - programacion - ¿Es Erlang realmente un lenguaje funcional?

functional programming python (4)

Escucho todo el tiempo que Erlang es un lenguaje funcional, sin embargo, es fácil llamar a bases de datos o código libre de efectos secundarios desde una función, y los comandos se ordenan fácilmente usando comas "," entre ellas como Ruby u otro idioma Entonces, ¿dónde está la parte "funcional" de Erlang?

Hay un meme de que los lenguajes funcionales deben tener valores inmutables y estar libres de efectos secundarios , pero digo que cualquier lenguaje con funciones de primera clase es un lenguaje de programación funcional.

Es útil y poderoso tener fuertes controles sobre la mutabilidad del valor y los efectos secundarios, pero creo que estos son periféricos a la programación funcional. Es bueno tenerlo, pero no es esencial. Incluso en los idiomas que tienen estas propiedades, siempre hay una manera de escapar de la pureza del paradigma. ¹

Hay un continuo en escala de grises entre los lenguajes de PF realmente puros que no se puede usar para nada práctico y los lenguajes que son realmente impuros pero que aún tienen algo de naturaleza de PF:

Libro FP: los libros introductorios sobre idiomas de FP con frecuencia solo muestran un subconjunto del lenguaje, con todos los ejemplos realizados dentro del REPL del lenguaje, para que nunca pueda ver cómo se rompe el paradigma puramente funcional. Un buen ejemplo de esto es Scheme como se presenta en The Little Schemer .
Puede dejar de leer un libro así con la falsa impresión de que los idiomas de FP no pueden hacer nada útil.
Haskell: los creadores de Haskell hicieron todo lo posible para aislar la impureza a través de la famosa mónada de E / S. Todo en un lado de la pared es puramente funcional, de modo que el compilador puede razonar con confianza sobre el código.
Pero lo importante es que, a pesar de la existencia de este muro, tienes que usar la mónada de E / S para hacer algo útil en Haskell. ² En ese sentido, Haskell no es tan "puro" como algunos quieren que creas. La mónada de E / S le permite crear cualquier tipo de software "impuro" que le guste en Haskell: clientes de base de datos, GUI altamente estaduales, etc.
Erlang: tiene valores inmutables y funciones de primera clase, pero carece de un muro sólido entre el lenguaje central y los bits impuros.
Erlang se envía con Mnesia , un DBMS en memoria respaldado en disco, que es casi tan impuro como el software. Es apenas diferente en la práctica de una tienda de variables global . Erlang también tiene un gran soporte para comunicarse con programas externos a través de ports , sockets , etc.
Erlang no impone ningún tipo de política de pureza a usted, el programador, a nivel de idioma. Solo te da las herramientas y te permite decidir cómo usarlas.
OCaml y F #: Estos lenguajes multiparadigmáticos estrechamente relacionados incluyen tanto elementos puramente funcionales como características imperativas y orientadas a objetos.
Los bits de programación imperativos le permiten hacer cosas como escribir un bucle for tradicional con una variable de contador mutable, mientras que un programa de FP puro probablemente trataría de repetir en una lista para lograr el mismo resultado.
Las partes OO son bastante inútiles sin la palabra clave mutable , que convierte una definición de value en una variable , de modo que el compilador no se quejará si cambia el valor de la variable. Las variables mutables en OCaml y F # tienen algunas limitaciones, pero puede escapar incluso a esas limitaciones con la palabra clave ref .
Si está utilizando F # con .NET, va a estar mutando valores todo el tiempo, porque la mayoría de .NET es mutable, de una forma u otra. Cualquier objeto .NET con una propiedad configurable es mutable, por ejemplo, y todas las cosas de la GUI inherentemente tienen efectos secundarios. La única parte inmutable de .NET que viene inmediatamente a mi mente es System.String .
A pesar de todo esto, nadie diría que OCaml y F # no son lenguajes de programación funcionales.
JavaScript, R, Lua, Perl ...: hay muchos idiomas incluso menos puros que OCaml que aún pueden considerarse funcionales en cierto sentido. Tales lenguajes tienen funciones de primera clase, pero los valores son mutables por defecto.

Notas al pie:

Cualquier lenguaje FP realmente puro es un lenguaje de juguete o el proyecto de investigación de alguien.
Es decir, a menos que su idea de "útil" sea mantener todo en el REPL de ghci . Puede usar Haskell como una calculadora glorificada, si lo desea, por lo que es puro FP.

La idea central es que cada proceso es un programa funcional sobre un flujo de entrada de mensajes. El resultado del programa funcional es un flujo de salida de mensajes a otros. Desde esta perspectiva, Erlang es un lenguaje funcional bastante limpio; no hay actualizaciones destructivas para las estructuras de datos (como setcar en Lisp y la mayoría de los Esquemas).

Con pocas excepciones, todas las funciones integradas, como las operaciones en las tablas ETS, también siguen este modelo: aparte de los problemas de eficiencia, esos BIF podrían realmente implementarse con procesos de Erlang puros y paso de mensajes.

Entonces, sí, el lenguaje Erlang es funcional, pero una colección de procesos interactivos de Erlang es algo diferente. Cada proceso es un cálculo continuo y, como tal, tiene un estado actual, que puede cambiar en relación con los otros procesos. Incluso una base de datos es solo otro proceso a este respecto.

En mi opinión, esta es una de las cosas más importantes acerca de Erlang: fuera del proceso, podría haber una tormenta, pero en el interior, las cosas están en calma, permitiéndole enfocarse en lo que ese proceso debería hacer, y solo eso.

La parte funcional es que tiendes a pasar por encima de las funciones. La mayoría de los idiomas se pueden usar como lenguaje funcional y como lenguaje imperativo, incluso C (es bastante posible crear un programa que conste solo de punteros y constantes de función).

Supongo que el factor distintivo suele ser la falta de variables mutables en los lenguajes funcionales.

Sí, es un lenguaje funcional. No es un lenguaje funcional puro como Haskell, pero, de nuevo, tampoco lo es LISP (y nadie realmente argumenta que LISP no es funcional).

El manejo del proceso / paso de mensajes de Erlang es una implementación del modelo Actor. Se podría argumentar que Erlang es un lenguaje de actor, con un lenguaje funcional utilizado para los actores individuales.