¿Qué desencadenó la popularidad de las funciones lambda en los lenguajes de programación modernos?

112

En los últimos años, las funciones anónimas (funciones AKA lambda) se han convertido en una construcción de lenguaje muy popular y casi todos los lenguajes de programación principales / principales las han introducido o se planea introducirlas en una próxima revisión del estándar.

Sin embargo, las funciones anónimas son un concepto muy antiguo y muy conocido en Matemáticas e Informática (inventado por el matemático Alonzo Church alrededor de 1936, y utilizado por el lenguaje de programación Lisp desde 1958, véase, por ejemplo, aquí ).

Entonces, ¿por qué los lenguajes de programación convencionales de hoy (muchos de los cuales se originaron hace 15 a 20 años) admitían las funciones lambda desde el principio y solo las introdujeron más tarde?

¿Y qué provocó la adopción masiva de funciones anónimas en los últimos años? ¿Hay algún evento específico, un nuevo requisito o una técnica de programación que inició este fenómeno?

NOTA IMPORTANTE

El objetivo de esta pregunta es la introducción de funciones anónimas en lenguajes modernos, mainstream (y, por lo tanto, tal vez con algunas excepciones, no funcionales). Además, tenga en cuenta que las funciones anónimas (bloques) están presentes en Smalltalk, que no es un lenguaje funcional, y que las funciones con nombre normales han estado presentes incluso en lenguajes de procedimiento como C y Pascal durante mucho tiempo.

No generalice en exceso sus respuestas al hablar sobre "la adopción del paradigma funcional y sus beneficios", porque este no es el tema de la pregunta.

Giorgio
fuente
77
Hace 15-20 años, la gente hacía la misma pregunta sobre OO ... no era un concepto nuevo, pero tuvo una explosión de popularidad.
MattDavey el
77
@MattDavey Most ciertamente no estaría de acuerdo, pero luego tendría que recordarles que "la mayoría de los desarrolladores de Smalltalk" no son realmente tanta gente; P
Yannis
30
¡Creo que la pregunta más interesante es qué provocó su desaparición ! Después de todo, hubo un tiempo, cuando la mayoría de las lenguas modernas hizo tener lambdas, a continuación, lenguajes como Java y C ++ se hizo popular. (Aunque no llamaría exactamente a Java un lenguaje "moderno". El concepto más moderno en Java es Genérico, que se remonta a finales de los años 60 / principios de los 70. Incluso la combinación de características que proporciona Java, seguridad de puntero, seguridad de memoria, tipo seguridad, GC, OO de tipo estático, todos los genéricos existieron en Eiffel en 1985 ... y mucho mejor, en mi humilde opinión.)
Jörg W Mittag
31
Incluso antes de que saliera Java 1.0, mientras todavía estaba en las primeras etapas de diseño, casi todos señalaron que Java necesita lambdas. Algunos de los diseñadores que trabajaron en Java incluyen Guy Steele (proponente de Lisp, co-diseñador de Scheme, coautor de Common Lisp, diseñador de Fortress), James Gosling (escribió el primer intérprete de Emacs Lisp para PC), Gilad Bracha (Smalltalk proponente, co-diseñador de Animorphic Smalltalk, diseñador de Newspeak), Phil Wadler (co-diseñador de Haskell), Martin Odersky (diseñador de Scala). Cómo Java terminó sin lambdas está realmente más allá de mí.
Jörg W Mittag
8
"Un poquito" a menudo significa 50% de función, 50% de ruido.
Kevin Cline

Respuestas:

86

Ciertamente hay una tendencia notable hacia la programación funcional, o al menos ciertos aspectos de la misma. Algunos de los lenguajes populares que en algún momento adoptaron funciones anónimas son C ++ ( C ++ 11 ), PHP ( PHP 5.3.0 ), C # ( C # v2.0 ), Delphi (desde 2009), Objective C ( bloques ) mientras Java 8 traerá soporte para lambdas al idioma . Y hay lenguajes populares que generalmente no se consideran funcionales, sino que admiten funciones anónimas desde el principio, o al menos desde el principio, siendo el ejemplo brillante JavaScript.

Al igual que con todas las tendencias, tratar de buscar un solo evento que los haya provocado es probablemente una pérdida de tiempo, generalmente es una combinación de factores, la mayoría de los cuales no son cuantificables. Practical Common Lisp , publicado en 2005, puede haber jugado un papel importante al atraer nueva atención a Lisp como un lenguaje práctico , ya que durante bastante tiempo Lisp fue principalmente un idioma que conocerías en un entorno académico o en nichos de mercado muy específicos. La popularidad de JavaScript también puede haber jugado un papel importante en atraer nueva atención a las funciones anónimas, como explica munificent en su respuesta .

Además de la adopción de conceptos funcionales de lenguajes multipropósito, también hay un cambio notable hacia lenguajes funcionales (o mayormente funcionales). Idiomas como Erlang (1986), Haskell (1990), OCaml (1996), Scala (2003), F # (2005), Clojure (2007) e incluso los idiomas específicos de dominio como R (1993) parecen haber ganado un fuerte seguimiento. después de que fueron presentados. La tendencia general ha atraído nueva atención a los lenguajes funcionales más antiguos, como Scheme (1975) y, obviamente, Common Lisp.

Creo que el evento más importante es la adopción de programación funcional en la industria. No tengo ni idea de por qué no solía ser así, pero me parece que en algún momento durante la programación funcional de principios y mediados de los 90 comenzó a encontrar su lugar en la industria, comenzando (tal vez) con la proliferación de Erlang en telecomunicaciones y la adopción de Haskell en el diseño aeroespacial y de hardware .

Joel Spolsky ha escrito una publicación de blog muy interesante, The Perils of JavaSchools , donde argumenta en contra de la (entonces) tendencia de las universidades de favorecer Java sobre otros idiomas, quizás más difíciles de aprender. Aunque la publicación del blog tiene poco que ver con la programación funcional, identifica un problema clave:

Ahí radica el debate. Años de lloriqueo por parte de estudiantes universitarios perezosos de CS como yo, combinados con las quejas de la industria sobre cuán pocos graduados de CS se están graduando de las universidades estadounidenses, han cobrado su precio, y en la última década, un gran número de escuelas que de otra manera serían perfectamente buenas se volvieron 100% Java. Está de moda, a los reclutadores que usan "grep" para evaluar los currículums parece gustarles y, lo mejor de todo, no hay nada lo suficientemente difícil en Java para eliminar a los programadores sin la parte del cerebro que hace punteros o recursividad, por lo que las tasas de deserción son más bajas, y los departamentos de informática tienen más estudiantes y presupuestos más grandes, y todo está bien.

Todavía recuerdo cuánto odiaba a Lisp, cuando la conocí durante mis años universitarios. Definitivamente es una amante dura, y no es un lenguaje en el que puedas ser productivo de inmediato (bueno, al menos no pude). En comparación con Lisp, Haskell (por ejemplo) es mucho más amigable, puede ser productivo sin tanto esfuerzo y sin sentirse como un completo idiota, y eso también podría ser un factor importante en el cambio hacia la programación funcional.

En general, esto es algo bueno. Varios lenguajes multipropósito están adoptando conceptos de paradigma que podrían haber parecido arcanos a la mayoría de sus usuarios antes, y la brecha entre los paradigmas principales se está reduciendo.

Preguntas relacionadas:

Otras lecturas:

Yannis
fuente
Gracias por la respuesta (y muchas ideas interesantes). +1 Sin embargo, diría que introducir (solo) lambdas en un lenguaje de programación es un paso muy pequeño hacia FP, e incluso puede ser confuso para muchos (¿qué están haciendo lambdas solos dentro de un lenguaje imperativo?). Después de aprender algo de Haskell, Scala y SML, no tengo la sensación de que puedo hacer FP real con un lenguaje imperativo que solo admite lambdas (¿qué pasa con el curry y la coincidencia de patrones, la inmutabilidad?).
Giorgio el
2
@YannisRizos: Perl ha tenido funciones anónimas desde el primer lanzamiento de 5 (1994), pero no estaban completamente "correctas" hasta 5.004 (1997).
Blrfl
1
@penartur Eso fue lo que pensé también, pero un editor amigable me corrigió señalándome aquí: msdn.microsoft.com/en-us/library/0yw3tz5k%28v=vs.80%29.aspx
yannis
Creo que quizás el principal "evento" que provocó la popularidad de los lenguajes funcionales es la web. Más específicamente, el cambio de los programas de escritorio al lado del servidor. Esto le da al desarrollador la libertad de elegir cualquier lenguaje de programación. Paul Graham y Lisp en los años 90 es un ejemplo notable.
Gilad Naor
32

Creo que es interesante hasta qué punto la popularidad de la programación funcional ha sido paralela al crecimiento y la proliferación de Javascript. Javascript tiene muchas características radicales a lo largo del espectro de programación funcional que en el momento de su creación (1995) no eran muy populares entre los lenguajes de programación convencionales (C ++ / Java). Fue inyectado repentinamente en la corriente principal como el único lenguaje de programación web del lado del cliente. De repente, muchos programadores simplemente tenían que saber Javascript y, por lo tanto, tenían que saber algo sobre las características funcionales del lenguaje de programación.

Me pregunto qué tan populares serían las funciones / lenguajes funcionales si no hubiera sido por el repentino aumento de Javascript.

Doug T.
fuente
55
Javascript es seguramente un lenguaje importante, pero no estoy seguro si la introducción de Javascript puede explicar la popularidad de la programación funcional por sí sola: muchos otros lenguajes de programación funcional han aparecido en los últimos años, como Yannis ha ilustrado en su respuesta .
Giorgio el
8
@Giorgio: puede haber muchos otros lenguajes de programación funcionales, pero (relativamente) nadie los usa. El uso de JS y la mayor visión de que la forma C ++ / Java de crear functores es dolorosa y molesta son realmente las fuerzas impulsoras de la corriente principal, incluso si los lenguajes más académicos confirmaron cómo deberían implementarse.
Telastyn el
1
La popularidad de los lenguajes dinámicos en general se insinúa como una explicación de la popularidad de Haskell: book.realworldhaskell.org/read/…
yannis
Además, el foco de la pregunta no es la popularidad de FP en general, sino la introducción tardía de funciones anónimas en lenguajes no funcionales de uso general. Incluso si el gran público (la mayoría de los programadores) no los conocía, los diseñadores de idiomas los conocían muy bien. Debe haber habido una razón para dejarlos afuera al principio. Tal vez fueron considerados no intuitivos para los desarrolladores de los primeros años 90.
Giorgio el
@ giorgio: son mucho más problemáticos de implementar que los functors de estilo Java. Combine eso con la falta de conocimiento / adopción y es una opción de diseño bastante clara.
Telastyn el
27

JavaScript y DOM controladores de eventos significado que millones de programadores tenían que aprender al menos un poco sobre las funciones de primera clase con el fin de hacer ninguna interactividad en la web.

A partir de ahí, es un paso relativamente corto para las funciones anónimas . Debido a que JavaScript no se cierra this, también lo alienta a aprender sobre los cierres. Y luego eres dorado: entiendes funciones anónimas de primera clase que se cierran sobre los ámbitos léxicos.

Una vez que se sienta cómodo con él, lo querrá en todos los idiomas que use.

munificente
fuente
77
+1 no se trata solo de funciones anónimas. Los cierres son un concepto mucho más amplio que simplemente definir una función temporal en línea.
phkahler
@phkahler: Tienes razón y, en este sentido, Java ya tiene cierres (e incluso más poderoso que lo que obtienes con una función literal) pero carece de una notación concisa para el caso común de una clase anónima de un método.
Giorgio
17

Ciertamente no es el único factor, pero señalaré la popularidad de Ruby. No digo que esto sea más importante que cualquiera de las seis respuestas que ya están en la pizarra, pero creo que sucedieron muchas cosas a la vez y que es útil enumerarlas todas.

Ruby no es un lenguaje funcional y sus lambdas, productos y bloques parecen torpes cuando has usado algo como ML, pero el hecho es que popularizó la noción de mapeo y reducción a una generación de jóvenes programadores que huyen de Java y PHP por hipper pastizales Las lambdas en varios idiomas parecen ser movimientos defensivos más que cualquier otra cosa ("¡Quédate! ¡Nosotros también los tenemos!)

Pero la sintaxis de bloque y la forma en que se integraba con .each, .map, .reduce, etc., popularizaron la idea de una función anónima, incluso si realmente es una construcción sintáctica que se comporta como una rutina. Y la fácil conversión a un proceso a través de & lo convierte en un fármaco de entrada para la programación funcional.

Sostengo que los programadores de Ruby on Rails que escribían JavaScript ya estaban activados para hacer las cosas con un estilo funcional ligero. Combine eso con los blogs de programadores, la invención de Reddit, Hacker News y Stack Overflow al mismo tiempo, y las ideas se difundieron más rápido en Internet que en los días de grupos de noticias.

TL; DR: Ruby, Rails, JavaScript, blogging y Reddit / Hacker News / Stack Overflow impulsaron las ideas funcionales a un mercado masivo, por lo que todos las querían en los idiomas existentes para evitar nuevas deserciones.

Reg Braithwaite
fuente
2
+1 Por una buena respuesta y (si pudiera, porque solo tengo un voto a favor) +1 por señalar que "Lambdas en varios idiomas parecen ser movimientos defensivos más que cualquier otra cosa (" ¡Quédate! También tenemos esos !!) ". Creo que esto también es un factor. Para algunos idiomas, las lambdas son una característica agradable que, a pesar de que agrega muy poco poder expresivo al idioma en general, le da cierta popularidad (un número de programadores parecen pensar que el apoyo a funciones anónimas equivale a apoyar plenamente la programación funcional).
Giorgio
2
Realmente creo que esta es la razón por la cual la mayoría de los idiomas han implementado la sintaxis de bloque en los últimos años. Pero la única forma de asegurarse es preguntarle a los desarrolladores de idiomas cuáles fueron sus motivos. Solo podemos especular imo.
SpoBo
Para mí, Ruby es el lenguaje que primero hizo que los bloques fueran rockeros y muy atractivos, por lo que +1. Haskell podría haber tenido un efecto también.
rogerdpack
13

Como señaló Yannis , hay una serie de factores que han influido en la adopción de funciones de alto orden en idiomas que anteriormente no tenían. Uno de los elementos importantes que solo tocó a la ligera es la proliferación de procesadores multinúcleo y, con eso, el deseo de un procesamiento más paralelo y concurrente.

El estilo de programación funcional de mapa / filtro / reducción es muy amigable con la paralelización, lo que permite al programador utilizar fácilmente múltiples núcleos, sin escribir ningún código de subproceso explícito.

Como señala Giorgio, la programación funcional tiene más que funciones de alto orden. Las funciones, más un patrón de programación de mapa / filtro / reducción, y la inmutabilidad son el núcleo de la programación funcional. En conjunto, estas cosas hacen poderosas herramientas de programación paralela y concurrente. Afortunadamente, muchos lenguajes ya admiten alguna noción de inmutabilidad e, incluso si no lo hacen, los programadores pueden tratar las cosas como inmutables permitiendo que las bibliotecas y el compilador creen y administren operaciones asincrónicas o paralelas.

Agregar funciones de alto orden a un lenguaje es un paso importante para simplificar la programación concurrente.

Actualizar

Agregaré un par de ejemplos más detallados para abordar las preocupaciones que señaló Loki.

Considere el siguiente código C # que atraviesa una colección de widgets, creando una nueva lista de precios de widgets.

List<float> widgetPrices;
    float salesTax = RetrieveLocalSalesTax();
foreach( Widget w in widgets ) {
    widgetPrices.Add( CalculateWidgetPrice( w, salesTax ) );
}

Para una gran colección de widgets, o un método CalculateWidgetPrice (Widget) computacionalmente intensivo, este bucle no haría un buen uso de los núcleos disponibles. Hacer los cálculos de precios en diferentes núcleos requeriría que el programador cree y administre explícitamente hilos, pasando el trabajo y recopilando los resultados juntos.

Considere una solución una vez que se hayan agregado funciones de orden superior a C #:

var widgetPrices = widgets.Select( w=> CalculateWidgetPrice( w, salesTax ) );

El bucle foreach se ha movido al método Seleccionar, ocultando los detalles de su implementación. Todo lo que le queda al programador es decirle a Select qué función aplicar a cada elemento. Esto permitiría que la implementación de Select ejecute los cálculos en paralelo, manejando todas las preocupaciones de sincronización y gestión de subprocesos sin la participación del programador.

Pero, por supuesto, Select no hace su trabajo en paralelo. Ahí es donde entra en juego la inmutabilidad. La implementación de Select no sabe que la función proporcionada (CalculateWidgets arriba) no tiene efectos secundarios. La función podría cambiar el estado del programa fuera de la vista de Select y su sincronización, rompiendo todo. Por ejemplo, en este caso, el valor de salesTax podría modificarse por error. Los lenguajes funcionales puros proporcionan inmutabilidad, por lo que la función Seleccionar (mapa) puede saber con certeza que ningún estado está cambiando.

C # aborda esto proporcionando PLINQ como una alternativa a Linq. Eso se vería así:

var widgetPrices = widgets.AsParallel().Select(w => CalculateWidgetPrice( w, salesTax) );

Lo que hace un uso completo de todos los núcleos de su sistema sin una gestión explícita de esos núcleos.

Ben
fuente
Apunto al deseo de un procesamiento más paralelo y concurrente, se discute en el artículo de ACM "Una historia de Erlang" al que me estoy vinculando en el cuarto párrafo. Pero es un muy buen punto, y probablemente debería haberlo ampliado un poco más. +1 porque ahora no tengo que hacerlo; P
yannis
Tienes razón, no miré con suficiente cuidado. Edité mi comentario.
Ben
Oh, realmente no tenías que hacer eso, no me estaba quejando;)
yannis 03 de
44
Nada de lo que describe arriba requiere lambdas. La misma funcionalidad se logra con la misma facilidad con funciones con nombre. Aquí simplemente está documentando a causey a perceived affectsin explicar el correlation. La última línea de la OMI es de qué se trata la pregunta; pero no lo respondiste ¿Por qué simplifica la programación concurrente?
Martin York
@Ben: Tenga cuidado de que su ejemplo se refiera a funciones de orden superior que no necesitan funciones anónimas para ser utilizadas. Su respuesta contiene ideas interesantes (para otra pregunta) pero está saliendo del tema en este momento.
Giorgio el
9

Estoy de acuerdo con muchas de las respuestas aquí, pero lo interesante es que cuando aprendí sobre lambdas y salté sobre ellas, no fue por ninguna de las razones que otros han mencionado.

En muchos casos, las funciones lambda simplemente mejoran la legibilidad de su código. Antes de lambdas, cuando llama a un método que acepta un puntero de función (o función, o delega), tenía que definir el cuerpo de esa función en otro lugar, por lo que cuando tenía una construcción "foreach", su lector tendría que saltar a un punto diferente parte del código para ver exactamente qué planeaba hacer con cada elemento.

Si el cuerpo de la función que procesa elementos tiene solo unas pocas líneas, usaría una función anónima porque ahora cuando está leyendo el código, la funcionalidad permanece sin cambios, pero el lector no tiene que saltar de un lado a otro, toda la implementación es Justo delante de él.

Muchas de las técnicas de programación funcional y la paralelización podrían lograrse sin funciones anónimas; simplemente declare uno normal y pase una referencia a eso siempre que lo necesite. Pero con la facilidad de escritura del código lambdas y la facilidad de lectura del código se mejora enormemente.

DXM
fuente
1
Muy buena explicación (+1). Los programadores de Lisp han sido conscientes de todo esto desde 1958. ;-)
Giorgio el
44
@Giorgio: Claro, pero los programadores de lisp también tuvieron que comprar teclados especiales con teclas de paréntesis abiertas / cerradas reforzadas :)
DXM
@DXM: no teclados, obtienen un dispositivo de entrada adicional que es como pedales de piano para abrir y cerrar paréntesis ;-)
vartec
@DXM, vartec: He estado haciendo algunos esquemas últimamente y los paréntesis me parecen correctos. Algunos códigos de C ++ pueden ser mucho más crípticos (y tengo mucha más experiencia con C ++ que con Scheme). :-)
Giorgio
9

Después de haber estado involucrado en la historia reciente aquí un poco, creo que un factor fue la adición de genéricos a Java y .NET. Eso naturalmente conduce a Func < , > y otras abstracciones computacionales fuertemente tipadas (Tarea < >, Async < > etc.)

En el mundo .NET, agregamos estas características precisamente para admitir FP. Eso desencadenó un conjunto de trabajos de lenguaje en cascada relacionados con la programación funcional, especialmente C # 3.0, LINQ, Rx y F #. Esa progresión también influyó en otros ecosistemas y aún continúa en C #, F # y TypeScript.

También ayuda tener a Haskell trabajando en MSR, por supuesto :)

Por supuesto, también hubo muchas otras influencias (JS ciertamente) y estos pasos fueron a su vez influenciados por muchas otras cosas, pero agregar genéricos a estos idiomas ayudó a romper la rígida ortodoxia OO de finales de los 90 en gran parte del mundo del software y ayudó a abrir la puerta para FP.

Don Syme

ps F # era 2003, no 2005, aunque diríamos que no alcanzó 1.0 hasta 2005. También hicimos un prototipo de Haskell.NET en 2001-02.

Don Syme
fuente
¡Bienvenidos! Usé 2005 para F #, ya que ese es el año informado en el artículo de Wikipedia de F # como el año de la primera versión estable. ¿Quieres que lo cambie a 2003?
Yannis
4

Por lo que veo, la mayoría de las respuestas se concentran en explicar por qué la programación funcional en general regresó y llegó a la corriente principal. Sin embargo, sentí que esto realmente no responde la pregunta sobre las funciones anónimas en particular, y por qué de repente se hicieron tan populares.

Lo que realmente ha ganado popularidad son los cierres . Dado que en la mayoría de los casos los cierres son funciones descartables que pasan variables, obviamente tiene sentido usar la sintaxis de funciones anónimas para estos. Y, de hecho, en algunos idiomas es la única forma de crear un cierre.

¿Por qué los cierres han ganado popularidad? Porque son útiles en la programación controlada por eventos, al crear funciones de devolución de llamada . Actualmente es la forma de escribir código de cliente JavaScript (de hecho, es la forma de escribir cualquier código GUI). Actualmente también es la forma de escribir código de fondo altamente eficiente, así como el código del sistema, ya que el código escrito en el paradigma controlado por eventos suele ser asíncrono y sin bloqueo . Para el back-end, esto se hizo popular como solución al problema C10K .

vartec
fuente
Gracias por subrayar que esta pregunta no se trata de programación funcional (+1) porque (1) la idea de un bloque de código que se pasa como argumento también se usa en lenguajes no funcionales como Smalltalk, y (2) estado mutante capturado del contexto léxico de un cierre (como es posible en muchas implementaciones lambda) definitivamente no es funcional . Y sí, al tener cierres, el paso a los cierres anónimos es corto. Lo interesante es que los cierres también se conocen desde hace mucho tiempo, y la programación basada en eventos se ha utilizado (hasta donde yo sé) desde los años ochenta.
Giorgio
Pero tal vez fue solo en los últimos años que quedó claro que los cierres se pueden usar con mucha más frecuencia de lo que se pensaba anteriormente.
Giorgio
@Giorgio: sí, la mayoría de los conceptos que se utilizan actualmente han existido durante mucho, mucho tiempo. Sin embargo, no se han utilizado de la manera, se usan ahora.
vartec
1

Creo que la razón es la creciente prevalencia de la programación concurrente y distribuida, donde el núcleo de la programación orientada a objetos (encapsulando el estado cambiante con objetos) ya no se aplica. En el caso de un sistema distribuido, porque no es ningún estado compartido (y abstracciones de software de este concepto son fugas) y en el caso de un sistema concurrente, porque correctamente la sincronización de acceso a estado compartido ha demostrado engorroso y propenso a errores. Es decir, uno de los beneficios clave de la programación orientada a objetos ya no se aplica a muchos programas, lo que hace que el paradigma orientado a objetos sea mucho menos útil de lo que solía ser.

En contraste, el paradigma funcional no usa el estado mutable. Cualquier experiencia que obtengamos con paradigmas y patrones funcionales es, por lo tanto, transferible de manera más inmediata a la computación concurrente y distribuida. Y en lugar de reinventar la rueda, la industria ahora toma prestados esos patrones y características del lenguaje para satisfacer sus necesidades.

Meriton
fuente
44
Las funciones anónimas en algunos lenguajes principales (por ejemplo, C ++ 11) permiten un estado mutable (incluso pueden capturar variables del entorno de definición y cambiarlas durante su ejecución). Así que creo que hablar sobre el paradigma funcional en general y sobre la inmutabilidad en particular está un poco fuera del alcance de la pregunta que se hace.
Giorgio el
Después de leer algunas de las notas de características para Java 8, uno de los objetivos principales del proyecto lambda es apoyar la concurrencia. Y ESO inmediatamente nos lleva a la bomba de clúster de mutabilidad con la que se encontrarán todos estos maravillosos JavaBeans. Una vez que Java obtiene lambdas (suponiendo que realmente lo haga en la versión final de la versión 8), entonces deben abordar el problema inmutable por defecto, de alguna manera (en cierto modo destruye el lenguaje, pensando en Lisp - funciones libres de efectos secundarios - en su lugar de en COBOL - whack on DATA DIVISION / COPYBOOK)
Roboprog
Bien dicho. El alejamiento del estado mutable facilita la concurrencia y las tecnologías como cascalog y spark distribuyen fácilmente la programación funcional en un grupo de computadoras. Consulte glennengstrand.info/analytics/distributed/functional/… para obtener más detalles sobre cómo y por qué.
Glenn
1

Si puedo agregar mis € 0.02, aunque estaría de acuerdo con la importancia de que JavaScript introduzca el concepto, creo que más que la programación concurrente culparía a la moda actual de la programación asincrónica. Cuando se realizan llamadas asíncronas (necesarias con las páginas web), las funciones anónimas simples son tan evidentemente útiles que cada programador web (es decir, cada programador) tuvo que familiarizarse con el concepto.

mcepl
fuente
1

Otro ejemplo muy antiguo de algo parecido a funciones anónimas / lambdas es la llamada por nombre en Algol 60. Sin embargo, tenga en cuenta que la llamada por nombre está más cerca de pasar macros como parámetros que pasar funciones verdaderas, y es más frágil / difícil de identificar. entender como resultado.

Stephen C
fuente
0

Aquí la ascendencia a lo mejor de mi conocimiento.

  • 2005: Javascript ha traído recientemente la programación de orden superior con lambdas a la corriente principal. En bibliotecas particulares como underscore.js y jquery . Una de las primeras de estas bibliotecas fue prototype.js, que es anterior a jquery en aproximadamente un año. Prototype se basa en el módulo Enumerable de Ruby, que nos lleva a ...
  • 1996: el módulo Enumerable de Ruby se inspiró muy obviamente en el marco de la colección de Smalltalk. Como ha sido mencionado por Matz en muchas entrevistas, lo que nos lleva a ...
  • 1980: Smalltalk utiliza una gran cantidad de programación de orden superior y proporciona una API de recopilación que hace un uso intensivo de la programación de orden superior (por ejemplo, la clase Iterable de GNU Smalltalk ). En el código idiomático de Smalltalk no encontrará ninguno para bucles sino solo enumeraciones de alto orden. Desafortunadamente, cuando Java, cuando el marco de colección de Smalltalk fue portado a Java en 1998, las enumeraciones de orden superior se quedaron fuera. ¡Así es como la programación de orden superior fue eliminada de la corriente principal durante los próximos diez años! Smalltalk tiene muchos ancestros, pero relevante para la pregunta de OP es LISP, que nos lleva a ...
  • 1958: LISP, obviamente, tiene una programación de orden superior en su núcleo.
akuhn
fuente
Amiss, por supuesto, es toda la ascendencia de ML. ML, SML, OCaml, Haskell, F #. Eso tiene que contar para algo ...
Muhammad Alkarouri
-1

Las funciones anónimas son buenas porque nombrar cosas es difícil, y si solo usa una función de una vez, no necesita un nombre.

Las funciones de Lambda se han convertido en una corriente principal recientemente porque hasta hace poco, la mayoría de los idiomas no admitían cierres.

Sugeriría que Javascript ha impulsado esta corriente principal. Es un lenguaje universal que no tiene forma de expresar paralelismo, y las funciones anónimas facilitan el uso de modelos de devolución de llamada. Además, han contribuido idiomas populares como Ruby y Haskell.

Matt Joiner
fuente
1
"Las funciones de Lambda se han convertido recientemente en mainstream porque hasta hace poco, la mayoría de los idiomas no admitían cierres". Este razonamiento me suena un poco circular: ser mainstream significa que la mayoría de los idiomas lo admiten. Uno podría preguntarse de inmediato "¿Qué provocó la popularidad de los cierres en los lenguajes de programación modernos".
Giorgio el
Sé que Python no tiene la mejor implementación de lambdas. Pero en términos de popularidad, probablemente contribuyó más que Haskell.
Muhammad Alkarouri