¿Por qué el entusiasmo actual por la programación funcional? [cerrado]

A finales de los 80 y principios de los 90, las computadoras se volvieron lo suficientemente poderosas como para la OOP al estilo Smalltalk. Hoy en día las computadoras son lo suficientemente poderosas para FP. FP es la programación a un nivel más alto y, por lo tanto, a menudo, mientras que es más agradable de programar, no es la forma más eficiente de resolver un problema determinado. Pero las computadoras son tan rápidas que no te importa.

El prorgamming 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 tienes que renunciar a un paradigma si quieres usar otro. Puedes hacer FP en los idiomas más populares, por lo que la barrera de entrada es baja.

Necesidad actual de computación distribuida.

FP usa funciones como bloques de construcción, que no tienen estado, por lo que invocarlas n con los mismos parámetros siempre debe devolver el mismo valor, no tienen efectos secundarios.

Por lo tanto, puede enviar la misma función a un grupo de máquinas para realizar y hacer el trabajo en paralelo.

En el paradigma OO, esto es un poco más difícil, ya que los bloques de construcción son objetos, que casi están definidos por estado. Si invoca varias veces el mismo método, debe tener cuidado al sincronizar los datos internos para evitar la corrupción de los datos. Aunque todavía es posible, el paradigma de PF funciona mejor que el OO en algunos escenarios donde se debe distribuir el cálculo.

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 es solo un nicho para el tipo de aplicaciones que necesitan este tipo de configuración. Para muchas, muchas otras aplicaciones / sistemas, 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 ese entonces ni siquiera sabía que era FP. A estas alturas ya lo he olvidado casi todo, pero ciertamente me ayuda a entender conceptos como la recursión muy fácilmente.

Nos estamos moviendo a una era en la que el procesamiento de múltiples núcleos no es solo algo que se hace en las salas de los laboratorios de ciencias o en hardware especializado. Ahora se está haciendo con procesadores de productos básicos. Programación funcional, al menos la mayoría de las variantes a las que he estado expuesto, generalmente intenta impulsar una visión de unidades computacionales sin estado y sin efectos secundarios. Este es el paradigma por excelencia para el trabajo de múltiples núcleos, ya que no hay necesidad de mantener el estado mezclado entre los procesadores.

Esta es solo una de las razones, pero una muy buena razón para ver que la programación funcional se afianza.

Creo que la respuesta principal a esa pregunta es "exposición".

La programación funcional no es nada nuevo, me enseñaron Haskell en la universidad hace unos 12 años y me encantó. Pero rara vez llegué a usar el lenguaje en mi trabajo profesional.

Recientemente, ha habido varios idiomas ganando terreno en la corriente principal que utilizan un enfoque de paradigma múltiple; F # , siendo JavaScript el mejor ejemplo.

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 dinámicos y modernos. 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 diarias.

Con F # convirtiéndose en un lenguaje de primera clase en Visual Studio 2010 y jQuery (et al) se vuelve tan importante, se está volviendo realista usar estos idiomas, en lugar de ser algo extraño para jugar o crear programas aislados.

Recuerde que el código debe mantenerse, una masa crítica de desarrolladores debe usar y admitir idiomas para que las empresas se sientan seguras al usarlos.

En esta charla Anders Hejlsberg explica su opinión sobre el tema.

[EDITAR]

Lo siento, el enlace estaba equivocado. Ahora apunta al lugar correcto.

Resumen muy breve de algunos puntos de la conversación 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 qué en lugar de cómo . Debido a su elegante estructura matemática, los compiladores también facilitan y transforman los archivos FL, lo que también permite una fácil programación y la construcción de DSL incorporados. Todo esto en conjunto hace que los programas de funciones sean más sucintos y autodocumentados que los programas de procedimientos.

Además, frente a la era de muchos puntos de vista del futuro próximo, los lenguajes de programación deben poder utilizar el procesamiento / subprocesamiento múltiple 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 reflejaba esto. Los subprocesos múltiples en muchas máquinas de núcleo serán muy diferentes. 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).

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 trajo todo el enfoque de la programación funcional en un gran alivio, ya que ofrecía un camino muy rápido hacia una aplicación web funcional (je je). Hay un una interesante discusión sobre SO sobre esto, y una respuesta particular se destaca:

  

La programación funcional coincide con la web   Aplicaciones muy bien. La aplicación web recibe un   Solicita HTTP y produce un HTML.   resultado. Esto podría ser considerado un   Función desde peticiones a páginas.

     

Compare con las aplicaciones de escritorio, donde   Normalmente tienen un proceso de larga ejecución,   una interfaz de usuario y un flujo de datos con estado en varios   direcciones. Esto es más adecuado para OO   que se preocupa por los objetos con   Estado y paso de mensajes.

Dado que la programación funcional ha existido por mucho tiempo, me pregunto por qué no veo muchos anuncios de trabajo buscando a los desarrolladores de Lisp para proyectos web en zonas verdes.

La programación funcional me da la misma sensación de " wow, esto es nuevo " como cuando empecé a incursionar con objetos hace años.

Me doy cuenta de que la FP no es un concepto nuevo en gran medida, pero tampoco lo fue OO cuando tuvo su verdadera ruptura en los años noventa cuando "todos" de repente abandonaron la programación procesal. Esto se debió en gran parte al éxito oportuno de Java y más tarde de C #.

Me imagino que lo mismo sucederá con FP eventualmente una vez que el siguiente grupo de idiomas comience a propagarse de la misma manera. Por mucho que ya tengan, al menos en algunos círculos, con idiomas como Scala y F #.

  

Aquí están mis preguntas:   1. ¿Qué ha contribuido al reciente entusiasmo de FP? ¿Es simplemente un aburrimiento con OO, o algo ha cambiado para hacer que la PF sea más necesaria que antes?   2. ¿Es esto indicativo de un futuro FP? ¿O es una moda, como las bases de datos orientadas a objetos?

Otros han dado una buena razón técnica.

Creo que la razón principal por la que FP está ganando terreno entre los tipos promedio de desarrolladores y administradores es que promete 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 uso generalizado en el futuro será si la promesa es real y se cumple.

Creo que es una combinación de dos tendencias:

1. Las funciones funcionales se agregan a los idiomas principales (por ejemplo, C #).
2. Se están creando nuevos lenguajes funcionales.

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 que se lo tome en serio.

Solía ser que la gente escribía programas para ejecutarse en el escritorio utilizando las API nativas del sistema operativo, y esas API estaban (generalmente) escritas en C, así que en su mayor parte si deseaba escribir un programa para el nativo APIs, escribiste ese programa en C.

Creo que la nueva innovación en los últimos 10 años más o menos es la de una diversidad de API, especialmente en cosas como el desarrollo web donde las API de la plataforma son irrelevantes (ya que la construcción de una página web implica básicamente la manipulación de cadenas). Dado que no está codificando directamente a la API de Win32 o la API de POSIX, eso le da a las personas la libertad de probar lenguajes funcionales.

Es neaty and nifty y le hace cosquillas a tu cerebro. Eso está bien.

También es, IMHO, un carro clásico. Una solución en busca de un problema.

Es como todas las nuevas empresas fundadas por ingenieros deslumbradas con una idea favorita, que se queman brillantemente por un tiempo, pero son superadas silenciosamente por compañías basadas en proporcionar lo que se necesita.

Esa es la nueva idea que me gustaría ver en el despegue, la programación basada en la necesidad, no la programación basada en la idea ingeniosa. Tal vez eso suene mundano, pero creo que de hecho puede ser bastante creativo y hábil.

Definitivamente debido a F #, aunque a veces es difícil decir cuál es la causa y cuál es el efecto.