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?¿Es Erlang realmente un lenguaje funcional?
Respuesta
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 .
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.
Entonces, ¿tal vez Erlang y otros similares deberían llamarse idiomas no mutables? – Zubair
@Zubair: Tal vez, pero creo que es más el hecho de que el lenguaje en sí mismo hace que sea más fácil trabajar con funciones en lugar de variables. Supongo que el nombre se deriva del análisis funcional de las matemáticas (http://en.wikipedia.org/wiki/Functional_analysis), pero esa es solo mi especulación. – falstro
Ok, eso tiene sentido, gracias – Zubair
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.
Estoy bastante seguro de que hay personas en la comunidad de Haskell que argumentarían que Lisp no funciona. También hay personas en la comunidad Lisp que argumentan que, de hecho, la comunidad de CommonLisp insiste categóricamente en que CommonLisp es un lenguaje multi-paradigma. –
Doug Hoyte argumenta que LISP no funciona: http://letoverlambda.com/index.cl/guest/chap5.html. Apenas es "nadie" en el mundo de LISP. Está hablando de Common Lisp, por supuesto, y no de Scheme (que es más funcional en varios aspectos importantes, y es un primo nuevo, Clojure, incluso más). – itsbruce
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 claveref
.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:
Cualquier lenguaje FP verdaderamente puro es un proyecto de investigación toy language o de alguien.
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.
Tener "funciones de primera clase" no hace un lenguaje FP. La parte "funcional" en la Programación funcional se refiere a las funciones _mathematical_, es decir, funciones en las que cada entrada tiene un único resultado. Esta propiedad luego le da transparencia referencial, inmutabilidad, que conduce al razonamiento ecuacional. Si desea un término para "programar con funciones que no son matemáticas", entonces un término mejor es "programación de procedimientos". De lo contrario, los "lenguajes FP" son los que fomentan activamente el uso de FP. JS, R, Lua, Perl nunca calificarán. Por favor, no diluya los términos para fines de marketing. –
@AlexandruNedelcu: me referí a eso oblicuamente arriba con mis comentarios sobre cómo escapar de la pureza del paradigma. Con eso me refiero a que cualquier lenguaje FP práctico te permite escribir programas que violan tu ideal matemático. Si insistes en esa definición, incluso Haskell no es FP.Tu definición es por lo tanto insostenible. –
- 1. ¿Haskell es realmente un lenguaje puramente funcional considerando UnpafePerformIO?
- 2. Además de un lenguaje declarativo, ¿SQL es un lenguaje funcional?
- 3. ¿XSLT es un lenguaje de programación funcional?
- 4. ¿Se puede usar realmente Ruby como lenguaje funcional?
- 5. Javascript como un lenguaje funcional
- 6. CMS en el lenguaje de programación funcional
- 7. lenguaje de ensamblaje funcional
- 8. ¿Es Erlang un lenguaje de programación de restricción de lógica?
- 9. Implementación de ESB (Enterprise Service Bus) en un lenguaje funcional
- 10. ¿Cuál es la diferencia formal entre un lenguaje de nivel funcional y uno funcional?
- 11. ¿El rubí es realmente un lenguaje completamente orientado a objetos?
- 12. ¿El "primer" lenguaje funcional del paciente con amnesia? (Realmente me gusta Clojure ...)
- 13. La "programación funcional" tiene un significado claro, pero ¿el "lenguaje funcional"?
- 14. ¿Qué lenguaje de programación funcional debería elegir como primer lenguaje de programación funcional?
- 15. ¿Cuál es el lenguaje de programación funcional más mínimo?
- 16. ¿Por qué es más fácil escribir un compilador en un lenguaje funcional?
- 17. ¿Qué tan práctico es incorporar el núcleo de un lenguaje con un espacio funcional funcional (como ML) en Haskell?
- 18. Lista doblemente enlazada en un lenguaje de programación puramente funcional
- 19. Cómo el lenguaje funcional es diferente del punto de vista de implementación del lenguaje
- 20. Búsqueda rápida de elementos para un lenguaje funcional (Haskell)
- 21. métodos estáticos hacen de Java un lenguaje pseudo funcional?
- 22. ¿Cómo estructurar una aplicación escrita en un lenguaje funcional?
- 23. Beneficios y usos de un lenguaje de programación funcional
- 24. Hojas de cálculo que utilizan un lenguaje de programación funcional
- 25. ¿Cuál es la duración de un valor memorable en un lenguaje funcional como Haskell?
- 26. ¿Cuál es un buen lenguaje funcional sobre el cual construir un servicio web?
- 27. ¿Es Erlang un lenguaje conciso desde la perspectiva de un programador?
- 28. ¿Es LuaJIT realmente más rápido que cualquier otro lenguaje dinámico JIT-ed?
- 29. ¿Cuál es un lenguaje de programación más funcional, Haskell o Python?
- 30. ¿Puede alguien explicar en términos sencillos qué es un lenguaje funcional?
El aislamiento del proceso y la falta de estado compartido es una de las propiedades clave del modelo Actor. Amo el modelo Actor. – kyoryu
Sí ... pero ¿qué tiene que ver el modelo de actor con ser un lenguaje funcional o no? – Zed
Ahora estoy confundido con los actores. Supongo que llamar a un idioma "funcional" no significa que sea 100% funcional en ese momento. ¿Cómo están relacionados los actores? – Zubair