¿Por qué lenguajes funcionales? [cerrado]

Aquí se habla mucho sobre lenguajes funcionales y otras cosas. ¿Por qué usarías uno sobre un lenguaje "tradicional"? ¿Qué hacen mejor? ¿En qué son peores? ¿Cuál es la aplicación de programación funcional ideal?

Los lenguajes funcionales usan un paradigma diferente que los lenguajes imperativos y orientados a objetos. Utilizan funciones libres de efectos secundarios como un componente básico del lenguaje. Esto permite muchas cosas y hace que muchas cosas sean más difíciles (o en la mayoría de los casos, diferentes de lo que la gente está acostumbrada).

Una de las mayores ventajas de la programación funcional es que el orden de ejecución de las funciones sin efectos secundarios no es importante. Por ejemplo, en Erlang esto se usa para habilitar la concurrencia de una manera muy transparente. Y debido a que las funciones en lenguajes funcionales se comportan de manera muy similar a las funciones matemáticas, es fácil traducirlas a lenguajes funcionales. En algunos casos, esto puede hacer que el código sea más legible.

Tradicionalmente, una de las grandes desventajas de la programación funcional también era la falta de efectos secundarios. Es muy difícil escribir software útil sin IO, pero IO es difícil de implementar sin efectos secundarios en las funciones. Por lo tanto, la mayoría de las personas nunca obtuvieron más de la programación funcional que calcular una sola salida a partir de una sola entrada. En lenguajes modernos de paradigma mixto como F # o Scala, esto es más fácil.

Muchos lenguajes modernos tienen elementos de lenguajes de programación funcionales. C # 3.0 tiene muchas características de programación funcional y también puedes hacer programación funcional en Python. Creo que las razones de la popularidad de la programación funcional se deben principalmente a dos razones: la concurrencia se está convirtiendo en un problema real en la programación normal porque estamos obteniendo más y más computadoras multiprocesador; y los idiomas son cada vez más accesibles.

No creo que haya ninguna duda sobre el enfoque funcional de la programación que se está poniendo de moda, ya que ha estado en uso (como un estilo de programación) durante aproximadamente 40 años. Cada vez que un programador de OO escribe código limpio que favorece los objetos inmutables, ese código toma prestados conceptos funcionales.

Sin embargo, los idiomas que imponen un estilo funcional están recibiendo mucha tinta virtual en estos días, y si esos idiomas serán dominantes en el futuro es una pregunta abierta. Mi propia sospecha es que los lenguajes híbridos y multi-paradigmáticos como Scala u OCaml probablemente dominarán sobre los lenguajes funcionales "puristas" de la misma manera que el lenguaje puro OO (Smalltalk, Beta, etc.) han influido en la programación principal pero no han terminado arriba como las notaciones más utilizadas.

Finalmente, no puedo resistirme a señalar que sus comentarios sobre FP son muy paralelos a los comentarios que escuché de programadores de procedimientos no hace muchos años:

• El programador "promedio" (mítico, en mi humilde opinión) no lo entiende.
• No se enseña mucho.
• Cualquier programa que pueda escribir con él puede escribirse de otra manera con las técnicas actuales.

Así como las interfaces gráficas de usuario y el "código como modelo de negocio" fueron conceptos que ayudaron a OO a ser más ampliamente apreciados, creo que un mayor uso de la inmutabilidad y un paralelismo más simple (masivo) ayudará a más programadores a ver los beneficios que ofrece el enfoque funcional . Pero por mucho que hayamos aprendido en los últimos 50 años que conforman toda la historia de la programación de computadoras digitales, creo que todavía tenemos mucho que aprender. Dentro de veinte años, los programadores mirarán con asombro la naturaleza primitiva de las herramientas que estamos utilizando actualmente, incluidos los populares lenguajes OO y FP.

La principal ventaja para mí es su paralelismo inherente, especialmente porque ahora nos estamos alejando de más MHz y hacia más y más núcleos.

No creo que se convierta en el próximo paradigma de programación y reemplace completamente los métodos de tipo OO, pero sí creo que llegaremos al punto de que necesitamos escribir parte de nuestro código en un lenguaje funcional, o nuestros lenguajes de uso general lo harán. crecer para incluir construcciones más funcionales.

Incluso si nunca trabaja profesionalmente en un lenguaje funcional, comprender la programación funcional lo convertirá en un mejor desarrollador. Le dará una nueva perspectiva sobre su código y la programación en general.

Yo digo que no hay razón para no aprenderlo.

Creo que los lenguajes que hacen un buen trabajo al mezclar el estilo funcional y el imperativo son los más interesantes y tienen más probabilidades de tener éxito.

Siempre soy escéptico sobre la próxima gran cosa. Muchas veces, Next Big Thing es puro accidente de la historia, estar allí en el lugar correcto en el momento correcto, sin importar si la tecnología es buena o no. Ejemplos: C ++, Tcl / Tk, Perl. Todas las tecnologías defectuosas, todas muy exitosas porque se percibía que resolvían los problemas del día o que eran casi idénticas a los estándares arraigados, o ambos. La programación funcional puede ser realmente excelente, pero eso no significa que se adoptará.

Pero puedo decir por qué la gente está entusiasmada con la programación funcional: muchos, muchos programadores han tenido una especie de "experiencia de conversión" en la que descubren que usar un lenguaje funcional los hace dos veces más productivos (o quizás diez veces más productivos) mientras producen código que es más resistente al cambio y tiene menos errores. Estas personas piensan en la programación funcional como un arma secreta; Un buen ejemplo de esta mentalidad es el de Paul Graham Beating the Averages de . Ah, y su aplicación? Aplicaciones web de comercio electrónico.

Desde principios de 2006 también ha habido algunos rumores sobre la programación funcional y el paralelismo. Como a la gente le gusta Simon Peyton Jones se han preocupado por el paralelismo de vez en cuando al menos desde 1984, no estoy aguantando la respiración hasta que los lenguajes funcionales resuelvan el problema multinúcleo. Pero sí explica algunos de los rumores adicionales en este momento.

En general, las universidades estadounidenses están haciendo un mal trabajo enseñando programación funcional. Existe un fuerte núcleo de soporte para enseñar programación de introducción usando Scheme , y Haskell también disfruta de cierto soporte allí, pero hay muy poco en el camino de enseñar técnicas avanzadas para programadores funcionales. He enseñado tal curso en Harvard y lo volveré a hacer esta primavera en Tufts. Benjamin Pierce ha enseñado tal curso en Penn. No sé si Paul Hudak ha hecho algo en Yale. Las universidades europeas están haciendo un trabajo mucho mejor; Por ejemplo, la programación funcional se enfatiza en lugares importantes en Dinamarca, los Países Bajos, Suecia y el Reino Unido. Tengo menos idea de lo que está sucediendo en Australasia.

No veo a nadie mencionando al elefante en la habitación aquí, así que creo que depende de mí :)

JavaScript es un lenguaje funcional. A medida que más y más personas hagan cosas más avanzadas con JS, especialmente aprovechando los puntos más finos de jQuery, Dojo y otros marcos, la puerta trasera del desarrollador web introducirá FP.

Junto con los cierres, FP hace que el código JS sea realmente ligero, pero aún legible.

Saludos, PS

La mayoría de las aplicaciones son lo suficientemente simples como para resolverse en formas normales de OO

1. OO maneras no siempre han sido "normales". El estándar de esta década fue el concepto marginado de la década pasada.

2. La programación funcional es matemática. Paul Graham en Lisp (programación funcional sustitutiva de Lisp):

Entonces, la breve explicación de por qué este lenguaje de la década de 1950 no es obsoleto es que no era tecnología sino matemáticas, y las matemáticas no se vuelven obsoletas. Lo correcto para comparar a Lisp no es el hardware de la década de 1950, sino, por ejemplo, el algoritmo Quicksort, que se descubrió en 1960 y sigue siendo el tipo de propósito general más rápido.

Apuesto a que no sabías que eras una programación funcional cuando usabas:

• Fórmulas de Excel
• Compositor de cuarzo
• JavaScript
• Logotipo (gráficos de tortuga)
• LINQ
• SQL
• Underscore.js (o Lodash), D3

El programador corporativo promedio, por ejemplo, la mayoría de las personas con las que trabajo, no lo entenderá y la mayoría de los entornos de trabajo no le permitirán programar en él.

Sin embargo, ese es solo cuestión de tiempo. Su programador corporativo promedio aprende cualquiera que sea la gran cosa actual. Hace 15 años, no entendían la POO. Si FP se pone al día, sus "programadores corporativos promedio" lo seguirán.

Realmente no se enseña en las universidades (¿o es hoy en día?)

Varía mucho En mi universidad, SML es el primer idioma que se les presenta a los estudiantes. Creo que el MIT enseña LISP como un curso de primer año. Estos dos ejemplos pueden no ser representativos, por supuesto, pero creo que la mayoría de las universidades ofrecen al menos algunos cursos opcionales sobre FP, incluso si no lo hacen una parte obligatoria del plan de estudios.

La mayoría de las aplicaciones son lo suficientemente simples como para resolverse en formas normales de OO

Sin embargo, no es realmente una cuestión de "lo suficientemente simple". ¿Sería una solución más simple (o más legible, robusta, elegante, eficiente) en FP? Muchas cosas son "lo suficientemente simples como para ser resueltas en Java", pero aún así requiere una cantidad de código increíble.

En cualquier caso, tenga en cuenta que los defensores de FP han afirmado que fue la próxima gran cosa durante varias décadas. Quizás tengan razón, pero tenga en cuenta que no lo estaban cuando hicieron el mismo reclamo hace 5, 10 o 15 años.

Sin embargo, una cosa que definitivamente cuenta a su favor es que recientemente, C # ha dado un giro brusco hacia FP, en la medida en que prácticamente está convirtiendo a una generación de programadores en programadores de FP, sin que ellos se den cuenta . Eso podría allanar el camino para la "revolución" de la PF. Tal vez. ;)

El hombre no puede entender la perfección e imperfecciones de su arte elegido si no puede ver el valor en otras artes. Seguir las reglas solo permite el desarrollo hasta cierto punto en la técnica y luego el estudiante y el artista tienen que aprender más y buscar más. Tiene sentido estudiar otras artes además de las de estrategia.

¿Quién no ha aprendido algo más sobre sí mismos al observar las actividades de los demás? Para aprender la espada estudia la guitarra. Para aprender el primer estudio de comercio. Solo estudiar la espada te hará de mente estrecha y no te permitirá crecer hacia afuera.

- Miyamoto Musashi, "Un libro de cinco anillos"

Una característica clave en un lenguaje funcional es el concepto de funciones de primera clase. La idea es que puede pasar funciones como parámetros a otras funciones y devolverlas como valores.

La programación funcional implica escribir código que no cambia de estado. La razón principal para hacerlo es que las llamadas sucesivas a una función producirán el mismo resultado. Puede escribir código funcional en cualquier idioma que admita funciones de primera clase, pero hay algunos idiomas, como Haskell, que no le permiten cambiar el estado. De hecho, se supone que no debes hacer ningún efecto secundario (como imprimir texto), lo que parece que podría ser completamente inútil.

Haskell, en cambio, emplea un enfoque diferente para IO: mónadas. Estos son objetos que contienen la operación IO deseada que debe ejecutar el nivel superior de su intérprete. En cualquier otro nivel, son simplemente objetos en el sistema.

¿Qué ventajas ofrece la programación funcional? La programación funcional permite la codificación con menos posibilidades de errores porque cada componente está completamente aislado. Además, el uso de funciones de recursión y de primera clase permite pruebas simples de corrección que generalmente reflejan la estructura del código.

No creo que las personas más realistas piensen que la programación funcional se pondrá al día (se convierte en el paradigma principal como OO). Después de todo, la mayoría de los problemas comerciales no son problemas matemáticos, sino reglas imperativas para mover los datos y mostrarlos de varias maneras, lo que significa que no encaja bien con el paradigma de programación funcional pura (la curva de aprendizaje de la mónada supera con creces la OO).

OTOH, la programación funcional es lo que hace que la programación sea divertida. Te hace apreciar la belleza inherente y atemporal de las expresiones sucintas de las matemáticas subyacentes del universo. La gente dice que aprender programación funcional te hará un mejor programador. Por supuesto, esto es muy subjetivo. Personalmente, tampoco creo que sea completamente cierto.

Te hace un mejor ser sensible.

Debo ser denso, pero todavía no lo entiendo. ¿Hay ejemplos reales de pequeñas aplicaciones escritas en un lenguaje funcional como F # donde pueda ver el código fuente y ver cómo y por qué era mejor usar un enfoque que, por ejemplo, C #?

Señalaría que todo lo que has dicho sobre lenguajes funcionales, la mayoría de la gente decía acerca de los idiomas orientados a objetos hace unos 20 años. En aquel entonces era muy común escuchar acerca de OO:

* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways

El cambio tiene que venir de alguna parte. Se producirá un cambio significativo e importante independientemente de si las personas capacitadas en tecnologías anteriores piensan que el cambio no es necesario. ¿Crees que el cambio a OO fue bueno a pesar de todas las personas que estaban en contra en ese momento?

F # podría ponerse al día porque Microsoft lo está presionando.

Pro:

• F # va a ser parte de la próxima versión de Visual Studio
• Microsoft está creando comunidad desde hace algún tiempo: evangelistas, libros, consultores que trabajan con clientes de alto perfil, exposición significativa en conferencias de MS.
• F # es el lenguaje .Net de primera clase y es el primer lenguaje funcional que viene con una base realmente grande (no es que yo diga que Lisp, Haskell, Erlang, Scala, OCaml no tienen muchas bibliotecas, simplemente no son tan completas como .Net es)
• Fuerte apoyo al paralelismo

Contra:

• F # es muy difícil de comenzar, incluso si eres bueno con C # y .Net, al menos para mí :(
• probablemente será difícil encontrar buenos desarrolladores de F #

Entonces, le doy 50:50 posibilidades a F # de volverse importante. Otros lenguajes funcionales no lo harán en un futuro próximo.

Creo que una razón es que algunas personas sienten que la parte más importante de si un idioma será aceptado es qué tan bueno es el idioma . Desafortunadamente, las cosas rara vez son tan simples. Por ejemplo, yo diría que el factor más importante detrás de la aceptación de Python no es el lenguaje en sí (aunque eso es bastante importante). La razón principal por la que Python es tan popular es su enorme biblioteca estándar y la comunidad aún más grande de bibliotecas de terceros.

Los lenguajes como Clojure o F # pueden ser la excepción a la regla sobre esto teniendo en cuenta que están construidos sobre JVM / CLR. Como resultado, no tengo una respuesta para ellos.

La mayoría de las aplicaciones se pueden resolver en [inserte su idioma favorito, paradigma, etc. aquí].

Aunque, esto es cierto, se pueden usar diferentes herramientas para resolver diferentes problemas. Funcional simplemente permite otra abstracción de nivel alto (¿más alto?) Que permite hacer nuestro trabajo de manera más efectiva cuando se usa correctamente.

Me parece que las personas que nunca aprendieron Lisp o Scheme como estudiantes universitarios ahora lo están descubriendo. Al igual que con muchas cosas en este campo, hay una tendencia a exagerar y crear altas expectativas ...

Pasara.

La programación funcional es genial. Sin embargo, no se hará cargo del mundo. C, C ++, Java, C #, etc. seguirán existiendo.

Creo que lo que vendrá de esto es una mayor capacidad de idiomas cruzados, por ejemplo, implementar cosas en un lenguaje funcional y luego dar acceso a esas cosas en otros idiomas.

Cuando leí "El siguiente lenguaje de programación convencional: la perspectiva de un desarrollador de juegos" de Tim Sweeney, Epic Games, mi primer pensamiento fue: aprendí Haskell.

PPT

Versión HTML de Google

Las cosas se han estado moviendo en una dirección funcional durante un tiempo. Los dos nuevos y geniales niños de los últimos años, Ruby y Python, están radicalmente más cerca de los lenguajes funcionales que lo que les precedió, tanto que algunos Lispers han comenzado a admitir uno u otro como "lo suficientemente cerca".

Y con el hardware masivamente paralelo ejerciendo presión evolutiva sobre todos, y los lenguajes funcionales en el mejor lugar para hacer frente a los cambios, no es un salto tan grande como lo fue alguna vez pensar que Haskell o F # serán la próxima gran cosa.

¿Has estado siguiendo la evolución de los lenguajes de programación últimamente? Cada nueva versión de todos los lenguajes de programación convencionales parece tomar prestadas más y más características de la programación funcional.

• Los cierres, las funciones anónimas, las funciones de paso y retorno como valores solían ser características exóticas conocidas solo por los piratas informáticos de Lisp y ML. Pero gradualmente, C #, Delphi, Python, Perl, Javascript, han agregado soporte para los cierres. No es posible que un lenguaje prometedor se tome en serio sin cierres.

• Varios lenguajes, especialmente Python, C # y Ruby tienen soporte nativo para la comprensión de listas y generadores de listas.

• ML fue pionero en la programación genérica en 1973, pero el soporte para genéricos ("polimorfismo paramétrico") solo se ha convertido en un estándar de la industria en los últimos 5 años más o menos. Si no recuerdo mal, Fortran admitió genéricos en 2003, seguido de Java 2004, C # en 2005, Delphi en 2008. (Sé que C ++ ha admitido plantillas desde 1979, pero el 90% de las discusiones sobre STL de C ++ comienzan con "aquí hay demonios" .)

¿Qué hace que estas características sean atractivas para los programadores? Debería ser claramente obvio: ayuda a los programadores a escribir código más corto . Todos los idiomas en el futuro apoyarán, como mínimo, cierres si quieren seguir siendo competitivos. A este respecto, la programación funcional ya está en la corriente principal.

La mayoría de las aplicaciones son lo suficientemente simples como para resolverse en formas normales de OO

¿Quién dice que no puede usar la programación funcional para cosas simples también? No todos los programas funcionales deben ser un compilador, un probador de teoremas o un conmutador de telecomunicaciones paralelo masivo. Regularmente uso F # para scripts desechables ad hoc además de mis proyectos más complicados.

Se está poniendo de moda porque es la mejor herramienta para controlar la complejidad. Ver:
diapositivas 109-116 de la charla de Simon Peyton-Jones "A Taste of Haskell"
- "The Next Mainstream Programming Language: A Game Developer's Perspective" por Tim Sweeney

Verifique por qué es importante la programación funcional

Estoy de acuerdo con el primer punto, pero los tiempos cambian. Las corporaciones responderán, incluso si son adoptadores tardíos, si ven que hay una ventaja. La vida es dinámica.

Enseñaban a Haskell y ML en Stanford a finales de los 90. Estoy seguro de que lugares como Carnegie Mellon, MIT, Stanford y otras buenas escuelas lo están presentando a los estudiantes.

Estoy de acuerdo en que la mayoría de las aplicaciones de "exponer bases de datos relacionales en la web" continuarán en esa línea durante mucho tiempo. Java EE, .NET, RoR y PHP han desarrollado algunas soluciones bastante buenas para ese problema.

Has tocado algo importante: podría ser el problema que no puede resolverse fácilmente por otros medios que impulse la programación funcional. ¿Qué sería eso?

¿El hardware multinúcleo masivo y la computación en la nube los impulsarán?

Porque FP tiene beneficios significativos en términos de productividad, confiabilidad y mantenibilidad. Many-core puede ser una aplicación asesina que finalmente logra que las grandes corporaciones cambien a pesar de los grandes volúmenes de código heredado. Además, incluso los grandes lenguajes comerciales como C # están adquiriendo un sabor funcional distintivo como resultado de preocupaciones de muchos núcleos: efectos secundarios simplemente No encaja bien con la concurrencia y el paralelismo.

No estoy de acuerdo con que los programadores "normales" no lo entiendan. Lo harán, al igual que finalmente entendieron la POO (que es tan misterioso y extraño, si no más).

Además, la mayoría de las universidades enseñan FP, muchas incluso lo enseñan como el primer curso de programación.

Wow, esta es una discusión interesante. Mis propios pensamientos sobre esto:

FP hace que algunas tareas sean relativamente simples (en comparación con los lenguajes sin FP). Los lenguajes sin FP ya están comenzando a tomar ideas de FP, por lo que sospecho que esta tendencia continuará y veremos una mayor fusión que debería ayudar a las personas a facilitar el salto a FP.

No sé si se pondrá al día o no, pero de mis investigaciones, es casi seguro que vale la pena aprender un lenguaje funcional y te hará un mejor programador. El simple hecho de comprender la transparencia referencial hace que muchas decisiones de diseño sean mucho más fáciles, y los programas resultantes son mucho más fáciles de razonar. Básicamente, si se encuentra con un problema, entonces tiende a ser solo un problema con la salida de una sola función, en lugar de un problema con un estado inconsistente, que podría haber sido causado por cualquiera de los cientos de clases / métodos / funciones en un lenguaje impaciente con efectos secundarios.

La naturaleza sin estado de FP asigna de forma más natural a la naturaleza sin estado de la web y, por lo tanto, los lenguajes funcionales se prestan más fácilmente a aplicaciones web más elegantes y RESTFUL. Contraste con los marcos JAVA y .NET que necesitan recurrir a HACKS horriblemente feos como las teclas VIEWSTATE y SESSION para mantener el estado de la aplicación y mantener la abstracción (ocasionalmente bastante permeable) de un lenguaje imperativo con estado, en una plataforma funcional esencialmente sin estado como la web.

Y además, cuanto más apátrida sea su aplicación, más fácilmente se presta para el procesamiento paralelo. Terriblemente importante para la web, si su sitio web se vuelve popular. No siempre es sencillo agregar más hardware a un sitio para obtener un mejor rendimiento.

Mi opinión es que se dará cuenta ahora que Microsoft lo ha llevado mucho más lejos en la corriente principal. Para mí es atractivo por lo que puede hacer por nosotros, porque es un nuevo desafío y por las oportunidades de trabajo que resiente en el futuro.

Una vez dominado, será otra herramienta para ayudarnos a ser más productivos como programadores.

Un punto omitido en la discusión es que los mejores sistemas de tipos se encuentran en lenguajes contemporáneos de FP. Además, los compiladores pueden inferir todos (o al menos la mayoría) tipos automáticamente.

Es interesante que uno pase la mitad del tiempo escribiendo nombres de tipos al programar Java, sin embargo, Java no es seguro. Si bien nunca puede escribir tipos en un programa Haskell (excepto como una especie de documentación comprobada por el compilador) y el código es 100% seguro.

Además de las otras respuestas, considerar la solución en términos funcionales puros obliga a uno a comprender mejor el problema. Por el contrario, pensar con un estilo funcional desarrollará mejores habilidades para resolver problemas.

* Ya sea porque el paradigma funcional es mejor o porque permitirá un ángulo de ataque adicional.