¿Por qué lenguajes funcionales?[cerrado]

https://stackoverflow.com/questions/36504

09-06-2019
|

Pregunta

Veo que se habla mucho aquí sobre lenguajes funcionales y esas cosas.¿Por qué usarías uno en lugar de un idioma "tradicional"?¿Qué hacen mejor?¿En qué son peores?¿Cuál es la aplicación de programación funcional ideal?

Solución

Los lenguajes funcionales utilizan un paradigma diferente al de los lenguajes imperativos y orientados a objetos.Utilizan funciones libres de efectos secundarios como elemento 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 libres de 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 los 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 era también 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 la gente nunca sacó más provecho de la programación funcional que calcular una única salida a partir de una única 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 realizar 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 cada vez tenemos más computadoras multiprocesador;y los idiomas son cada vez más accesibles.

Otros consejos

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

Sin embargo, las lenguas que hacer cumplir Un estilo funcional está recibiendo mucha tinta virtual en estos días, y si esos lenguajes se volverán dominantes en el futuro es una pregunta abierta.Mi propia sospecha es que los lenguajes híbridos y multiparadigmáticos como escala o OCamlprobablemente dominará sobre los lenguajes funcionales "puristas" de la misma manera que el lenguaje OO puro (Smalltalk, Beta, etc.) ha influido en la programación convencional pero no ha terminado 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 ampliamente.
Cualquier programa que puedas escribir con él se puede escribir 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 que OO fuera más apreciado, creo que un mayor uso de la inmutabilidad y un paralelismo más simple (masivo) ayudará a que más programadores vean los beneficios que ofrece el enfoque funcional. .Pero por mucho que hayamos aprendido en los últimos 50 años aproximadamente que conforman toda la historia de la programación informática digital, creo que todavía tenemos mucho que aprender.Dentro de veinte años, los programadores mirarán hacia atrás con asombro ante la naturaleza primitiva de las herramientas que utilizamos actualmente. incluido los ahora 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 en el que necesitaremos escribir parte de nuestro código en un lenguaje funcional o nuestros lenguajes de propósito 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 mezclando estilos funcionales e imperativos son los más interesantes y los que tienen más probabilidades de tener éxito.

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

Pero yo poder decirte por qué la gente entusiasmado sobre 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 tal vez diez veces más productivos) mientras producen código que es más resistente al cambio y tiene menos errores.Estas personas piensan que la programación funcional es un arma secreta;Un buen ejemplo de esta mentalidad es el de Paul Graham. Superando los promedios.Ah, ¿y su solicitud?Aplicaciones web de comercio electrónico.

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

En general, las universidades estadounidenses están haciendo un mal trabajo enseñando programación funcional.Hay un fuerte núcleo de apoyo a Enseñanza de programación introductoria usando Scheme., y Haskell también disfruta de cierto soporte allí, pero hay muy poca enseñanza de técnicas avanzadas para programadores funcionales.He impartido un curso de este tipo en Harvard y lo volveré a hacer esta primavera en Tufts.Benjamin Pierce ha impartido un curso de este tipo 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 de Dinamarca, los Países Bajos, Suecia y el Reino Unido.Tengo menos idea de lo que está pasando 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 hacen cosas más avanzadas con JS, especialmente aprovechando los puntos más finos de jQuery, Dojo y otros marcos, FP será introducido por la puerta trasera del desarrollador web.

Junto con los cierres, FP hace que el código JS sea realmente liviano y aún así legible.

Saludos, PD

La mayoría de las aplicaciones son lo suficientemente simples como para resolverse de manera normal en OO.

Las formas de OO no siempre han sido "normales". El estándar de esta década fue el concepto marginado de la última década.
La programación funcional es matemática. Paul Graham en Lisp (programación funcional sustituta de Lisp):

Entonces, la breve explicación de por qué este idioma 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 LISP no es el hardware de los años 50, sino el algoritmo Quicksort, que se descubrió en 1960 y sigue siendo el tipo de uso general más rápido.

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

fórmulas de excel
Compositor de cuarzo
javascript
Logotipo (gráficos de tortugas)
LINQ
SQL
Subscore.js (o Lodash), D3

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

Aunque eso es sólo cuestión de tiempo.El programador corporativo promedio aprende cuál es el gran acontecimiento actual.Hace 15 años, no entendían la programación orientada a objetos.SI FP se pone de moda, sus "programadores corporativos promedio" lo seguirán.

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

Varía mucho.En mi universidad, SML es el primer idioma que conocen los estudiantes.Creo que el MIT enseña LISP como curso de primer año.Puede que estos dos ejemplos no sean representativos, por supuesto, pero creo que la mayoría de las universidades ofrecen al menos algunos cursos opcionales de FP, incluso si no lo convierten en una parte obligatoria del plan de estudios.

La mayoría de las aplicaciones son lo suficientemente simples como para resolverse de manera normal

Sin embargo, en realidad no es una cuestión de "suficientemente simple".¿Sería una solución más simple (o más legible, robusto, elegante y de alto rendimiento) en FP?Muchas cosas son "lo suficientemente simples como para resolverlas en Java", pero aún requieren una enorme cantidad de código.

En cualquier caso, tenga en cuenta que los defensores de la PF han afirmado que era la próxima gran novedad desde hace varias décadas.Quizás tengan razón, pero tenga en cuenta que no la tenían cuando hicieron la misma afirmación 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, hasta el punto de que prácticamente está convirtiendo a una generación de programadores en programadores de FP. sin que se den cuenta.Esto podría allanar el camino para la "revolución" de la FP.Tal vez.;)

El hombre no puede comprender la perfección y las imperfecciones del arte que ha elegido si no puede ver el valor de otras artes.Seguir las reglas sólo 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í mismo observando las actividades de los demás?Para aprender la espada estudia la guitarra.Para aprender el primer estudio de comercio.Simplemente estudiar la espada te volverá de mente estrecha y no te permitirá crecer hacia afuera.

-- Miyamoto Musashi, "El libro de los cinco anillos"

Una característica clave de un lenguaje funcional es el concepto de funciones de primera clase.La idea es que puedas 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 produzcan el mismo resultado.Puedes escribir código funcional en cualquier lenguaje que admita funciones de primera clase, pero hay algunos lenguajes, como Haskell, que no te permiten cambiar de estado.De hecho, se supone que no debes producir ningún efecto secundario (como imprimir texto), lo que parece que podría ser completamente inútil.

En cambio, Haskell 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 del sistema.

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

No creo que la gente más realista piense que la programación funcional se popularizará (se convertirá en el paradigma principal como OO).Después de todo, la mayoría de los problemas de negocios no son problemas matemáticos, sino reglas imperativas complicadas para mover datos y mostrarlos de varias maneras, lo que significa que no es una buena opción para el paradigma de programación funcional pura (la curva de aprendizaje de la mónada excede 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 convertirá en un mejor programador.Por supuesto, esto es muy subjetivo.Personalmente, tampoco creo que eso sea del todo cierto.

Te convierte en un mejor ser sensible.

Debo ser tonto, pero todavía no lo entiendo.¿Existe algún ejemplo real de aplicaciones pequeñas escritas en un lenguaje funcional como F# donde pueda mirar el código fuente y ver cómo y por qué era mejor utilizar ese enfoque que, digamos, C#?

Quisiera señalar que todo lo que usted ha dicho sobre los lenguajes funcionales, la mayoría de la gente lo decía sobre los lenguajes orientados a objetos hace unos 20 años.En aquel entonces era muy común oír hablar 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.Un cambio significativo e importante se producirá independientemente de si las personas capacitadas en tecnologías anteriores opinan que el cambio no es necesario.¿Crees que el cambio a OO fue bueno a pesar de toda la gente que estaba en contra en ese momento?

F# podría ponerse de moda porque Microsoft lo está impulsando.

Pro:

F# formará parte de la próxima versión de Visual Studio
Microsoft está construyendo una 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 un lenguaje .Net de primera clase y es el primer lenguaje funcional que viene con una base realmente grande (no es que diga que Lisp, Haskell, Erlang, Scala, OCaml no tengan muchas bibliotecas, simplemente no son tan completos como .Net es)
Fuerte apoyo al paralelismo

Contra:

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

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

Creo que una razón es que Algunas personas sienten que la parte más importante para determinar si un idioma será aceptado es qué tan bueno es..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 mayor de bibliotecas de terceros.

Lenguajes como Clojure o F# pueden ser la excepción a la regla considerando 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, paradigma, etc. favorito.aquí].

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

Me parece que aquellas personas que nunca aprendieron Lisp o Scheme cuando eran estudiantes ahora lo están descubriendo.Como ocurre 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 apoderará del mundo.C, C++, Java, C#, etc. seguirán existiendo.

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

Al leer "El próximo lenguaje de programación convencional:A Game Developer's Perspective" de Tim Sweeney, Epic Games, lo primero que pensé fue: aprendí Haskell.

PPT

Versión HTML de Google

Las cosas se han estado moviendo en una dirección funcional desde hace algún tiempo.Los dos nuevos y geniales chicos de los últimos años, Ruby y Python, están radicalmente más cerca de los lenguajes funcionales que los que los precedieron, hasta el punto de que algunos Lispers han comenzado a apoyar a uno u otro como "lo suficientemente cercano".

Y con el hardware masivamente paralelo ejerciendo presión evolutiva sobre todos (y los lenguajes funcionales en el mejor lugar para lidiar con los cambios), no es un salto tan grande como antes pensar que Haskell o F# serán la próxima gran novedad.

¿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 y las funciones de paso y retorno como valores solían ser características exóticas conocidas sólo por los piratas informáticos de Lisp y ML.Pero gradualmente, C#, Delphi, Python, Perl, Javascript han agregado soporte para cierres.No es posible que ningún lenguaje emergente se tome en serio sin cierres.
Varios lenguajes, en particular Python, C# y Ruby, tienen soporte nativo para listas por comprensión 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 aproximadamente.Si no recuerdo mal, Fortran admitía genéricos en 2003, seguido de Java 2004, C# en 2005 y 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.En el futuro, todos los idiomas apoyarán, como mínimo, los cierres si quieren seguir siendo competitivos.En este sentido, la programación funcional ya está de moda.

La mayoría de las aplicaciones son lo suficientemente simples como para resolverse de manera normal

¿Quién dice que no se puede utilizar la programación funcional también para cosas simples?No todos los programas funcionales necesitan ser un compilador, un demostrador de teoremas o un conmutador de telecomunicaciones masivamente paralelo.Utilizo F# con regularidad para scripts descartables ad hoc, además de mis proyectos más complicados.

Está ganando popularidad porque es la mejor herramienta que existe para controlar la complejidad.Ver:
- diapositivas 109-116 de la charla de Simon Peyton-Jones "A Taste of Haskell"
- "El próximo lenguaje de programación convencional:La perspectiva de un desarrollador de juegos" por Tim Sweeney

Verificar 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 las últimas en adoptarlo, si ven que se puede obtener una ventaja.La vida es dinámica.

Enseñaban 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 para "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 dado con algo importante:Podría ser el problema que no se puede resolver fácilmente por otros medios que impulsen la programación funcional.¿Qué sería eso?

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

Porque la FP tiene importantes beneficios en términos de productividad, confiabilidad y mantenibilidad.Muchos núcleos pueden ser una aplicación excelente que finalmente consiga 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: simplemente efectos secundarios. no encajan bien con la concurrencia y el paralelismo.

No estoy de acuerdo con que los programadores "normales" no lo entiendan.Lo harán, tal como finalmente entendieron la programación orientada a objetos (que es igual de misteriosa y extraña, si no más).

Además, la mayoría de universidades sí imparten FP, muchas incluso la imparten como primer curso de programación.

Vaya, 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 que no son FP).Los lenguajes que no pertenecen a FP ya están comenzando a tomar ideas de FP, por lo que sospecho que esta tendencia continuará y veremos más fusiones que deberían ayudar a las personas a dar el salto a FP más fácilmente.

No sé si tendrá éxito o no, pero según mis investigaciones, es casi seguro que vale la pena aprender un lenguaje funcional y te convertirá en un mejor programador.Simplemente comprender la transparencia referencial hace que muchas decisiones de diseño sean mucho más fáciles y que sea mucho más fácil razonar sobre los programas resultantes.Básicamente, si te encuentras con un problema, entonces tiende a ser solo un problema con la salida de una única 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 imparativo con efectos secundarios.

La naturaleza sin estado de FP se corresponde más naturalmente con 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 RESFULTAS.En contraste con los marcos JAVA y .NET que necesitan recurrir a HACKS horriblemente feos como las claves VIEWSTATE y SESSION para mantener el estado de la aplicación y mantener la abstracción (ocasionalmente con bastantes fugas) 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 podrá prestarse al procesamiento paralelo.Terriblemente importante para la web, si su sitio web se vuelve popular.No siempre es sencillo simplemente agregar más hardware a un sitio para obtener un mejor rendimiento.

Mi opinión es que se popularizará ahora que Microsoft lo ha impulsado mucho más hacia la corriente principal.Para mí es atractivo por lo que puede hacer por nosotros, porque es un nuevo desafío y por las oportunidades laborales que presenta para el futuro.

Una vez dominado, será otra herramienta que nos ayudará a ser más productivos como programadores.

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

Es interesante que uno pasa la mitad del tiempo escribiendo nombres de tipos cuando programa Java, pero Java no es, ni mucho menos, seguro para los tipos.Si bien es posible que nunca escriba tipos en un programa Haskell (excepto como una especie de documentación verificada por el compilador) y el código es 100% seguro.

Además de las otras respuestas, plantear la solución en términos puramente funcionales obliga a comprender mejor el problema.Por el contrario, pensar en 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.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow