¿Por qué lenguajes funcionales? [cerrado]


332

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?


John Hughes ha escrito un artículo sobre esto: Por qué es importante la programación funcional .
Hjulle

Respuestas:


214

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.


14
PUEDES hacer programación funcional en python, pero es realmente terrible. stackoverflow.com/questions/1017621/…
Gordon Gustafson

28
Es no difícil de escribir código IO en los lenguajes funcionales puros. Todos proporcionan un mecanismo simple para escribir código IO que funciona igual que en lenguajes imperativos. Todo lo que hacen es exigir que no se pueda llamar al código IO dentro de otro código cuya interfaz se declare como que no realiza IO. Una analogía sería un programador de lenguaje dinámico quejándose de que un lenguaje de tipo estático como Java le dificultaba devolver el tipo que quisiera de un método, porque tenía que devolver lo que la declaración de tipo decía que devolvería.
Ben

99
Haskell es un ejemplo de lenguaje funcional puro, que no tiene el inconveniente que usted dijo. Realmente hace que lidiar con los efectos secundarios sea mucho más fácil, porque los efectos secundarios están encapsulados, y permite al programador lograr un nivel de abstracción mucho más poderoso que los lenguajes imperativos ... Realmente, todos deberían probar Haskell, comprenderlo y darse cuenta por qué es tan poderoso
FtheBuilder

202

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.


55
Solo mira 20 años atrás. No creo que la programación haya evolucionado mucho. Bueno, tenga mejores herramientas, tal vez un nuevo idioma o 2, pero fundamentalmente no cambiará mucho. Esto llevará más de 20 años. Todos pensamos una vez que veríamos autos voladores en el 2000. :)
bibac

32
Sin embargo, O'Caml es irlandés.
defmeta

77
@alex extraño: "Favorecer la inmutabilidad" y "evitar efectos secundarios" han sido buenas reglas generales durante bastante tiempo tanto en las escuelas de programación orientadas a objetos como en las imperativas. (Entonces, ¿qué más se puede pedir ;-)?
joel.neely

101
@bibac: hace 20 años estábamos escribiendo código C y discutíamos los méritos de Clipper o Turbo Pascal. La orientación a objetos era el ámbito exclusivo de los académicos. Proponer que poco ha cambiado es francamente absurdo.
Daniel C. Sobral

24
@Daniel: Proporcione una lista de estas personas que abogaron por los "méritos" de Clipper. Necesitan ser perseguidos y llevados ante la justicia.
David

125

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.


44
Ya estamos viendo que esto suceda. Y sucederá más en el futuro. Así que estoy de acuerdo al 100% en este punto.
Jason Baker, el

Lo complicado es que son los aspectos de efectos secundarios compartidos de nada / no de FP que lo hacen tan adecuado para el paralelismo. Y esos son los aspectos que no encajan bien con las soluciones OO: hacer híbridos eficaces es extremadamente difícil. Tal vez el pegamento FP entre los nodos OO?
James Brady el

Para un híbrido efectivo, eche un vistazo a la rama 2.0 del lenguaje de programación D. Es un alfa / trabajo en progreso, pero está llegando allí.
dsimcha

2
Esta respuesta me pareció interesante, no conozco ningún lenguaje funcional, ¿por qué se consideran más adecuados para el paralelismo?
andandandand

26
Como no hay datos compartidos, las funciones no tienen efectos secundarios. Todo lo que le importa es el valor de retorno. (Esta es una idea bastante difícil para un programador de procedimientos / OO para entenderla). Por lo tanto, se pueden invocar muchas funciones a la vez, siempre que la salida de una no se use como entrada para otra.
Tom Smith

79

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.


Buen punto, pero me gustaría ver una explicación de "de qué manera te hará un mejor desarrollador"
mt3

20
Diferentes paradigmas de programación abordan los problemas desde diferentes ángulos y a menudo requieren una "forma diferente de pensar" o mentalidad. Y entrenarse en múltiples formas diferentes de pensar (lo que implica aprender cuál usar en cada situación ...) nunca es algo malo.
peSHIr

56

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 sé sobre las universidades del Reino Unido. Es muy probable que encuentre que muchas universidades aquí enseñan muy pocos lenguajes de programación (Java, C, tal vez Perl si tiene suerte). El problema aquí es la diferencia de calidad, ya que las mejores (pocas) universidades tienen los mejores programas de CS.
Mike B

No estoy de acuerdo con los ejemplos que dio son defectuosos, de nicho quizás, o adecuados para ciertas áreas, pero lo suficientemente generales como para ser abordados universalmente sin una curva de aprendizaje masiva. Esa es probablemente la razón principal por la que tienen tanto éxito.
gbjbaanb

Hice Forth y Lisp en la universidad en el Reino Unido (así como Pascal, C, Cobol y Modula2) pero eso fue hace 20 años ..
kpollock

29
Me enseñaron Java / C ++ en la universidad (en Australia), pero algunos de mis compañeros de trabajo fueron a diferentes universidades donde hicieron varias unidades en Haskell. Se utilizó tanto para la introducción a la programación como para una de sus unidades de último año. Me reí cuando escuché lo que mi compañero de trabajo le dijo a un profesor de Java después de que le presentaron el casting por primera vez (en este momento solo conocía a Haskell): "¡¿Qué ?! ¿Quieres decir que tienes algo y no lo haces?" ¡ ¿ SABES qué tipo es ?! "
Jacob Stanley

1
Mira lo que le pasó a C # con todos esos europeos en el equipo :)
Benjol

32

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


2
Así es como realmente comencé a cavar la programación funcional. Nada es mejor que la lista de Prototype.js. Cada (función (elemento) {}) o el método de operación completo de jQuery.
Cory R. King

20
Javascript le permite a uno programar de manera funcional. Es, sin embargo, un lenguaje de paradigma cruz, que permite a uno programa en una variedad de maneras diferentes (que yo prefiero, pero eso no es relevante) ... OO, funcional, de procedimiento, etc.
RHSeeger


Los métodos de objetos jQuery son solo operaciones en la lista mónada. Tomar un objeto que representa un contenedor (o secuencia) como entrada y devolver un contenedor de objetos como salida es un buen ejemplo de una reinvención práctica de fmap.
Jared Updike

25

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.


25

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

10
¿Cómo se considera Javascript la programación funcional?
Pacerier

8
Tiene funciones de primera clase, funciones de orden superior, cierres, funciones anónimas, aplicación parcial, currículum y composición.
daniel1426

2
Jaja. Una vez escribió una fórmula de Excel de pago de carga que era más ancha que la pantalla con funciones anidadas. Entonces supe que estaba programando funcionalmente, pero aún no conocía el término.
ProfK

77
Agregue C a esa lista
Mandeep Janjua

2
@MandeepJanjua: ¿Eh? ¿Cómo? ¿O por qué no cualquier idioma entonces?
Sz.

18

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. ;)


MIT solía enseñar Scheme en su curso de introducción CS, pero ahora usa Python.
mipadi

1
"Hace 15 años, no entendían la POO". El problema es que hace 15 años, tampoco entendían la PF. Y todavía no lo hacen hoy.
Jason Baker, el

15

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"


12

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.


12

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.


66
No creo que OO sea inherentemente más fácil que FP. Realmente depende de tus antecedentes (soy un chico de matemáticas, ¿adivinas lo que me resulta mucho más fácil? :) Maldita sea OO gente y tus reglas locas.
temp2290

14
Las mónadas no son difíciles de entender. No compre en ese bullcrap.
Rayne

-1 OOP es más difícil que FP
solo alguien

-1 No escribiríamos compiladores de optimización usando OCaml o Haskell si FP fuera apropiado solo para problemas matemáticos bonitos.
gracchus

8

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 #?


Buen comentario +1. @Mendelt: "más accesible"? ¿Quiere decir que el dolor de cabeza es más rápido cuando mira el código?
Patrick Honorez el

2
Consulte esta biblioteca de F #: quanttec.com/fparsec/tutorial.html . Me encantaría ver código de muestra en C # con analizadores que parecieran la mitad de elegantes y legibles que el código F #, incluso si se compilan con las mismas instrucciones. E intente portar FParsec de F # a C # y ver cómo se hincha el código.
Jared Updike

8

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?


2
* 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. Eso sigue siendo cierto para OOP en muchos lugares en los que he trabajado :) (por supuesto, dicen están haciendo POO, pero no lo están)
tolanj

7

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.


66
Yo diría que Scala fue una base bastante profunda con el JRE.
cdmckay

2
En cuanto a las bibliotecas, realmente depende de lo que estés haciendo. F # está dirigido al sector financiero y también es aplicable a la informática científica, pero OCaml en realidad tiene bibliotecas mucho mejores para tales aplicaciones que .NET. Por ejemplo, cuando llegué a F # de OCaml, no pude encontrar un FFT decente y terminé escribiendo (y vendiendo) el mío en C # y luego F #.
Jon Harrop

1
LINQ es un buen puente para usar conceptos funcionales con C # y VB.Net ... Y creo que es mucho menos doloroso de leer en comparación con F #
Matthew Whited

5

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.


+1, pero no olvides el poder del marketing y el hecho de que la montaña de código heredado de tu empresa no cambiará de idioma en virtud de alguna nueva tendencia.
temp2290

Y olvidó mencionar: Google está popularizando Python.
Hao Wooi Lim

4

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.


4

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.


1
C # ahora es un lenguaje de programación funcional (tanto como Lisp) porque tiene cierres léxicos de primera clase. De hecho, ya se usan en WPF y TPL. Obviamente, la programación funcional ya está aquí.
Jon Harrop


3

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.


3

¿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.



3

El enlace no se abre. Error 403.
Alexey Frunze


Enlace muerto Es por eso que este tipo de respuestas son desfavorables para las citas y los enlaces.
Sylwester

He arreglado el enlace. @Sylwester es cierto, pero es un documento de 23 páginas. Destilar el documento para responder en este sitio no le haría justicia.
Grom

2

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?


2

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.


Lo sentimos, pero FP ha existido casi 3 veces más que OOP. Esto simplemente no es una cuestión de necesitar más tiempo. Se necesitará algo más para hacer que FP sea una corriente principal.
Jason Baker, el

¿Cómo puedes perderte la parte de mi publicación en la que te explico que el "algo más" bien podría ser multinúcleo? Y algo "estar cerca" no es realmente relevante. La gente entendió la POO porque en ese momento ofrecía beneficios tangibles, la PF se ha vuelto práctica recientemente.
Sebastian

2

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.


2

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.


2

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.


2

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.


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.