Що спричинило популярність лямбда-функцій у сучасних мовах програмування?


112

В останні кілька років анонімні функції (AKA лямбда-функції) стали дуже популярною мовною конструкцією, і майже кожна основна / основна мова програмування запровадила їх або планується впровадити в майбутній редакції стандарту.

Тим не менше, анонімні функції - це дуже давнє і дуже відоме поняття з математики та інформатики (винайдене математиком Церквою Алонцо близько 1936 року, а мова програмування Ліспа використовується з 1958 року, див., Наприклад, тут ).

То чому б сьогоднішні основні мови програмування (багато з яких виникли 15-20 років тому) не підтримували лямбда-функції з самого початку і лише впроваджували їх пізніше?

І що викликало масове прийняття анонімних функцій в останні кілька років? Чи є якась конкретна подія, нова вимога або техніка програмування, яка розпочала це явище?

ВАЖЛИВА ПРИМІТКА

Основна увага в цьому питанні - введення анонімних функцій у сучасних, основних (та, можливо, за кількома винятками, нефункціональних) мовах. Також зауважте, що анонімні функції (блоки) присутні у Smalltalk, що не є функціональною мовою, і що звичайні названі функції вже давно існують навіть у таких процедурних мовах, як C та Pascal.

Будь ласка, не надто узагальнюйте свої відповіді, говорячи про "прийняття функціональної парадигми та її переваг", адже це не тема питання.


7
15-20 років тому люди задавали той самий питання про ОО ... це не нова концепція, але вона мала вибух популярності.
MattDavey

7
@MattDavey Більшість, безумовно, не погодиться, але тоді я повинен би нагадати їм, що "більшість розробників Smalltalk" насправді не так вже й багато людей; P
yannis

30
Думаю, цікавішим є питання, що спричинило їхню смерть ! В кінці кінців, був час, коли більшість сучасних мов справді є лямбда, то мови , як Java і C ++ стали популярними. (Хоча я точно не назвав би Java "сучасною" мовою. Найсучаснішою концепцією на Java є Generics, яка бере свій початок з кінця 60-х - початку 70-х. Навіть поєднання функцій, які надає Java, безпека вказівника, безпека пам'яті, тип безпека, GC, статично набраний OO, Generics все існувало в Ейфелі в 1985 році ... і набагато краще, IMHO.)
Jörg W Mittag

31
Ще до появи Java 1.0, поки вона ще була на ранніх етапах проектування, майже всі вказували, що Java потрібні лямбда. Деякі з дизайнерів, які працювали над Java, включають Гая Стіла (прихильник Lisp, співавтор Scheme, співавтор Common Lisp, дизайнер Fortress), Джеймс Гослінг (написав першого перекладача Emacs Lisp для ПК), Гілад Браша (Smalltalk прихильник, співавтор Animorphic Smalltalk, дизайнер Newspeak), Філ Вадлер (співавтор компанії Haskell), Мартін Одерський (дизайнер Scala). Те, як Ява опинився без лямбда, насправді не виходить за мене.
Йорг W Міттаг

8
"Крихітний шматочок" часто означає 50% функції, 50% шуму.
Кевін Клайн

Відповіді:


86

Звичайно, помітна тенденція до функціонального програмування або хоча б певних його аспектів. Деякі з популярних мов, які в якийсь момент прийняли анонімні функції, - це C ++ ( C ++ 11 ), PHP ( PHP 5.3.0 ), C # ( C # v2.0 ), Delphi (з 2009 року), ціль C ( блоки ), а Java 8 принесе підтримку лямбдам для мови . І є популярні мови, які, як правило, не вважаються функціональними, але підтримуються анонімними функціями з самого початку, або принаймні на початку, яскравим прикладом є JavaScript.

Як і у всіх тенденціях, намагання шукати одну подію, яка їх викликала, - це, мабуть, марна трата часу, зазвичай це поєднання факторів, більшість з яких неможливо оцінити. Практичний звичайний Lisp , опублікований у 2005 році, можливо, зіграв важливу роль у приверненні нової уваги до Lisp як до практичної мови, оскільки довгий час Lisp був здебільшого мовою, яку ви зустрінете в академічній обстановці, або дуже специфічною ринковою нішею. Популярність JavaScript також могла зіграти важливу роль у приверненні нової уваги до анонімних функцій, як це чудово пояснює у своїй відповіді .

Крім прийняття функціональних концепцій з багатоцільових мов, спостерігається також помітний перехід до функціональних (або переважно функціональних) мов. Такі мови, як Erlang (1986), Haskell (1990), OCaml (1996), Scala (2003), F # (2005), Clojure (2007), і навіть мови, характерні для домену, такі як R (1993), начебто отримали сильний наступ після того, як вони були представлені. Загальна тенденція привернула нову увагу до старих функціональних мов, як Scheme (1975), і, очевидно, Common Lisp.

Я думаю, що важливішою подією є прийняття функціонального програмування в галузі. Я абсолютно не маю ідеї, чому це не було так, але мені здається, що в якийсь момент на початку та середині 90-х функціональне програмування почало знаходити своє місце в галузі, починаючи (можливо) з розповсюдження Ерланга в телекомунікації та прийняття Haskell в галузі аерокосмічної та апаратної конструкції .

Джоель Спольський написав дуже цікавий пост у блозі «Небезпеки JavaSchools» , де він заперечує проти (тодішньої) тенденції університетів надавати перевагу Яві перед іншими, можливо більш складними для вивчення мов. Хоча публікація в блозі мало спільного з функціональним програмуванням, вона визначає ключову проблему:

У цьому криються дебати. Роки уболівальників ледачих підлеглих CS, як я, у поєднанні зі скаргами промисловості на те, як мало спеціальностей CS закінчують американські університети, взяли свою справу, і за останнє десятиліття велика кількість інакше ідеально хороших шкіл пішло на 100% Java. Це хіп, рекрутерам, які використовують "grep" для оцінки резюме, здається, це подобається, і, найкраще, немає нічого важкого в тому, щоб Java справді відсікала програмістів без тієї частини мозку, яка робить покажчики або рекурсії, тому коефіцієнти відсіву нижчі, і на кафедрах інформатики є більше студентів, і більший бюджет, і все добре.

Я все ще пам’ятаю, як сильно ненавидів Лісп, коли вперше зустрівся з нею в роки навчання в коледжі. Це, безумовно, сувора господиня, і це не мова, де ти можеш бути негайно продуктивним (ну, принаймні, я не міг). Порівняно з Ліспом, Haskell (наприклад) набагато привітніше, ви можете бути продуктивними без особливих зусиль і не відчуваючи себе повноцінним ідіотом, і це також може бути важливим фактором у переході на функціональне програмування.

Загалом, це гарна річ. Кілька багатоцільових мов приймають поняття парадигми, які, здавалося б, здавалися таємницькими для більшості їх користувачів раніше, і розрив між основними парадигмами звужується.

Пов’язані запитання:

Подальше читання:


Дякую за відповідь (і багато цікавих ідей). +1 Але я б заперечував, що введення (лише) лямбда в мову програмування - це дуже маленький крок на шляху до ФП, і це може навіть бентежити багатьох (що ж лямбди роблять всі наодинці в імперативній мові?). Дізнавшись про Haskell, Scala та SML, я не маю відчуття, що я можу зробити справжній FP з необхідною мовою, яка підтримує лише лямбда (що з currying та узгодженням шаблону, незмінністю?).
Джорджіо


2
@ YannisRizos: Перл мав анонімні функції з першого виходу 5 (1994), але вони не були повністю "правильними" до 5.004 (1997).
Blrfl

1
@penartur Це теж я подумав, але доброзичливий редактор виправив мене, вказавши мене тут: msdn.microsoft.com/en-us/library/0yw3tz5k%28v=vs.80%29.aspx
yannis

Я думаю, що, мабуть, головна «подія», яка спричинила популярність функціональних мов, - це Інтернет. Більш конкретно, перехід від настільних програм на сторону сервера. Це дає розробникові свободу вибору будь-якої мови програмування. Пол Грехем і Лісп у 90-х - помітний приклад.
Гілад Наор

32

Думаю, цікавим є те, наскільки популярність функціонального програмування паралельно зростає та розповсюджується Javascript. Javascript має багато радикальних особливостей уздовж функціонального спектра програмування, які на момент його створення (1995 р.) Не користувалися великою популярністю серед основних програмних мов (C ++ / Java). Його внесли раптово в основний потік як єдину мову веб-програмування на стороні клієнта. Раптом багатьом програмістам просто довелося знати Javascript, і тому вам довелося знати щось з функціональних особливостей мови програмування.

Цікаво, якими популярними функціональними мовами / функціями були б, якби не раптовий підйом Javascript.


5
Javascript, безумовно, є важливою мовою, але я не впевнений, чи введення Javascript може спричинити популярність функціонального програмування самостійно: за останні роки з'явилося багато інших мов функціонального програмування, як проілюстрував Янніс у своїй відповіді .
Джорджіо

8
@Giorgio - можливо, було багато інших функціональних мов програмування, але (відносно) їх ніхто не використовує. Використання JS та посилене уявлення про те, що спосіб C ++ / Java зробити функторів болючим і дратівливим, насправді є рушійними силами до основних напрямків, навіть якщо більше академічних мов підкреслило те, як їх потрібно реалізувати.
Теластин

1
На популярність динамічних мов загалом натякають як одне пояснення популярності Haskell: book.realworldhaskell.org/read/…
yannis

Також у центрі уваги питання не популярність ПП загалом, а про несвоєчасне введення анонімних функцій у нефункціональні мови загального призначення. Навіть якщо велика публіка (більшість програмістів) їх не знала, мовні дизайнери їх дуже добре знали. Мабуть, була причина, щоб їх не було на початку. Можливо, вони вважалися неінтуїтивними для розробників початку 90-х років.
Джорджіо

@giorgio - Реалізувати їх набагато складніше, на відміну від функціонерів стилю Java. Поєднуйте це з відсутністю знань / прийняття, і це досить чіткий вибір дизайну.
Теластин

27

Обробники подій JavaScript та DOM означали, що мільйонам програмістів довелося хоч трохи навчитися функціям першого класу, щоб робити будь-яку інтерактивність в Інтернеті.

Звідси це порівняно короткий крок до анонімних функцій. Оскільки JavaScript не закривається this, він також наполегливо рекомендує вам дізнатися про закриття. І тоді ти золотий: ти розумієш анонімні функції першого класу, які закриваються за допомогою лексичних областей.

Після того, як вам це зручно, ви хочете його будь-якою мовою, якою ви користуєтеся.


7
+1 - це не лише анонімні функції. Закриття - це набагато ширше поняття, ніж просто визначення тимчасової функції в рядку.
phkahler

@phkahler: Ви маєте рацію, і в цьому сенсі у Java вже є закриття (і навіть більш потужні, ніж те, що ви отримуєте з функцією буквально), але йому не вистачає стислого позначення для загального випадку одноактивного анонімного класу.
Джорджіо

17

Це, звичайно, не єдиний фактор, але я зазначу популярність Рубі. Не кажучи про це важливіше, ніж будь-який із шести відповідей, які вже є на дошці, але я думаю, що багато речей сталося одразу і що корисно перерахувати їх усі.

Ruby - це не функціональна мова, і її лямбди, приладдя та блоки здаються незграбними, коли ви використовуєте щось на зразок ML, але факт полягає в тому, що вона популяризувала поняття відображення та скорочення до покоління молодих програмістів, що рятуються від Java та PHP для хіперів пасовища. Лямбди на декількох мовах здаються оборонними рухами більше, ніж будь-що інше ("Притримуйся! У нас теж є!"

Але синтаксис блоку і спосіб його інтеграції з .each, .map, .reduce і так далі популяризували ідею анонімної функції, навіть якщо це дійсно синтаксична конструкція, яка поводиться як коренева програма. А просте перетворення на додаток через & робить його препаратом для функціонального програмування.

Я стверджую, що програмісти Ruby on Rails, що пишуть JavaScript, вже ввійшли до того, щоб робити речі у легкому функціональному стилі. У поєднанні з блогом програмістів, винаходом Reddit, хакерських новин та Stack Overflow приблизно в один і той же час, і ідеї поширюються швидше в Інтернеті, ніж це було за часів Групи новин.

TL; DR: Ruby, Rails, JavaScript, ведення блогів та Reddit / Hacker News / Stack Overflow висунуло функціональні ідеї на масовий ринок, тому всі бажали, щоб вони існували на інших мовах, щоб запобігти подальшим дефектам.


2
+1 За гарну відповідь і (якщо я міг би, тому що у мене є лише один підсумок) +1 за те, що "Ламбдаси на декількох мовах здаються оборонними рухами більше, ніж будь-що інше (" Дотримуйтесь! У нас теж є !!) ". Я думаю, що це також є фактором. Для деяких мов лямбди - це приємна функція, яка, хоч і додає дуже мало виразної сили мові в цілому, надає мові деяку популярність ( кількість программістів, здається, вважає, що підтримка анонімних функцій еквівалентна повністю підтримуючому функціональному програмуванню.
Giorgio

2
Я дійсно думаю, що це причина, чому більшість мов впровадили синтаксис блоків за останні роки. Але єдиний спосіб переконатися - запитати у розробників мови, які були їхні мотиви. Ми можемо лише міркувати imo.
SpoBo

для мене Рубі - це мова, яка вперше зробила блоки рок і дуже приваблива, тому +1. Хаскелл також міг мати ефект.
rogerdpack

13

Як зазначив Янніс , існує низка факторів, які вплинули на прийняття функцій високого порядку в мовах, які раніше не були. Одним із важливих пунктів, якого він лише злегка торкнувся, є розповсюдження багатоядерних процесорів і, з тим, прагнення до більш паралельної та одночасної обробки.

Мапа / фільтр / скорочення стилю функціонального програмування дуже привітна до паралелізації, що дозволяє програмісту легко використовувати декілька ядер, не записуючи явного коду нарізки.

Як зазначає Джорджіо, функціональне програмування більше, ніж просто функції високого порядку. Функції, плюс карта / фільтр / зменшити схему програмування та незмінність є основою функціонального програмування. Разом ці речі створюють потужні інструменти паралельного та паралельного програмування. На щастя, багато мов вже підтримують певне поняття незмінності, і, навіть якщо вони цього не роблять, програмісти можуть трактувати речі як непорушні, дозволяючи бібліотекам і компілятору створювати та керувати асинхронними або паралельними операціями.

Додавання мови високого порядку до мови є важливим кроком для спрощення одночасного програмування.

Оновлення

Я додам ще кілька докладних прикладів, щоб вирішити проблеми, які зазначив Локі.

Розглянемо наступний код C #, який охоплює колекцію віджетів, створюючи новий список цін віджетів.

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

Для великої колекції віджетів або обчислювально інтенсивного методу CalculateWidgetPrice (Widget) цей цикл не використовує жодних наявних ядер. Щоб зробити розрахунок ціни на різних ядрах, програміст повинен чітко створити та керувати потоками, проходячи навколо роботи та збираючи результати разом.

Розгляньте рішення, як тільки в C # додано функції високого порядку:

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

Цикл foreach переміщений у метод Select, приховуючи деталі його реалізації. Все, що залишається програмісту, - це сказати Вибрати, яку функцію застосувати до кожного елемента. Це дозволить реалізації програми Select запустити обчислення паралельно, обробляючи всі проблеми синхронізації та управління потоками без участі програміста.

Але, звичайно, Select не робить це паралельно. Ось де відбувається незмінність. Реалізація Select не знає, що надана функція (CalculateWidgets вище) не має побічних ефектів. Функція могла змінити стан програми поза зоною вибору та її синхронізацією, порушивши все. Наприклад, у цьому випадку значення SalesTax можна змінити помилково. Чисті функціональні мови забезпечують незмінність, тому функція Select (map) може точно знати, що жоден стан не змінюється.

C # вирішує це, надаючи PLINQ як альтернативу Linq. Це виглядатиме так:

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

Що дозволяє повною мірою використовувати всі ядра вашої системи без явного управління цими ядрами.


Я вказую на прагнення до більш паралельної та паралельної обробки, про це йдеться у статті про історію Ерланг, про яку я посилаюсь у четвертому пункті. Але це дуже вдалий момент, і я, мабуть, повинен був би розширити його ще трохи. +1, тому що зараз мені не доведеться; P
yannis

Ти маєш рацію, я не придивився уважно. Я відредагував своє зауваження.
Бен

Ой, вам насправді цього не довелося робити, я не скаржився;)
yannis

4
Ніщо з того, що ви описали вище, не вимагає лямбда. Такий же функціонал досягається так само легко, як іменовані функції. Тут ви просто документуєте a causeі a perceived affectбез пояснення correlation. Останній рядок ІМО - про що йдеться; але ти на це не відповів. Чому це спрощує одночасне програмування.
Мартін Йорк

@Ben: Будьте уважні, що ваш приклад стосується функцій вищого порядку, які не потребують використання анонімних функцій. Ваша відповідь містить цікаві ідеї (на інше запитання), але зараз йде тема.
Джорджіо

9

Я погоджуюся з багатьма відповідями тут, але що цікаво, це те, що коли я дізнався про лямбда і стрибнув на них, це було не з жодної причини, про яку згадували інші.

У багатьох випадках функції лямбда просто покращують читабельність вашого коду. Перш ніж лямбдати, коли ви викликаєте метод, який приймає покажчик функції (або функцію, або делегат), вам довелося визначити тіло цієї функції десь в іншому місці, тому коли ви побудували "foreach", ваш читач повинен був би перейти на інший частина коду, щоб побачити, що саме ви планували робити з кожним елементом.

Якщо в тій частині функції, яка обробляє елементи, є лише кілька рядків, я б використав анонімну функцію, оскільки тепер, коли ви читаєте код, функціональність залишається незмінною, але читачеві не потрібно скачуватися вперед і назад, вся реалізація полягає в прямо там перед ним.

Багато функціональних методів програмування та паралелізації можна було б досягти без анонімних функцій; просто оголосіть звичайну та передайте посилання на це, коли вам потрібно. Але з лямбдами легкість написання коду та простота читання коду значно покращуються.


1
Дуже добре пояснення (+1). Про це програмісти Lisp знають з 1958 року ;-)
Джорджо

4
@Giorgio: Звичайно, але програмістам Lisp також довелося купувати спеціальні клавіатури із посиленими клавішами з відкритими та закритими дужками :)
DXM

@DXM: не клавіатури, вони отримують додатковий пристрій введення, який схожий на педалі для фортепіано для відкривання та закриття дужок ;-)
vartec

@DXM, vartec: Нещодавно робив якусь схему, і я вважаю круглі дужки в порядку. Деякі C ++-коди можуть бути набагато виразнішими (і я маю набагато більше досвіду роботи з C ++, ніж із Scheme). :-)
Джорджіо

9

Трохи долучившись до недавньої історії тут, я вважаю, що одним із факторів було додавання дженериків до Java та .NET. Це, природно, призводить до функцій < , > та інших сильно типізованих обчислювальних абстракцій (Завдання < >, Асинхрон < > тощо)

У світі .NET ми додали ці функції саме для підтримки FP. Це викликало каскадний набір мовних робіт, пов'язаних з функціональним програмуванням, особливо C # 3.0, LINQ, Rx і F #. Цей прогрес вплинув і на інші екосистеми, і досі триває у C #, F # та TypeScript.

Звичайно, це допомагає Haskell працювати і в MSR :)

Звичайно, було і багато інших впливів (звичайно, JS), і на ці кроки вплинули багато інших речей - але додавання генерики до цих мов допомогло зламати жорстку OO-ортодоксію кінця 90-х у великих частинах програмного світу та допомогло відкрити двері для ФП.

Дон Сайм

ps F # був 2003 р., а не 2005 р. - хоч ми б сказали, що до 2005 р. він не досягав 1,0. Ми також робили прототип Haskell.NET в 2001-02 роках.


Ласкаво просимо! Я використовував 2005 рік для F #, оскільки про цей рік повідомляється у статті Вікіпедії F # як рік першого стабільного випуску. Хочете, щоб я змінив його на 2003 рік?
янніс

4

Це не означало серйозної відповіді, але це питання нагадало мені крутий гумористичний пост Джеймса Ірі - "Коротка, неповна та здебільшого помилкова історія мов програмування", яка містить таку фразу:

"Лямбди відносяться до відносної невідомості, поки Java не зробить їх популярними, не маючи їх."


золота фраза :)
фісташка

4

З того, що я бачу, більшість відповідей зосереджуються на поясненні того, чому функціональне програмування в цілому зробило це поверненням і зробило це шлях до мейнстріму. Я відчував, що це не дуже відповідає на питання про анонімні функції, зокрема, і чому вони раптом набули такої популярності.

Те, що дійсно завоювало популярність, - це закриття . Оскільки в більшості випадків закриття є функціями викидання, переданими змінною, очевидно, має сенс використовувати анонімний синтаксис функції для них. Насправді в деяких мовах це єдиний спосіб створити закриття.

Чому закриття набули популярності? Оскільки вони корисні в програмуванні на основі подій, коли створюються функції зворотного виклику . Зараз це спосіб написання коду клієнта JavaScript (насправді це спосіб написання будь-якого коду GUI). Наразі це також спосіб написання високоефективного резервного коду, а також системного коду, оскільки код, записаний у парадигмі, керованої подіями, зазвичай є асинхронним і не блокуючим . Для бек-енду це стало популярним як рішення проблеми C10K .


Дякую за наголос, що це питання не стосується функціонального програмування (+1), оскільки (1) ідея блоку коду, який передається як аргумент, також використовується в нефункціональних мовах, таких як Smalltalk, та (2) мутації стану узяте з лексичного контексту закриття (як це можливо в багатьох лямбда-реалізаціях), безумовно, нефункціональне . І так, маючи закриття, крок до анонімного закриття короткий. Цікавим є той факт, що закриття також були давно відомі, а програмування на основі подій використовується (наскільки я знаю) з вісімдесятих років.
Джорджіо

Але, можливо, лише за останні кілька років стало зрозуміло, що закриття можна використовувати набагато частіше, ніж вважалося раніше.
Джорджіо

@ Giorgio: так, більшість понять, які зараз використовуються, існують дуже-дуже довго. Але вони не використовувались так, як зараз.
vartec

1

Я думаю, що причина полягає в збільшенні поширеності одночасного і розподіленого програмування, де ядро ​​об'єктно-орієнтованого програмування (інкапсуляція змінного стану об'єктами) вже не застосовується. У разі розподіленої системи, тому що це не загальні державні (і програмні абстракції цієї концепції не діряві) і в разі паралельної системи, так як правильно синхронізувати доступ до загального стану був доведена громіздким і схильні до помилок. Тобто одна з ключових переваг об'єктно-орієнтованого програмування вже не застосовується для багатьох програм, що робить об’єктно-орієнтовану парадигму набагато менш корисною, ніж раніше.

На відміну від цього, функціональна парадигма не використовує стан, що змінюється. Будь-який досвід, який ми набули з функціональними парадигмами та зразком, може бути негайно перенесений на паралельні та розподілені обчислення. І замість того, щоб винаходити колесо, тепер галузь запозичує ці структури та мовні особливості для задоволення її потреб.


4
Анонімні функції в деяких мовах основного потоку (наприклад, C ++ 11) дозволяють змінювати стан (вони можуть навіть захоплювати змінні з визначаючого середовища та змінювати їх під час їх виконання). Тож я думаю, що говорити про функціональну парадигму взагалі та про незмінність зокрема трохи не виходить за рамки питання, яке задається.
Джорджіо

Щойно прочитавши деякі примітки до функцій Java 8, однією з головних цілей лямбда проекту є підтримка паралельності. І ЦЕ негайно переносить нас до скупчуваності мінливості, в яку збираються зіткнутися всі ці чудові яваби. Як тільки Java отримує лямбдаси (якщо припустити, що це дійсно є в остаточному випуску версії 8), то їм потрібно якось вирішити непорушну проблему за замовчуванням (це на зразок руйнує мову, думаючи в Lisp - вільні функції побічних ефектів - замість цього в COBOL - удари по DIVISION DATA / COPYBOOK)
Roboprog

Добре сказано. Відхід від стану, що змінюється, полегшує паралельність, а такі технології, як каскалог та іскри, легко поширюють функціональне програмування на кластері комп'ютерів. Див. Glennengstrand.info/analytics/distributed/functional/… для більш детальної інформації про те, як і чому.
Гленн

1

Якщо я можу додати 0,02 євро, хоча я погоджуюся з важливістю введення JavaScript у цю концепцію, я думаю, що більше, ніж одночасне програмування, я б звинувачував сучасну моду асинхронного програмування. Проводячи асинхронні дзвінки (необхідні на веб-сторінках), прості анонімні функції настільки очевидно корисні, що кожен веб-програміст (тобто кожен програміст) повинен був дуже добре ознайомитися з концепцією.


1

Ще один справді старий приклад чогось схожого на анонімні функції / лямбдаси - це заклик по імені в Algol 60. Однак зауважте, що call-by-name ближче до передачі макросів як параметрів, ніж передача справжніх функцій, і це більш крихке / складніше зрозуміти як результат.


0

Тут походження, наскільки мені відомо.

  • 2005 р.: Нещодавно Javascript повернув програмування вищого порядку з лямбдами в основний потік. Зокрема, такі бібліотеки, як underscore.js та jquery . Однією з перших з цих бібліотек був prototype.js, який передував jquery приблизно року. Прототип заснований на численному модулі Ruby, який веде нас до ...
  • 1996: Модуль Ruby's Enumerable дуже очевидно взяв натхнення в рамках колекції Smalltalk. Як згадував Матц у багатьох інтерв'ю, що призводить нас до ...
  • 1980: Smalltalk використовує багато програмувань вищого порядку та пропонує API колекції, який широко використовує програмування вищого порядку (наприклад, клас Iterable GNU Smalltalk ). У ідіоматичному коді Smalltalk ви не знайдете циклів, а лише переліки високого порядку. На жаль, коли Java, коли колекція Smalltalk колекції була перенесена на Java в 1998 році, перерахування вищого порядку не залишилося. Ось як програмування вищого порядку було виведено з мейнстріму на наступні десять років! Smalltalk має багато родів, але актуальним питанням ОП є LISP, який призводить нас до ...
  • 1958 рік: LISP, очевидно, має в своїй основі програмування вищого порядку.

Звісно, ​​звичайно, це весь рід МЛ. ML, SML, OCaml, Haskell, F #. То
мусив

-1

Анонімні функції хороші тим, що називати речі важко, і якщо ви використовуєте функцію лише в одному місці, її імені не потрібно.

Функції лямбда лише нещодавно стали мейнстрімом, оскільки донедавна більшість мов не підтримували закриття.

Я б припустив, що Javascript підштовхнув цей мейнстрім. Це універсальна мова, яка не має можливості виразити паралелізм, а анонімні функції полегшують використання моделей зворотного виклику. Додатково сприяли популярні мови, такі як Ruby та Haskell.


1
"Функції лямбда лише нещодавно стали мейнстрімом, оскільки донедавна більшість мов не підтримували закриття.": Це міркування для мене звучить трохи кругообіжно. Можна одразу запитати "Що спричинило популярність закриття в сучасних мовах програмування".
Джорджіо

Я знаю, що Python не найкраще реалізує лямбда. Але з точки зору популярності це, мабуть, сприяло більше, ніж Haskell.
Мухаммед Алькарурі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.