Qu'est-ce qui a déclenché la popularité des fonctions lambda dans les langages de programmation traditionnels modernes?

112

Au cours des dernières années, les fonctions anonymes (fonctions AKA lambda) sont devenues une construction de langage très populaire et presque tous les langages de programmation majeurs / grand public les ont introduites ou sont prévues pour les introduire dans une prochaine révision de la norme.

Pourtant, les fonctions anonymes sont un concept très ancien et très connu en mathématiques et en informatique (inventé par le mathématicien Alonzo Church vers 1936 et utilisé par le langage de programmation Lisp depuis 1958, voir par exemple ici ).

Alors, pourquoi les langages de programmation traditionnels (dont beaucoup sont nés il y a 15 ou 20 ans) ne prennent-ils pas en charge les fonctions lambda depuis le début et ne les ont-ils introduits que plus tard?

Et qu'est-ce qui a déclenché l'adoption massive de fonctions anonymes ces dernières années? Existe-t-il un événement spécifique, une nouvelle exigence ou une technique de programmation à l'origine de ce phénomène?

NOTE IMPORTANTE

L'objet de cette question est l'introduction de fonctions anonymes dans les langages modernes (et donc, peut-être à quelques exceptions près, non fonctionnels). Notez également que des fonctions anonymes (blocs) sont présentes dans Smalltalk, qui n'est pas un langage fonctionnel, et que des fonctions nommées normales sont présentes même dans des langages procéduraux tels que C et Pascal.

Veuillez ne pas trop généraliser vos réponses en parlant de "l’adoption du paradigme fonctionnel et de ses avantages", car ce n’est pas le sujet de la question.

Giorgio
la source
7
Il y a 15 ou 20 ans, les gens se posaient la même question à propos de OO ... Ce n'était pas un nouveau concept, mais il connaissait une explosion de popularité.
MattDavey
7
@MattDavey La plupart des gens seraient certainement en désaccord, mais je devrais leur rappeler que "la plupart des développeurs Smalltalk" n'est pas si nombreux; P
yannis
30
Je pense que la question la plus intéressante est ce qui a déclenché leur disparition ! Après tout, il y avait un temps où la plupart des langues modernes fait ont lambdas, puis langages comme Java et C ++ sont devenus populaires. (Bien que je n'appellerais pas exactement Java un langage "moderne". Le concept le plus moderne de Java est Generics, qui remonte à la fin des années 60 / au début des années 70. Même la combinaison de fonctionnalités fournies par Java, la sécurité du pointeur, la sécurité de la mémoire, le type sécurité, GC, OO statiquement typé, les génériques ont tous existé à Eiffel en 1985… et bien mieux, à mon humble avis.)
Jörg W Mittag
31
Même avant la sortie de Java 1.0, alors que la conception en était encore à ses débuts, presque tout le monde a fait remarquer que Java avait besoin de lambdas. Parmi les concepteurs ayant travaillé sur Java, citons Guy Steele (promoteur Lisp, co-concepteur de Scheme, co-auteur de Common Lisp, concepteur de Fortress), James Gosling (auteur du premier interprète Emacs Lisp pour PC), Gilad Bracha (Smalltalk). promoteur, co-concepteur d'Animorphic Smalltalk, concepteur de Newspeak), Phil Wadler (co-concepteur de Haskell), Martin Odersky (concepteur de Scala). Comment Java a fini sans lambdas est vraiment au-delà de moi.
Jörg W Mittag
8
"Un tout petit peu" signifie souvent 50% de fonctionnement, 50% de bruit.
kevin cline

Réponses:

86

Il y a certainement une tendance notable vers la programmation fonctionnelle, ou du moins certains de ses aspects. Certains des langages populaires ayant à un moment adopté des fonctions anonymes sont le C ++ ( C ++ 11 ), PHP ( PHP 5.3.0 ), C # ( C # v2.0 ), Delphi (depuis 2009), Objective C ( blocs ), tandis que Java 8 apportera un soutien pour les lambdas à la langue . Et il existe des langages populaires qui ne sont généralement pas considérés comme fonctionnels, mais pris en charge depuis le début, ou du moins au début, par des fonctions anonymes, le meilleur exemple étant JavaScript.

Comme pour toutes les tendances, essayer de rechercher un événement unique qui les a déclenchées est probablement une perte de temps, il s'agit généralement d'une combinaison de facteurs, dont la plupart ne sont pas quantifiables. Pratique Common Lisp , publié en 2005, peut avoir joué un rôle important dans la nouvelle attention à Lisp en tant que pratique la langue, comme pour un certain Lisp temps était la plupart du temps une langue que vous souhaitez rencontrer dans un cadre universitaire ou des marchés de niche très spécifiques. La popularité de JavaScript a peut-être également joué un rôle important dans l’attention portée aux fonctions anonymes, comme l'explique munificent dans sa réponse .

Outre l'adoption de concepts fonctionnels issus de langages multi-usages, il existe également un changement notable vers les langages fonctionnels (ou principalement fonctionnels). Des langues comme Erlang (1986), Haskell (1990), OCaml (1996), Scala (2003), F # (2005), Clojure (2007) et même des langues spécifiques à un domaine comme R (1993) semblent avoir acquis une forte popularité. après leur introduction. La tendance générale a attiré l'attention sur les langages fonctionnels plus anciens, comme Scheme (1975) et, bien entendu, le Common Lisp.

Je pense que l’événement le plus important est l’adoption de la programmation fonctionnelle dans l’industrie. Je ne sais absolument pas pourquoi cela n’était pas le cas auparavant, mais il me semble qu’à un moment donné, au début et au milieu des années 90, la programmation fonctionnelle a commencé à trouver sa place dans l’industrie, à commencer (peut-être) par la prolifération d’ Erlang dans télécommunications et l'adoption de Haskell dans l'aérospatiale et la conception de matériel .

Joel Spolsky a écrit un article de blog très intéressant, The Perils of JavaSchools , dans lequel il s'oppose à la tendance des universités à privilégier Java par rapport à d'autres langues, peut-être plus difficiles à apprendre. Bien que le blog ait peu à voir avec la programmation fonctionnelle, il identifie un problème clé:

C'est là que réside le débat. Des années de blagues de laïcs CS comme moi, associées à des plaintes de l'industrie concernant le peu de diplômés en sciences des universités américaines, ont laissé des traces et au cours de la dernière décennie, un grand nombre d'écoles parfaitement performantes sont passées à Java à 100%. Les recruteurs qui utilisent "grep" pour évaluer les curriculum vitae semblent l’aimer, et, mieux encore, rien n’est assez difficile en Java pour vraiment écarter les programmeurs sans la partie du cerveau qui fait des pointeurs ou des récursions. les taux d'abandon sont plus bas et les départements d'informatique ont plus d'étudiants et des budgets plus importants, et tout va bien.

Je me souviens encore combien je détestais Lisp lorsque je l'ai rencontrée pour la première fois à l'université. C'est définitivement une maîtresse dure, et ce n'est pas une langue dans laquelle vous pouvez être immédiatement productif (enfin, au moins, je ne pouvais pas). Comparé à Lisp, Haskell (par exemple) est beaucoup plus convivial, vous pouvez être productif sans trop d'effort et sans vous sentir complètement idiot, ce qui pourrait également constituer un facteur important dans le passage à la programmation fonctionnelle.

Dans l'ensemble, c'est une bonne chose. Plusieurs langages à usages multiples adoptent des concepts de paradigme qui semblaient parfois obscurs à la plupart de leurs utilisateurs, et l'écart entre les paradigmes principaux se réduit.

Questions connexes:

Lectures complémentaires:

Yannis
la source
Merci pour la réponse (et beaucoup d'idées intéressantes). +1 Cependant, je dirais que l'introduction (uniquement) de lambdas dans un langage de programmation est un très petit pas en avant vers la PF, et qu'elle peut même dérouter beaucoup de gens (que font les lambdas seuls dans un langage impératif?). Après avoir appris quelques notions de Haskell, Scala et SML, je n’ai pas l’impression que je peux réaliser une vraie PF avec un langage impératif qui ne prend en charge que les lambdas (qu’en est-il du currying, de la correspondance des motifs, de l’immutabilité?).
Giorgio
2
@YannisRizos: Les fonctions de Perl étaient anonymes depuis la première publication de 5 (1994), mais elles n'étaient pas complètement "correctes" avant 5,004 (1997).
Blrfl
1
@penartur C'est ce que je pensais aussi, mais un éditeur sympathique m'a corrigé en me désignant ici: msdn.microsoft.com/en-us/library/0yw3tz5k%28v=vs.80%29.aspx
yannis
Je pense que le Web est peut-être le principal "événement" à l'origine de la popularité des langages fonctionnels. Plus spécifiquement, le passage des programmes de bureau au côté serveur. Cela donne au développeur la liberté de choisir n’importe quel langage de programmation. Paul Graham et Lisp dans les années 90 en sont un exemple notable.
Gilad Naor
32

Je trouve intéressant de constater combien la popularité de la programmation fonctionnelle a été parallèle à la croissance et à la prolifération de Javascript. Le langage Javascript présente de nombreuses fonctionnalités radicales dans le spectre de la programmation fonctionnelle qui, au moment de sa création (1995), n’étaient pas très populaires parmi les langages de programmation traditionnels (C ++ / Java). Il est soudainement devenu le seul langage de programmation Web côté client. Tout à coup, beaucoup de programmeurs devaient simplement connaître le langage Javascript et par conséquent, connaître les fonctionnalités du langage de programmation fonctionnel.

Je me demande quelle serait la popularité des langages / fonctionnalités fonctionnels sans l’augmentation soudaine de Javascript.

Doug T.
la source
5
Le javascript est certes un langage important, mais je ne suis pas sûr que l'introduction du javascript puisse expliquer à elle seule la popularité de la programmation fonctionnelle: de nombreux autres langages de programmation fonctionnels sont apparus au cours des dernières années, comme l'a illustré Yannis dans sa réponse. .
Giorgio
8
@Giorgio - il y a peut-être eu beaucoup d'autres langages de programmation fonctionnels, mais (relativement) personne ne les utilise. L’utilisation de JS et l’idée de plus en plus répandue que la méthode de création de foncteurs en C ++ / Java est douloureuse et agaçante sont réellement les forces motrices du courant dominant, même si les langages plus académiques précisent comment les mettre en œuvre.
Telastyn
1
La popularité des langages dynamiques en général est suggérée comme une explication de la popularité de Haskell: book.realworldhaskell.org/read/…
yannis
En outre, la question ne porte pas sur la popularité de la PF en général, mais sur l’ introduction tardive de fonctions anonymes dans des langages à usage général non fonctionnels. Même si le grand public (la plupart des programmeurs) ne les connaissait pas, les concepteurs de langages les connaissaient très bien. Il devait y avoir une raison pour les laisser au début. Peut-être étaient-ils considérés comme non intuitifs pour les développeurs du début des années 90.
Giorgio
@giorgio - Ils sont beaucoup plus difficiles à implémenter que les foncteurs de style Java. Combinez cela avec le manque de connaissances / d'adoption et c'est un choix de conception assez clair.
Telastyn
27

Les gestionnaires d’événements JavaScript et DOM signifiaient que des millions de programmeurs devaient au moins apprendre un peu plus sur les fonctions de première classe afin de réaliser toute interactivité sur le Web.

À partir de là, les fonctions anonymes sont relativement courtes . Comme JavaScript ne ferme pas this, il vous encourage également vivement à en apprendre davantage sur les fermetures. Et puis vous êtes en or: vous comprenez des fonctions anonymes de première classe qui se superposent à des portées lexicales.

Une fois que vous êtes à l'aise avec cela, vous le voulez dans toutes les langues que vous utilisez.

munificent
la source
7
+1, il ne s'agit pas uniquement de fonctions anonymes. Les fermetures sont un concept beaucoup plus large que la simple définition d'une fonction temporaire en ligne.
Phkahler
@phkahler: Vous avez raison et, dans ce sens, Java a déjà des fermetures (et même plus puissant que ce que vous obtenez avec un littéral de fonction), mais il manque une notation concise pour le cas courant d'une classe anonyme à une méthode.
Giorgio
17

Ce n'est certainement pas le seul facteur, mais je soulignerai la popularité de Ruby. Ne pas dire que cela est plus important que l'une des six réponses déjà inscrites au tableau, mais je pense que beaucoup de choses se sont produites en même temps et qu'il est utile de toutes les énumérer.

Ruby n’est pas un langage fonctionnel et ses lambdas, ses émules et ses blocs semblent maladroits quand vous avez utilisé quelque chose comme ML, mais le fait est qu’il a popularisé la notion de mapping et de réduction à une génération de jeunes programmeurs fuyant Java et PHP pour hipper les pâturages. Les lambda en plusieurs langues semblent être des mouvements défensifs plus que toute autre chose ("Restez dans le coin! Nous les avons aussi !!"

Mais la syntaxe de bloc et la façon dont elle s’intégrait avec .each, .map, .reduce et ainsi de suite ont popularisé l’idée d’une fonction anonyme même si c’est vraiment une construction syntaxique qui se comporte comme une coroutine. Et la conversion facile en proc via et en fait un médicament passerelle pour la programmation fonctionnelle.

Je soutiens que les programmeurs de Ruby on Rails écrivant en JavaScript étaient déjà prêts à faire des choses dans un style fonctionnel léger. Ajoutez à cela les blogs de programmeurs, l'invention de Reddit, le hacker News et le débordement de pile à peu près au même moment, et les idées se propagent plus rapidement sur Internet qu'à l'époque de Newsgroups.

TL; DR: Ruby, Rails, JavaScript, les blogs et Reddit / Hacker News / Stack Overflow ont propulsé les idées fonctionnelles vers un marché de masse, de sorte que tout le monde les souhaitait dans les langues existantes pour éviter de nouvelles défections.

Reg Braithwaite
la source
2
+1 pour une bonne réponse et (si je pouvais, parce que je n’ai qu’un vote positif) +1 pour avoir signalé que "Lambdas dans plusieurs langues semble être un mouvement défensif plus qu’autre chose (" Tenez-vous-en! Nous les avons aussi !!) ". Je pense que c'est aussi un facteur. Pour certaines langues, les lambdas sont une fonctionnalité intéressante qui, même si elle ajoute très peu de pouvoir expressif à la langue dans son ensemble, donne à la langue une certaine popularité (un nombre de programmeurs semblent penser que la prise en charge de fonctions anonymes équivaut à une prise en charge complète de la programmation fonctionnelle.)
Giorgio
2
Je pense vraiment que c’est la raison pour laquelle la plupart des langues ont implémenté la syntaxe de bloc ces dernières années. Mais le seul moyen de s’assurer est de demander aux développeurs de langages quelles étaient leurs motivations. Nous ne pouvons que spéculer imo.
SpoBo
Pour moi, Ruby est le langage qui a d'abord fait des blocs rock très attrayants, donc +1. Haskell aurait également pu avoir un effet.
rogerdpack
13

Comme Yannis l'a souligné, plusieurs facteurs ont influencé l'adoption de fonctions de haut niveau dans des langues qui étaient auparavant dépourvues. L’un des points importants qu’il a abordé à la légère est la prolifération de processeurs multicœurs et, partant, le souhait d’un traitement plus parallèle et simultané.

Le style de programmation fonctionnelle carte / filtre / réduction est très favorable à la parallélisation, permettant au programmeur d'utiliser facilement plusieurs cœurs, sans écrire de code de thread explicite.

Comme le note Giorgio, la programmation fonctionnelle ne se limite pas à des fonctions d'ordre élevé. Les fonctions, plus un schéma de programmation carte / filtre / réduction et l’ immuabilité sont au cœur de la programmation fonctionnelle. Ensemble, ces éléments constituent de puissants outils de programmation parallèle et simultanée. Heureusement, de nombreux langages supportent déjà une certaine notion d'immutabilité et, même s'ils ne le font pas, les programmeurs peuvent traiter les choses comme immuables, permettant ainsi aux bibliothèques et au compilateur de créer et de gérer des opérations asynchrones ou parallèles.

L'ajout de fonctions d'ordre élevé à un langage est une étape importante dans la simplification de la programmation simultanée.

Mise à jour

Je vais ajouter quelques exemples plus détaillés afin de répondre aux préoccupations de Loki.

Considérez le code C # suivant qui traverse une collection de widgets, créant une nouvelle liste de prix de widgets.

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

Pour une grande collection de widgets ou une méthode de calcul à calculer complexe (Widget), cette boucle ne ferait pas bon usage des cœurs disponibles. Pour effectuer les calculs de prix sur différents cœurs, le programmeur devrait explicitement créer et gérer des threads, passer le travail et collecter les résultats.

Envisagez une solution une fois que des fonctions d'ordre élevé ont été ajoutées à C #:

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

La boucle foreach a été déplacée dans la méthode Select, masquant ses détails d'implémentation. Le programmeur n'a plus qu'à indiquer à la fonction à appliquer à chaque élément. Cela permettrait à l’implémentation Select d’exécuter les calculs dans Parallel, en gérant toutes les préoccupations de synchronisation et de gestion des threads sans l’implication du programmeur.

Mais, bien sûr, Select ne fait pas son travail en parallèle. C'est là que l'immuabilité entre en jeu. L'implémentation de Select ne sait pas que la fonction fournie (CalculateWidgets ci-dessus) n'a pas d'effets secondaires. La fonction peut changer l'état du programme en dehors de la vue de Select et de sa synchronisation, en cassant tout. Par exemple, dans ce cas, la valeur de salesTax peut être modifiée par erreur. Les langages fonctionnels purs fournissent l’immuabilité, ainsi la fonction Select (map) peut savoir avec certitude qu’aucun état ne change.

C # résout ce problème en proposant PLINQ comme alternative à Linq. Cela ressemblerait à:

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

Ce qui exploite pleinement tous les cœurs de votre système sans une gestion explicite de ces cœurs.

Ben
la source
Je signale le souhait de davantage de traitements parallèles et simultanés, dont il est question dans l'article "A history of Erlang" d'ACM auquel je fais référence dans le quatrième paragraphe. Mais c'est un très bon point, et j'aurais probablement dû développer un peu plus. +1 parce que maintenant je ne suis pas obligé; P
yannis
Tu as raison, je n'ai pas regardé assez attentivement. J'ai édité ma remarque.
Ben
Oh, tu n'avais pas vraiment à faire ça, je ne me plaignais pas;)
yannis
4
Aucune de ce que vous décrivez ci-dessus ne nécessite de lambdas. La même fonctionnalité est obtenue aussi facilement avec les fonctions nommées. Ici, vous documentez simplement un causeet un perceived affectsans expliquer le correlation. La dernière ligne IMO est le sujet de la question; mais vous n'y avez pas répondu. Pourquoi simplifie-t-il la programmation simultanée?
Martin York
@Ben: Veillez à ce que votre exemple concerne des fonctions d'ordre supérieur ne nécessitant pas l'utilisation de fonctions anonymes. Votre réponse contient des idées intéressantes (pour une autre question) mais sort du sujet pour le moment.
Giorgio
9

Je suis d’accord avec beaucoup des réponses ici, mais ce qui est intéressant, c’est que lorsque j’ai appris à connaître les lambdas et que je leur sautais dessus, ce n’était pour aucune des raisons évoquées par d’autres.

Dans de nombreux cas, les fonctions lambda améliorent simplement la lisibilité de votre code. Avant lambdas lorsque vous appelez une méthode qui accepte un pointeur de fonction (ou une fonction, ou un délégué), vous devez définir le corps de cette fonction ailleurs. Par conséquent, lorsque vous avez la construction "foreach", votre lecteur doit passer à une autre une partie du code pour voir exactement ce que vous aviez l'intention de faire avec chaque élément.

Si le corps de la fonction qui traite les éléments ne contient que quelques lignes, j'utiliserais une fonction anonyme, car lorsque vous lisez du code, la fonctionnalité reste inchangée, mais le lecteur n'a pas à basculer, la mise en œuvre complète est juste là devant lui.

Beaucoup de techniques de programmation fonctionnelle et de parallélisation pourraient être réalisées sans fonctions anonymes; il suffit de déclarer un poste régulier et de passer une référence à cela chaque fois que vous en avez besoin. Mais avec lambdas, la facilité d’écriture du code et la facilité de lecture du code sont grandement améliorées.

DXM
la source
1
Très bonne explication (+1). Les programmeurs Lisp sont au courant de tout cela depuis 1958. ;-)
Giorgio
4
@Giorgio: Bien sûr, mais les programmeurs de Lisp ont également dû acheter des claviers spéciaux avec des touches de parenthèse ouvertes / fermées renforcées :)
DXM
@DXM: pas les claviers, ils ont un périphérique d'entrée supplémentaire qui est un peu comme une pédale de piano pour ouvrir et fermer les parenthèses ;-)
vartec
@DXM, vartec: Je fais quelque chose de récent et je trouve les parenthèses acceptables. Certains codes C ++ peuvent être beaucoup plus cryptiques (et j'ai beaucoup plus d'expérience avec C ++ qu'avec Scheme). :-)
Giorgio
9

Ayant été un peu impliqué dans l’histoire récente, j’estime que l’un des facteurs était l’ajout de médicaments génériques à Java et .NET. Cela conduit naturellement à Func < , > et à d'autres abstractions de calcul fortement typées (Task < >, Async < > etc.)

Dans le monde .NET, nous avons ajouté ces fonctionnalités précisément pour prendre en charge la FP. Cela a déclenché un ensemble de travaux de langage en cascade liés à la programmation fonctionnelle, notamment C # 3.0, LINQ, Rx et F #. Cette progression a également influencé d’autres écosystèmes et se poursuit encore aujourd’hui en C #, F # et TypeScript.

Bien sûr, il est utile que Haskell travaille chez MSR :)

Bien sûr, il y avait beaucoup d'autres influences aussi (JS bien sûr) et ces étapes ont été à leur tour influencées par bien d'autres choses - mais l'ajout de génériques à ces langues a permis de casser l'orthodoxie rigide de la fin des années 90 dans de nombreuses parties du monde du logiciel et d'ouvrir la voie. la porte pour FP.

Don Syme

ps F # était 2003 et non 2005 - bien que nous dirions qu'il n'a pas atteint 1.0 avant 2005. Nous avons également réalisé un prototype de Haskell.NET en 2001-02.

Don Syme
la source
Bienvenue! J'ai utilisé 2005 pour F #, car c'est l'année mentionnée dans l'article de Wikipédia dans F # comme l'année de la première publication stable. Voulez-vous que je le change en 2003?
Yannis
4

D'après ce que je vois, la plupart des réponses se concentrent sur l'explication de la raison pour laquelle la programmation fonctionnelle en général a fait son retour et a été introduite dans le grand public. J’ai eu l’impression que cela ne répondait pas vraiment à la question des fonctions anonymes en particulier et de la raison pour laquelle elles sont devenues si populaires.

Ce qui a vraiment gagné en popularité, ce sont les fermetures . Étant donné que dans la plupart des cas, les fermetures sont des fonctions jetables transmises de manière variable, il est évidemment logique d’utiliser une syntaxe de fonction anonyme pour celles-ci. Et en fait, dans certaines langues, c'est le seul moyen de créer une clôture.

Pourquoi les fermetures ont-elles gagné en popularité? Parce qu'ils sont utiles dans la programmation événementielle lors de la création de fonctions de rappel . C'est actuellement la façon d'écrire le code client JavaScript (en fait, c'est la façon d'écrire n'importe quel code d'interface graphique). C'est actuellement aussi la manière d'écrire du code back-end hautement efficace ainsi que du code système, car le code écrit dans un paradigme basé sur les événements est généralement asynchrone et non bloquant . Pour le back-end, cela devint populaire comme solution au problème C10K .

vartec
la source
Merci de souligner que cette question ne concerne pas la programmation fonctionnelle (+1) car (1) l’idée d’un bloc de code transmis comme argument est également utilisée dans des langages non fonctionnels comme Smalltalk, et (2) l’état de mutation capturé à partir du contexte lexical d’une fermeture (comme cela est possible dans de nombreuses implémentations lambda) est définitivement non fonctionnel . Et oui, en ce qui concerne les fermetures, le passage aux fermetures anonymes est court. Ce qui est intéressant, c’est que les fermetures sont également bien connues depuis longtemps et que la programmation événementielle est utilisée (à ma connaissance) depuis les années quatre-vingt.
Giorgio
Mais peut-être n’est-ce que depuis quelques années qu’il est devenu évident que les fermetures peuvent être utilisées beaucoup plus souvent que prévu.
Giorgio
@Giorgio: oui, la plupart des concepts actuellement utilisés existent depuis très longtemps. Pourtant, ils n'ont pas été utilisés comme ils le sont maintenant.
Vartec
1

Je pense que la raison en est la prévalence croissante de la programmation concurrente et distribuée, où le cœur de la programmation orientée objet (encapsuler des états changeants avec des objets) ne s'applique plus. Dans le cas d'un système distribué, car il n'y a pas d'état partagé (et les abstractions logicielles de ce concept ont des fuites) et dans le cas d'un système simultané, une synchronisation correcte de l'accès à un état partagé s'est avérée fastidieuse et source d'erreurs. En d’autres termes, l’un des principaux avantages de la programmation orientée objet ne s’applique plus pour de nombreux programmes, ce qui rend le paradigme orienté objet beaucoup moins utile qu’il le fut auparavant.

En revanche, le paradigme fonctionnel n'utilise pas l'état mutable. Toute expérience acquise avec les paradigmes et modèles fonctionnels est donc immédiatement transférable au calcul simultané et distribué. Et au lieu de réinventer la roue, l’industrie emprunte maintenant ces schémas et fonctionnalités linguistiques pour répondre à ses besoins.

meriton
la source
4
Les fonctions anonymes dans certains langages de flux principaux (par exemple, C ++ 11) autorisent les états mutables (elles peuvent même capturer des variables à partir de l'environnement de définition et les modifier au cours de leur exécution). Je pense donc que parler du paradigme fonctionnel en général et de l’immuabilité en particulier est un peu en dehors du champ de la question posée.
Giorgio
Après avoir lu quelques-unes des notes sur les fonctionnalités de Java 8, l’un des principaux objectifs du projet lambda est de prendre en charge la concurrence. Et CELA nous amène immédiatement à la grappe de mutabilité que tous ces javabéens merveilleux vont rencontrer. Une fois que Java a obtenu les lambdas (en supposant que ce soit vraiment le cas dans la version finale de la version 8), ils doivent alors résoudre le problème immuable par défaut (cela détruit en quelque sorte le langage, en pensant à Lisp - fonctions sans effets secondaires - à la place de en COBOL - coup sur DATA DIVISION / COPYBOOK)
Roboprog
Bien dit. L'abandon de l'état mutable facilite la concurrence et des technologies telles que cascalog et spark permettent de distribuer facilement une programmation fonctionnelle sur un groupe d'ordinateurs. Voir glennengstrand.info/analytics/distributed/functional/… pour plus de détails sur comment et pourquoi.
Glenn
1

Si je peux ajouter mes 0,02 €, bien que je sois d’accord avec l’importance de l’introduction du concept par JavaScript, je pense que plus que la programmation simultanée, je voudrais reprocher à la mode actuelle de la programmation asynchrone. Lorsque vous effectuez des appels asynchrones (nécessaires avec les pages Web), de simples fonctions anonymes sont tellement utiles que chaque programmeur Web (c'est-à-dire tout programmeur) devait se familiariser avec le concept.

mcepl
la source
1

Un autre très vieux exemple de fonctions / lambdas anonymes est l' appel par nom dans Algol 60. Notez cependant que l'appel par nom est plus proche du passage de macros en tant que paramètres que du passage de vraies fonctions, et qu'il est plus fragile / difficile à comprendre en conséquence.

Stephen C
la source
0

Voici l'ascendance au mieux de ma connaissance.

  • 2005: Javascript a récemment réintégré la programmation de niveau supérieur avec lambdas. Dans des bibliothèques particulières telles que underscore.js et jquery . Une des premières de ces bibliothèques était prototype.js, qui est antérieure à jquery d’environ un an. Prototype est basé sur le module Enumerable de Ruby, qui nous amène à…
  • 1996: Le module Enumerable de Ruby s'inspire très évidemment du cadre de collection de Smalltalk. Comme Matz l'a mentionné dans de nombreuses interviews, ce qui nous amène à…
  • 1980: Smalltalk utilise beaucoup de programmation d'ordre supérieur et fournit une API de collection qui utilise beaucoup la programmation d'ordre supérieur (par exemple, la classe Iterable de GNU Smalltalk ). Dans le code Smalltalk idiomatique, vous ne trouverez aucune boucle for, mais seulement des énumérations d’ordre élevé. Malheureusement, lorsque Java, lorsque la structure de collection de Smalltalk a été transférée à Java en 1998, les énumérations d’ordre supérieur ont été omises. C’est ainsi que la programmation d’ordre supérieur a été progressivement éliminée du grand public au cours des dix prochaines années! Le Smalltalk a de nombreux ancêtres, mais le LISP, qui nous amène à…
  • 1958: Le LISP est évidemment basé sur une programmation de niveau supérieur.
Akuhn
la source
Bien sûr, l’ascendance ML n’est pas un atout. ML, SML, OCaml, Haskell, F #. Cela doit compter pour quelque chose ..
Muhammad Alkarouri
-1

Les fonctions anonymes sont bien parce que nommer des choses est difficile, et si vous utilisez seulement une fonction à un endroit, elle n’a pas besoin d’un nom.

Les fonctions Lambda ont récemment été intégrées au grand public car, jusqu'à récemment, la plupart des langues ne prenaient pas en charge les fermetures.

Je dirais que Javascript a poussé ce courant dominant. C'est un langage universel qui ne permet pas d'exprimer le parallélisme et les fonctions anonymes facilitent l'utilisation des modèles de rappel. De plus, des langues populaires comme Ruby et Haskell ont contribué.

Matt Joiner
la source
1
"Les fonctions Lambda ont récemment été intégrées au grand public car, jusqu'à récemment, la plupart des langues ne prenaient pas en charge les fermetures.": Ce raisonnement me semble un peu circulaire: être traditionnel signifie que la plupart des langues le prennent en charge. On pourrait immédiatement se demander "Ce qui a déclenché la popularité des fermetures dans les langages de programmation modernes".
Giorgio
Je sais que Python n’a pas la meilleure implémentation de lambdas. Mais en termes de popularité, il a probablement contribué plus que Haskell.
Muhammad Alkarouri