Últimamente he escuchado mucho entusiasmo sobre los lenguajes de programación funcionales, con respecto a Scala, Clojure y F #. Recientemente comencé a estudiar Haskell para aprender el paradigma FP.
Me encanta, es muy divertido y se adapta a mi experiencia matemática.
¿Pero realmente importará alguna vez? Obviamente, no es una idea nueva.
Aquí están mis preguntas:
- ¿Qué ha contribuido al reciente entusiasmo de FP? ¿Es simplemente aburrimiento con OO, o ha cambiado algo para hacer que FP sea más necesario que antes?
- ¿Es esto indicativo de un futuro FP? ¿O es una moda pasajera, como las bases de datos orientadas a objetos?
En otras palabras, ¿alguien puede ayudarme a entender de dónde viene esto y hacia dónde podría ir?
functional-programming
Eric Wilson
fuente
fuente
Respuestas:
Una de las principales innovaciones en FP que ha resultado en la "explosión" de interés son las mónadas.
En enero de 1992, Philip Wadler escribió un artículo llamado La esencia de la programación funcional que introdujo a las mónadas en la programación funcional como una forma de tratar con IO.
El principal problema con los lenguajes de programación puros, perezosos y funcionales fue la utilidad al tratar con IO. Es uno de los miembros del "Awkward Squad" en programación, porque "la pereza y los efectos secundarios son, desde un punto de vista práctico, incompatibles. Si quieres usar un lenguaje perezoso, tiene que ser un lenguaje puramente funcional; si quieres usar efectos secundarios, es mejor que uses un lenguaje estricto ". Referencia
El problema con IO antes de las mónadas era que mantener la pureza no era posible para los programas que en realidad eran útiles para cualquier cosa. Por IO, nos referimos a todo lo relacionado con el cambio de estado, incluida la obtención de entradas y salidas del usuario o del entorno. En la programación funcional pura, todo es inmutable, para permitir pereza y pureza (sin efectos secundarios).
¿Cómo resuelven las mónadas el problema de IO? Bueno, sin discutir demasiado sobre las mónadas, básicamente toman el "Mundo" (el entorno de tiempo de ejecución) como entrada para la mónada, y producen un nuevo "Mundo" como salida, y el resultado: escriba IO a = Mundo -> (a, Mundo).
FP, por lo tanto, ha entrado cada vez más en la corriente principal, porque el mayor problema, IO (y otros) se ha resuelto. La integración en los lenguajes OO existentes también ha estado sucediendo, como saben. LINQ es mónadas, por ejemplo, de principio a fin.
Para obtener más información, recomiendo leer sobre mónadas y los documentos a los que se hace referencia en mi respuesta.
fuente
type IO a = UI -> (a, UI)un ejemplo más relevante sería una respuesta fantástica.Uno de los principales problemas al programar lenguajes tradicionales como C, Java, C #, ensamblador, etc. es que tiene una secuencia incómoda de pasos que debe seguir para realizar una tarea dada porque primero debe haber preparado todas las dependencias y SUS dependencias anteriores
Un ejemplo: para hacer A, debe tener presentes B y C, y B depende de D y E, lo que da como resultado algo así como
porque debes tener los ingredientes preparados antes de poder usarlos.
Los lenguajes funcionales, especialmente los flojos, dan vuelta este. Al dejar que A diga que necesita B y C, y dejar que el tiempo de ejecución del lenguaje descubra cuándo obtener B y C (lo que a su vez requiere D y E), todos los cuales se evalúan cuando es necesario para evaluar A, puede crear muy pequeño y conciso bloques de construcción, que resultan en programas pequeños y concisos. Los lenguajes perezosos también permiten usar listas infinitas, ya que solo se calculan los elementos realmente utilizados, y sin necesidad de almacenar toda la estructura de datos en la memoria antes de poder usarla.
El truco realmente bueno es que este mecanismo automático de "oh, necesito una B y una C" es escalable porque no hay restricción, como en el programa secuencial, sobre dónde y cuándo puede ocurrir esta evaluación, por lo que puede suceder en el momento mismo tiempo e incluso en diferentes procesadores o computadoras.
Es por eso que los lenguajes funcionales son interesantes, porque el mecanismo de tiempo de ejecución asume el mecanismo "qué hacer cuando" en lugar de que el programador tenga que hacerlo manualmente. Esta es una diferencia tan importante como la recolección de basura automática fue para Java a C, y una de las principales razones por las que es más fácil escribir software robusto y escalable de subprocesos múltiples en Java que en C. Es aún más fácil escribir robusto, software escalable multiproceso en lenguajes funcionales ...
fuente
A finales de los años 80 / principios de los 90, las computadoras se volvieron lo suficientemente potentes para la POO de estilo Smalltalk. Hoy en día las computadoras son lo suficientemente potentes para FP. FP está programando en un nivel superior y, por lo tanto, a menudo, aunque es más agradable de programar, no es la forma más eficiente de resolver un determinado problema. Pero las computadoras son tan rápidas que no te importa.
La programación multinúcleo puede ser más fácil con lenguajes de programación puramente funcionales, ya que se ve obligado a aislar el código que cambia de estado.
También los bordes del lenguaje de programación están borrosos hoy. No tiene que renunciar a un paradigma si quiere usar otro. Puede hacer FP en los idiomas más populares, por lo que la barrera de entrada es baja.
fuente
Necesidad actual de computación distribuida.
FP utiliza funciones como bloques de construcción, que no tienen estado, por lo que invocarlas n veces con los mismos parámetros debería devolver siempre el mismo valor, no tienen efectos secundarios.
Por lo tanto, puede enviar la misma función a un montón de máquinas para realizar y hacer el trabajo en paralelo.
En el paradigma OO, esto es un poco más difícil, porque los bloques de construcción son objetos, que son casi por definición con estado. Si invoca varias veces el mismo método, debe tener cuidado al sincronizar los datos internos, para evitar la corrupción de datos. Aunque todavía es posible, el paradigma FP funciona mejor que el OO en algunos escenarios en los que se debe distribuir la computación.
El advenimiento de FP (y NoSQL en cierta medida) se produce después de las historias sobre sorprendentes resultados informáticos en cientos de miles de computadoras que trabajan en paralelo, y lo fácil que es.
Pero probablemente este sea solo un nicho del tipo de aplicaciones que necesitan este tipo de configuración. Para muchas, muchas otras aplicaciones / sistemas, los procedimientos y OO funcionan bien.
Por lo tanto, se trata de expandir nuestros horizontes de programación y retomar estos conceptos que alguna vez pensamos que no irían más allá de la academia.
Aprendí a programar en Lisp hace años, y en aquel entonces no sabía que eso era FP. Por ahora me he olvidado de casi todo al respecto, pero ciertamente me ayuda a comprender conceptos como la recursión muy fácilmente.
fuente
Nos estamos moviendo a una era en la que el procesamiento multinúcleo no es solo algo que se hace en los cuartos traseros de los laboratorios de ciencias o en hardware especializado. Ahora se está haciendo con procesadores de productos básicos. La programación funcional, al menos la mayoría de las variantes a las que he estado expuesto, generalmente intenta impulsar una vista sobre unidades computacionales sin estado y sin efectos secundarios. Este es el paradigma por excelencia para el trabajo multinúcleo, ya que no es necesario mantener el estado mezclado entre los procesadores.
Esta es solo una de las razones, pero es una muy buena razón para ver cómo se afianza la programación funcional.
fuente
Creo que la respuesta principal a esa pregunta es 'exposición'.
La programación funcional no es nada nuevo, me enseñaron a Haskell en la universidad hace unos 12 años y me encantó. Pero raramente uso el lenguaje en mi trabajo profesional.
Recientemente ha habido una serie de idiomas que están ganando terreno en la corriente principal que utilizan un enfoque de paradigmas múltiples; F # , JavaScript siendo ejemplos principales.
JavaScript en particular, especialmente cuando se usa con un lenguaje de marco de estilo funcional como jQuery o Prototype , se está convirtiendo en un lenguaje cotidiano para muchas personas debido a todo el trabajo en sitios web modernos y dinámicos. Esta exposición al estilo funcional hace que las personas se den cuenta del poder que otorga, especialmente cuando uno puede volver a un estilo imperativo a voluntad.
Una vez que las personas están expuestas, prueban variantes más completas de lenguajes funcionales y comienzan a usarlas para las tareas cotidianas.
Con F # convirtiéndose en un lenguaje de primera clase en Visual Studio 2010 y jQuery (et al) cada vez más importante, se está volviendo realista usar estos lenguajes, en lugar de algo oscuro para jugar o hacer programas aislados.
Recuerde que el código debe ser mantenible: una masa crítica de desarrolladores debe usar y admitir idiomas para que las empresas se sientan seguras al usarlos.
fuente
En esta charla, Anders Hejlsberg explica su punto de vista sobre el tema.
[EDITAR]
Lo sentimos, el enlace estaba mal. Ahora apunta al lugar correcto.
Resumen extremadamente breve de algunos puntos de la charla de una hora:
Los lenguajes funcionales permiten un estilo de programación más declarativo que los lenguajes de procedimiento, por lo que los programas escritos en FL generalmente se concentran más en el qué en lugar del cómo . Debido a su elegante estructura matemática, los FL también son más fáciles de optimizar y transformar mediante compiladores, lo que también permite una fácil metaprogramación y la construcción de DSL integrados. Todo esto en conjunto hace que los programas funcionales sean más concisos y autodocumentados que los programas de procedimientos.
Además, en vista de la era de muchos núcleos del futuro cercano, los lenguajes de programación deben ser capaces de utilizar múltiples procesos / subprocesos de diferentes maneras. El subprocesamiento múltiple en máquinas de un solo núcleo era en efecto un mecanismo de tiempo compartido, y la arquitectura de los sistemas lo reflejaba. El subprocesamiento múltiple en máquinas de muchos puntos será muy diferente. Los lenguajes funcionales son especialmente adecuados para la paralelización, ya que en su mayoría evitan el estado, por lo que no es necesario preocuparse tanto por la integridad de los datos mutables compartidos (porque no suele haber datos mutables compartidos).
fuente
Creo que tiene que ver con la estrecha correlación entre el paradigma de programación funcional y la programación para la web.
Ruby on Rails puso en relieve todo el enfoque de la programación funcional, ya que ofrecía un camino muy rápido hacia una aplicación web funcional (heh heh). Hay una discusión interesante sobre SO sobre esto, y una respuesta particular se destaca:
Dado que la programación funcional ha existido durante siglos, me pregunto por qué no veo muchos anuncios de trabajo en busca de desarrolladores de Lisp para proyectos web nuevos.
fuente
La programación funcional me da la misma sensación de hormigueo de " wow, esto es nuevo " que cuando comencé a incursionar en objetos hace años.
Me doy cuenta de que FP no es un concepto nuevo con diferencia, pero tampoco lo era OO cuando tuvo su verdadero descanso en los noventa cuando "todos" saltaron repentinamente de la programación de procedimientos. Esto se debió en gran medida al éxito oportuno de Java y luego de C #.
Me imagino que lo mismo sucederá con FP eventualmente una vez que el próximo lote de idiomas comience a extenderse de la misma manera. Como ya lo han hecho, al menos en algunos círculos, con idiomas como Scala y F #.
fuente
Otros han dado buenas razones técnicas.
Creo que la razón principal por la que FP está ganando terreno entre los tipos promedio de desarrolladores y administradores es su promesa de permitir un mejor uso de las CPU de múltiples núcleos. De todo lo que he leído, FP permite una programación paralela más fácil (no fácil).
Su futuro uso generalizado será si la promesa es real y se cumple.
fuente
Creo que es una combinación de dos tendencias:
Probablemente haya un límite natural en la primera tendencia, pero supongo que cualquier lenguaje nuevo tendrá que soportar la programación funcional, al menos como una opción, para ser tomado en serio.
fuente
Solía ser que las personas escribían programas para ejecutarse en el escritorio utilizando las API nativas del sistema operativo, y esas API estaban (generalmente) escritas en C, por lo que en su mayor parte si desea escribir un programa para las API nativas, usted escribió ese programa en C.
Creo que la nueva innovación en los últimos 10 años más o menos es que una diversidad de API se ponga al día, particularmente para cosas como el desarrollo web donde las API de la plataforma son irrelevantes (ya que construir una página web básicamente implica la manipulación de cadenas). Como no está codificando directamente a la API Win32 o la API POSIX, eso le da a las personas la libertad de probar lenguajes funcionales.
fuente
Es elegante e ingenioso y le hace cosquillas en el cerebro. Esta bien.
También es, en mi humilde opinión, un carro clásico. Una solución buscando un problema.
Es como todas las empresas de nueva creación fundadas por ingenieros que deslumbraron con una idea favorita, que arden brillantemente por un tiempo, pero son superadas silenciosamente por empresas fundadas en proporcionar lo que se necesita.
Esa es la nueva idea que me gustaría ver despegar, programación basada en necesidades, no programación basada en ideas ingeniosas. Tal vez eso suene mundano, pero creo que de hecho puede ser bastante creativo e ingenioso.
fuente
Definitivamente debido a F #, aunque a veces es difícil saber cuál es la causa y cuál es el efecto.
fuente