¿Es Erlang realmente un lenguaje funcional?

Question

Oigo todo el tiempo que Erlang es un lenguaje funcional, sin embargo, es fácil llamar bases de datos o código libre de efecto secundario de una función, y los comandos se ordenan fácilmente usando "," comas entre ellos como Ruby u otra idioma, entonces, ¿dónde está la parte "funcional" de Erlang?

Answer 1

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 realmente podrían haberse implementado con procesos Erlang puros y transmisión de mensajes.

Así que sí, el lenguaje de Erlang es funcional, pero una colección de procesos de Erlang que interactúan 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 de Erlang: fuera del proceso, podría haber una tormenta furiosa, pero por dentro las cosas están tranquilas, permitiéndote enfocarte en lo que ese proceso debería hacer, y solo eso .

Answer 2

La parte funcional es que tiende a pasar las funciones. La mayoría de los lenguajes pueden usarse tanto como un lenguaje funcional, como un lenguaje imperativo, incluso C (es bastante posible hacer un programa que consista solo en punteros y constantes de función).

Supongo que el factor distintivo es generalmente la falta de variables mutables en los lenguajes funcionales.

Answer 3

Sí, es un lenguaje funcional. No es un lenguaje funcional puro como Haskell, pero tampoco es LISP (y nadie defiende realmente que LISP no sea funcional).

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

Answer 4

Hay un meme que los lenguajes funcionales deben tener immutable values y ser side-effect free, pero digo que cualquier lenguaje con first-class functions es un lenguaje de programación funcional.

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

Hay un continuo de escala de grises entre las lenguas verdaderamente puros de PF que no se puede utilizar realmente para nada práctico y lenguajes que son realmente muy impura, pero todavía tiene algo de la naturaleza de FP a ellos:

• Libro FP: Los libros introductorios sobre lenguajes FP a menudo muestran solo un subconjunto del idioma, con todos los ejemplos hechos dentro del lenguaje REPL, de modo que nunca se llega a ver que se rompa el paradigma puramente funcional. Un buen ejemplo de esto es el esquema presentado en The Little Schemer.

  Puede dejar de leer un libro con la falsa impresión de que los lenguajes de FP no pueden hacer nada realmente útil.

• Haskell: Los creadores de Haskell fue a longitudes no comunes a la pared fuera de impurezas a través de la famosa I/O monad. 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, tiene que usar la mónada de E/S para obtener útil hecho en Haskell. En ese sentido, Haskell no es tan "puro" como algunos quisieran que creyeras. La mónada de E/S le permite construir cualquier tipo de software "impura" te gusta en Haskell: Los clientes de bases de datos, interfaces gráficas de usuario altamente con estado, etc.

• Erlang: tiene valores inmutables y funciones de primera clase, pero le falta una pared fuerte entre el lenguaje central y los bits impuros.

  Erlang se envía con Mnesia, un DBMS en memoria con respaldo de disco, que es casi tan impuro como el software. En la práctica, no es muy diferente de una tienda global variable. 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 para usted, el programador, en el nivel del idioma. Simplemente le da las herramientas y le permite decidir cómo usarlas.

• OCaml y F #: Estos lenguajes multiparadigma estrechamente relacionados incluyen tanto elementos puramente funcionales como imperativos y características orientadas a objetos.

  Los bits de programación imperativa le permiten hacer cosas como escribir un bucle for tradicional con una variable de contador mutable, mientras que un programa de FP puro probablemente intentaría recurse sobre una lista para lograr el mismo resultado.

  Las partes OO son bastante inútil sin la mutable keyword, que convierte una definición value en un variable, por lo 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 de esas limitaciones con la palabra clave ref.

  Si está usando F # con .NET, va a estar mutando de 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 características de la GUI tienen efectos secundarios intrínsecamente. La única parte inmutable de .NET que inmediatamente viene a la mente es System.String.

  A pesar de todo esto, nadie discutirí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 todavía se pueden considerar funcionales en algún sentido. Dichos lenguajes tienen funciones de primera clase, pero los valores son mutables por defecto.

---

Foototes:

1. Cualquier lenguaje FP verdaderamente puro es un proyecto de investigación toy language o de alguien.

2. Es decir, a menos que su idea de "útil" sea mantener todo en ghci REPL. Puedes usar Haskell como una calculadora glorificada, si quieres, entonces es pura FP.