Что вызвало популярность лямбда-функций в современных основных языках программирования?


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, Дженерики все существовали в Eiffel в 1985 году ... и намного лучше, ИМХО.)
Йорг Миттаг

31
Еще до того, как вышла Java 1.0, хотя она еще находилась на ранней стадии проектирования, почти все указали на то, что Java нуждается в лямбдах. Среди дизайнеров, которые работали на Java, Гай Стил (сторонник Lisp, со-дизайнер Scheme, соавтор Common Lisp, дизайнер Fortress), Джеймс Гослинг (написал первый интерпретатор Emacs Lisp для ПК), Gilad Bracha (Smalltalk сторонник, со-дизайнер Animorphic Smalltalk, дизайнер Newspeak), Фил Уодлер (со-дизайнер Haskell), Мартин Одерский (дизайнер Scala). То, как Java оказалась без лямбд, на самом деле вне меня.
Jörg W Mittag

8
«Крошечный бит» часто означает 50% функции, 50% шума.
Кевин Клайн

Ответы:


86

Конечно, есть заметная тенденция к функциональному программированию или, по крайней мере, к некоторым его аспектам. Некоторые из популярных языков, которые в какой-то момент приняли анонимные функции: C ++ ( C ++ 11 ), PHP ( PHP 5.3.0 ), C # ( C # v2.0 ), Delphi (с 2009 года), Objective C ( блоки ), в то время как Java 8 принесет поддержку лямбда-языку . И есть популярные языки, которые, как правило, не считаются функциональными, но поддерживают анонимные функции с самого начала или, по крайней мере, на раннем этапе, ярким примером является JavaScript.

Как и во всех тенденциях, попытка найти единственное событие, вызвавшее их, вероятно, является пустой тратой времени, обычно это комбинация факторов, большинство из которых не поддаются количественной оценке. Практический Common 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» , в котором он опровергает (тогда) тенденцию университетов отдавать предпочтение Java по сравнению с другими, возможно, более сложными в изучении языками. Хотя сообщение в блоге имеет мало общего с функциональным программированием, оно определяет ключевую проблему:

В этом и заключается дискуссия. Годы ленивых ленивых старшекурсников CS, таких как я, в сочетании с жалобами индустрии на то, что немногие выпускники CS заканчивают американские университеты, пошли на спад, и в последнее десятилетие большое количество совершенно других хороших школ перешли на 100% Java. Это хип, рекрутерам, которые используют «grep» для оценки резюме, похоже, это нравится, и, что лучше всего, нет ничего достаточно сложного в Java, чтобы действительно отсеять программистов без той части мозга, которая выполняет указатели или рекурсию, поэтому уровень отсева ниже, и на факультетах информатики учится больше студентов, и у них больше бюджетов, и все хорошо.

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

В общем, это хорошая вещь. Несколько многоцелевых языков принимают концепции парадигмы, которые раньше могли показаться загадочными для большинства их пользователей, и разрыв между основными парадигмами сокращается.

Смежные вопросы:

Дальнейшее чтение:


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


2
@YannisRizos: Perl's имел анонимные функции с момента первого выпуска 5 (1994), но они не были полностью «правильными» до 5.004 (1997).
Blrfl

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

Я думаю, что, пожалуй, главным «событием», вызвавшим популярность функциональных языков, является Интернет. В частности, переход от настольных программ к серверной части. Это дает разработчику свободу выбора любого языка программирования. Пол Грэм и Лисп в 90-х годах являются ярким примером.
Гилад Наор

32

Мне кажется интересным, насколько популярность функционального программирования сопровождается ростом и распространением Javascript. Javascript имеет много радикальных особенностей в спектре функционального программирования, которые на момент его создания (1995) не были очень популярны среди основных языков программирования (C ++ / Java). Он был внедрен внезапно в мейнстрим как единственный клиентский язык веб-программирования. Внезапно многим программистам просто нужно было знать Javascript, и поэтому вам нужно было кое-что узнать о функциональных возможностях языка программирования.

Интересно, насколько популярными были бы функциональные языки / функции, если бы не внезапный рост Javascript?


5
Javascript, безусловно, является важным языком, но я не уверен, что введение Javascript может объяснить популярность функционального программирования само по себе: в последние годы появилось много других языков функционального программирования, как проиллюстрировал Яннис в своем ответе ,
Джорджио

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

1
Популярность динамических языков в целом намекается на одно из объяснений популярности Haskell: book.realworldhaskell.org/read/…
yannis

Кроме того, основное внимание в этом вопросе уделяется не популярности FP в целом, а позднему введению анонимных функций в не функциональных языках общего назначения. Даже если широкая публика (большинство программистов) не знала их, языковые дизайнеры знали их очень хорошо. Должно быть, в начале была причина оставить их. Возможно, они считались не интуитивными для разработчиков начала 90-х годов.
Джорджио

@giorgio - их гораздо сложнее реализовать, чем функторы в стиле Java. Объедините это с отсутствием знаний / принятия, и это довольно четкий выбор дизайна.
Теластин

27

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

Оттуда это относительно короткий шаг к анонимным функциям. Поскольку JavaScript не закрывается this, он также настоятельно рекомендует вам также узнать о замыканиях. И тогда вы великолепны: вы понимаете анонимные функции первого класса, которые закрывают окружающие лексические области.

Как только вы освоитесь с этим, вы захотите использовать его на каждом используемом вами языке.


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

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

17

Это, конечно, не единственный фактор, но я укажу на популярность Ruby. Не сказать, что это важнее, чем любой из шести ответов на доске, но я думаю, что многие вещи произошли одновременно и что полезно перечислить их все.

Ruby не является функциональным языком, и его лямбда-выражения, модули и блоки кажутся неуклюжими, когда вы используете что-то вроде ML, но на самом деле он популяризировал понятие отображения и превращает его в поколение молодых программистов, бегущих из Java и PHP для хипперов. пастбища. Лямбды на нескольких языках кажутся защитными движениями больше всего на свете («Держись! У нас тоже есть!)

Но синтаксис блока и его интеграция с .each, .map, .reduce и т. Д. Привели к появлению идеи анонимной функции, даже если это действительно синтаксическая конструкция, которая ведет себя как сопрограмма. А простое преобразование в процесс через & делает его шлюзом для функционального программирования.

Я утверждаю, что программисты Ruby on Rails, пишущие JavaScript, уже были заняты выполнением задач в легком функциональном стиле. Соедините это с блоггингом программистов, изобретением Reddit, хакерских News и Stack Overflow в одно и то же время, и идеи распространяются по Интернету быстрее, чем во времена новостных групп.

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


2
+1 за хороший ответ и (если бы я мог, потому что у меня только одно возражение) +1 за указание на то, что «лямбды на нескольких языках кажутся защитными ходами больше, чем что-либо еще» («Держись! У нас тоже есть такие !!) ". Я думаю, что это тоже фактор. Для некоторых языков лямбды - это полезная функция, которая, хотя и добавляет очень мало выразительной силы языку в целом, придает языку некоторую популярность ( Похоже, что многие программисты считают, что поддержка анонимных функций эквивалентна полной поддержке функционального программирования.
Джорджио

2
Я действительно думаю, что это причина того, что в большинстве языков в последние годы реализован блочный синтаксис. Но единственный способ убедиться в этом - спросить разработчиков языка, каковы были их мотивы. Мы можем только спекулировать имо.
SpoBo

для меня Ruby - это язык, который первым сделал блоки роковыми и очень привлекательными, так что +1. Haskell, возможно, имел эффект также.
rogerdpack

13

Как указал Яннис , существует ряд факторов, которые повлияли на принятие функций высокого порядка в языках, которые ранее не использовались. Одним из важных моментов, которые он лишь слегка коснулся, является распространение многоядерных процессоров и, следовательно, стремление к более параллельной и параллельной обработке.

Стиль функционального программирования map / filter / Reduce очень удобен для распараллеливания, что позволяет программисту легко использовать несколько ядер без написания какого-либо явного кода многопоточности.

Как отмечает Джорджио, функциональное программирование - это нечто большее, чем просто функции высокого порядка. Функции, а также шаблон программирования карта / фильтр / сокращение и неизменность являются ядром функционального программирования. Вместе эти вещи создают мощные инструменты параллельного и параллельного программирования. К счастью, многие языки уже поддерживают некоторое понятие неизменности, и, даже если они этого не делают, программисты могут воспринимать вещи как неизменяемые, позволяя библиотекам и компилятору создавать и управлять асинхронными или параллельными операциями.

Добавление функций высокого порядка к языку является важным шагом для упрощения параллельного программирования.

Обновить

Я добавлю пару более подробных примеров, чтобы решить проблемы, отмеченные Локи.

Рассмотрим следующий код 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 выполнять вычисления в parellel, обрабатывая все проблемы синхронизации и управления потоками без участия программиста.

Но, конечно же, Select не работает параллельно. Вот тут-то и возникает неизменность. Реализация Select не знает, что предоставленная функция (CalculateWidgets выше) не имеет побочных эффектов. Функция может изменить состояние программы вне представления Select и его синхронизации, нарушая все. Например, в этом случае значение salesTax может быть изменено по ошибке. Чистые функциональные языки обеспечивают неизменность, поэтому функция Select (map) может точно знать, что состояние не меняется.

C # решает эту проблему, предоставляя PLINQ в качестве альтернативы Linq. Это будет выглядеть так:

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

Который в полной мере использует все ядра вашей системы без явного управления этими ядрами.


Я указываю на желание более параллельной и параллельной обработки, это обсуждается в статье ACM «История Эрланга», на которую я ссылаюсь в четвертом абзаце. Но это очень хороший момент, и мне следовало бы остановиться на нем немного подробнее. +1, потому что теперь мне не нужно; P
Яннис

Ты прав, я не выглядел достаточно внимательно. Я отредактировал свое замечание.
Бен

О, ты не должен был этого делать, я не жаловался;)
Яннис

4
Ничто из того, что вы описываете выше, не требует лямбд. Та же функциональность достигается так же легко с помощью именованных функций. Здесь вы просто документируете causeи perceived affectне объясняете correlation. Последняя строчка ИМО - о чем вопрос; но ты не ответил на это. Почему это упрощает параллельное программирование?
Мартин Йорк

@Ben: будьте осторожны, если ваш пример касается функций высшего порядка, которым не нужны анонимные функции. Ваш ответ содержит интересные идеи (для другого вопроса), но сейчас уходит с темы.
Джорджио

9

Я согласен со многими ответами здесь, но что интересно, когда я узнал о лямбдах и запрыгнул на них, это было не по какой-либо из причин, упомянутых другими.

Во многих случаях лямбда-функции просто улучшают читабельность вашего кода. Перед лямбдами, когда вы вызываете метод, который принимает указатель на функцию (или функцию, или делегат), вы должны были определить тело этой функции где-то еще, поэтому, когда у вас была конструкция «foreach», ваш читатель должен был перейти к другому часть кода, чтобы увидеть, что именно вы планируете делать с каждым элементом.

Если тело функции, которая обрабатывает элементы, состоит всего из нескольких строк, я бы использовал анонимную функцию, потому что теперь, когда вы читаете код, функциональность остается неизменной, но читателю не нужно переходить назад и вперед, вся реализация прямо перед ним.

Многие из методов функционального программирования и распараллеливания могут быть достигнуты без анонимных функций; просто объявите обычный и передайте ссылку на это всякий раз, когда вам нужно. Но с лямбдами значительно улучшается простота написания кода и простота чтения кода.


1
Очень хорошее объяснение (+1). Программисты на Лиспе знают об этом с 1958 года. ;-)
Джорджио

4
@ Джорджио: Конечно, но программисты на lisp также должны были покупать специальные клавиатуры с усиленными клавишами открывания / закрывания скобок :)
DXM

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

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

9

Я немного поучаствовал в недавней истории и считаю, что одним из факторов было добавление дженериков в Java и .NET. Это естественно приводит к Func < , > и другим строго типизированным вычислительным абстракциям (Task < >, Async < > и т. Д.)

В мире .NET мы добавили эти функции именно для поддержки FP. Это вызвало каскадный набор языковых работ, связанных с функциональным программированием, особенно C # 3.0, LINQ, Rx и F #. Это развитие повлияло и на другие экосистемы и продолжается до сих пор в C #, F # и TypeScript.

Конечно, это помогает работать на Haskell в MSR :)

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

Дон Сайм

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


Добро пожаловать! Я использовал 2005 для F #, поскольку это год, о котором сообщалось в статье F # в Википедии как год первого стабильного выпуска. Вы хотите, чтобы я изменил его на 2003?
Яннис

4

Это не должно быть серьезным ответом, но этот вопрос напомнил мне о забавном юмористическом посте Джеймса Ири - «Краткая, неполная и в основном неправильная история языков программирования», которая включает следующую фразу:

«Лямбды относят к относительной безвестности, пока Java не делает их популярными, не имея их».


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

4

Из того, что я вижу, большинство ответов сконцентрировано на объяснении того, почему функциональное программирование в целом вернулось и вошло в мейнстрим. Я чувствовал, что это, однако, на самом деле не отвечает на вопрос об анонимных функциях, в частности, и почему они внезапно стали настолько популярными.

Что действительно завоевало популярность, так это замыкания . Поскольку в большинстве случаев замыкания являются одноразовыми функциями, передаваемыми переменными, очевидно, что для них имеет смысл использовать синтаксис анонимных функций. И на самом деле в некоторых языках это единственный способ создать замыкание.

Почему затворы приобрели популярность? Потому что они полезны в программировании, управляемом событиями, при создании функций обратного вызова . В настоящее время это способ написания клиентского кода JavaScript (фактически это способ написания любого кода GUI). В настоящее время это также способ написания высокоэффективного внутреннего кода, а также системного кода, поскольку код, написанный в парадигме, управляемой событиями, обычно асинхронный и неблокирующий . Для серверной части это стало популярным решением проблемы C10K .


Спасибо за то, что подчеркнули, что этот вопрос не о функциональном программировании (+1), потому что (1) идея блока кода, который передается в качестве аргумента, также используется в нефункциональных языках, таких как Smalltalk, и (2) изменяющееся состояние захваченный из лексического контекста замыкания (как это возможно во многих реализациях лямбды) определенно не функционален . И да, имея замыкания, шаг к анонимным замыканиям короткий. Интересно, что замыкания также давно известны, а программирование на основе событий используется (насколько я знаю) с восьмидесятых годов.
Джорджио

Но, возможно, только в последние несколько лет стало ясно, что затворы могут использоваться гораздо чаще, чем считалось ранее.
Джорджио

@ Джорджио: да, большинство концепций, которые используются в настоящее время, существуют очень и очень долго. И все же они не были использованы так, как они используются сейчас.
vartec

1

Я думаю, что причина заключается в растущей распространенности параллельного и распределенного программирования, где ядро ​​объектно-ориентированного программирования (инкапсуляция изменяющегося состояния с объектами) больше не применяется. В случае распределенной системы, потому что это не общие государственные (и программные абстракции этой концепции не дырявые) и в случае параллельной системы, так как правильно синхронизировать доступ к общему состоянию был доказана громоздким и подвержены ошибкам. То есть одно из ключевых преимуществ объектно-ориентированного программирования больше не применимо ко многим программам, что делает объектно-ориентированную парадигму гораздо менее полезной, чем раньше.

Напротив, функциональная парадигма не использует изменяемое состояние. Таким образом, любой опыт, полученный нами в отношении функциональных парадигм и паттернов, более быстро переносится на параллельные и распределенные вычисления. И вместо того, чтобы изобретать велосипед, индустрия теперь заимствует эти модели и языковые возможности для удовлетворения своих потребностей.


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

Только что прочитав некоторые примечания к функциям Java 8, одной из основных целей лямбда-проекта является поддержка параллелизма. И это немедленно приводит нас к кластерной бомбе изменчивости, с которой столкнутся все эти замечательные javabeans. Как только Java получает лямбды (при условии, что это действительно происходит в окончательном выпуске версии 8), им необходимо каким-то образом решить проблему неизменности по умолчанию (это как бы разрушает язык, думая на Лиспе - функции, свободные от побочных эффектов - вместо этого из в COBOL - удар по разделу данных / COPYBOOK)
Roboprog

Хорошо сказано. Переход от изменяемого состояния облегчает параллелизм, а технологии, такие как cascalog и spark, легко распределяют функциональное программирование по кластеру компьютеров. См. Glennengstrand.info/analytics/distributed/functional/… для более подробной информации о том, как и почему.
Гленн

1

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


1

Другой действительно старый пример чего-то похожего на анонимные функции / лямбды - это вызов по имени в Algol 60. Однако обратите внимание, что вызов по имени ближе к передаче макросов в качестве параметров, чем к передаче истинных функций, и он более хрупок / сложнее понять в результате.


0

Здесь родословная насколько я знаю.

  • 2005: Javascript совсем недавно вернул программирование высшего порядка с лямбдами обратно в мейнстрим. В частности, такие библиотеки, как underscore.js и jquery . Одной из первых из этих библиотек был prototype.js, который предшествовал jquery примерно на год. Прототип основан на Enumerable модуле Ruby, который приводит нас к…
  • 1996: Enumerable модуль Ruby, очевидно, черпал вдохновение из коллекционной среды Smalltalk. Как было упомянуто Матцем во многих интервью, что приводит нас к ...
  • 1980: Smalltalk использует множество программ более высокого порядка и предоставляет API-интерфейс коллекции, который активно использует программирование более высокого порядка (например, класс Iterable GNU Smalltalk ). В идиоматическом коде Smalltalk вы не найдете ни одного цикла for, а только перечисления высокого порядка. К сожалению, когда Java, когда среда сбора данных Smalltalk была портирована на Java в 1998 году, перечисления более высокого порядка были исключены. Именно так программирование высшего порядка было выведено из основного потока на следующие десять лет! Smalltalk имеет много предков, но к вопросу OP уместен LISP, что приводит нас к ...
  • 1958: LISP, очевидно, имеет ядро ​​программирования высшего порядка.

Amiss, конечно, является целой родословной ML. ML, SML, OCaml, Haskell, F #. Это должно что-то
значить

-1

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

Лямбда-функции только недавно стали мейнстримом, потому что до недавнего времени большинство языков не поддерживали замыкания.

Я бы предположил, что Javascript подтолкнул этот мейнстрим. Это универсальный язык, который не может выразить параллелизм, а анонимные функции упрощают использование моделей обратного вызова. Кроме того, такие популярные языки как Ruby и Haskell внесли свой вклад.


1
«Лямбда-функции только недавно стали мейнстримом, потому что до недавнего времени большинство языков не поддерживали замыкания». Это рассуждение звучит для меня несколько циркулярно: мейнстрим означает, что большинство языков поддерживают его. Можно сразу спросить: «Что вызвало популярность замыканий в современных языках программирования».
Джорджио

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