Функциональное программирование на подъеме?

42

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

И это имело место в течение достаточно долгого времени. Функциональное программирование просто не стало таким популярным, как другие модели (т.е. объектно-ориентированное программирование).

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

Я с большим интересом вижу тот факт, что, несмотря на отсутствие значительного признания в сообществе, все больше и больше языков такого рода продолжают появляться. Clojure (2007), Scala (2003), F # (2002) - это всего лишь три примера последнего десятилетия.

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

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

Я хочу спросить:

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

Любые рекомендации для дальнейших исследований будут приветствоваться.

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

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

Заранее спасибо!

edalorzo
источник
4
Это Эрланг, а не Эрланг (я бы отредактировал ваше сообщение, но система не позволяет редактировать в одну букву).
Quant_Dev
6
Стоит сказать - нет жесткой границы между функциональными и императивными языками. Языки семейства ML не свободны от побочных эффектов и поддерживают императивные операторы и структуры и изменяемые переменные. Некоторые императивные языки - вне головы Python и Javascript - имеют важные функции, взятые из функционального программирования. Лично я надеюсь увидеть более функциональные идеи в основном использовании - особенно сопоставление с образцом.
Steve314
1
Наличие нескольких функций, общих для функциональных языков, не обязательно делает язык «функциональным». Функциональное программирование - это не только способ мышления и проектирования программ, но и специфические особенности языка.
Мипади
2
@mipadi - и поэтому вы можете применять функциональную философию на любом языке в той степени, в которой это позволяют доступные инструменты. Вы можете написать код функционального стиля в Python (в определенных пределах), и в этом смысле Python является функциональным языком. И вы можете написать код императивного стиля в ML, и в этом смысле ML - императивный язык. Это не совсем то же самое, что «плохие программисты могут писать на Фортране на любом языке», хотя, очевидно, это простая ловушка, в которую можно попасть, если вы неправильно истолковали мою точку зрения.
Steve314
1
@mipadi - но если бы в императивном языке были все нормальные функциональные конструкции, вы могли бы делать с ним все, что могли на функциональном языке - пробел был бы закрыт, и вопрос был бы «каков наилучший способ сделать это», а не «Что такое функциональный / императивный путь». Семья ML уже преодолела этот пробел, но поскольку он называется функциональным, мы думаем о его стиле как о функциональном, а не просто о хорошем стиле.
Steve314

Ответы:

24

В каких сценариях мне следует рассмотреть функциональные языки программирования, более подходящие для выполнения определенной задачи? Помимо недавно популярной многоядерной проблемы параллельного программирования.

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

По сути, «проблема с электронными таблицами». У вас есть некоторые исходные данные и ряд построчных вычислений, которые можно применить к этим данным.

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

Одна общая вещь, которую мы делаем, - это объединение трех чудовищных наборов данных. Подобно соединению SQL, но не так обобщенно. Далее следует ряд расчетов по полученным данным. Это все просто функциональные преобразования.

Приложение написано на Python, но написано в функциональном стиле с использованием функций генератора и неизменных именованных кортежей. Это композиция функций нижнего уровня.

Вот конкретный пример функциональной композиции.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

Это один из способов, которым функциональное программирование влияет на такие языки, как Python.

Иногда такие вещи записываются так:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

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

Неизменяемые объекты - самое сложное препятствие.

Часто вам приходится вычислять значения, которые создают новые объекты, вместо обновления существующих. Идея, что это изменчивый атрибут объекта, - это сложная умственная привычка, которую можно сломать.

Производное свойство или функция-метод является лучшим подходом. Объекты с состоянием - это сложная привычка.

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

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

Я прочитал о Хаскеле, чтобы понять, чего не хватает Python.

С. Лотт
источник
5
@edalorzo: Python не печатается слабо. Это очень, очень сильно напечатано. Там нет оператора приведения, поэтому он более строго типизирован, чем Java или C ++.
С.Лотт
5
@ S.Lott - разве статическая проверка типов не помогает в инструментах рефакторинга IDE и материалах типа intellisense? Если у вас есть фоновая компиляция и вы статически проверяете типы, не значит ли это, что вы можете автоматизировать больше в своих инструментах? Я согласен, что если в ваших тестах будет 100% покрытие кода, оно его поймает. Вы должны понимать, что, вероятно, менее 50% производственного кода на предприятии действительно имеют покрытие модульных тестов, верно? :) Существует реальный мир, в котором мы должны жить.
Скотт Уитлок
8
@ S.Lott "Статическая проверка типов не так уж и полезна. Не имеет значения, есть ли статическая проверка компилятором или проверка во время выполнения. Вы по-прежнему пишете тот же объем кода и такое же количество модульных тестов. " Нет, нет Весь смысл статической проверки типов заключается в том, что она выявляет ошибки и, следовательно, значительно сокращает объем необходимого тестирования.
Джон Харроп
3
@ S.Lott "Python не напечатан слабо. Он очень, очень сильно напечатан." Python неявно преобразует числовые типы в слабо типизированные.
Джон Харроп
3
@ Steve314 «В конце концов, статическая проверка типов выявляет некоторые ошибки, которые соответствуют некоторым основным правилам. В принципе, модульное тестирование может отлавливать все эти ошибки и многое другое». Нет. Статическая проверка подтверждает правильность аспекта программы. Модульное тестирование стремится опровергнуть правильность, но не доказывает правильность чего-либо. Модульное тестирование не является заменой статической проверки типа или каких-либо других доказательств.
Джон Харроп
23

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

неизменность

Теперь, когда я знаком с этим, каждый раз, когда мне удается вернуть неизменный результат, я всегда пытаюсь это сделать, даже в объектно-ориентированной программе. Про программу легче рассуждать, если у вас есть данные типа значения. Обычно вам нужна изменчивость для таких вещей, как графический интерфейс и узкие места производительности. Мои объекты (использующие NHibernate) также являются изменяемыми (что имеет смысл, поскольку они моделируют данные, хранящиеся в базе данных).

Функции как типы первого класса

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

Возможность составлять функции (например, превращение Action<T>в просто Action) также весьма полезна в некоторых сценариях.

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

Монады

Правда, это мое слабое место, но я понимаю, что вычислительные рабочие процессы в F #, такие как asyncрабочий процесс, являются монадой. Это тонкий, но очень мощный конструкт. Это так же мощно, как yieldключевое слово, используемое для создания IEnumerableклассов в C #. По сути, он строит для вас конечный автомат, но ваша логика выглядит линейной.

Ленивая оценка и рекурсия

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

S-выражение

Думаю, я не уверен, куда это поместить, но способность обрабатывать не скомпилированный код как объект (и проверять / изменять его), такой как Lisp S-Expressions или LINQ Expressions, в некотором смысле самый мощный инструмент функционального программирования. Большинство новых .NET «свободно» интерфейсов и DSL используют комбинацию лямбда-синтаксиса и выражений LINQ для создания очень лаконичных API. Не говоря уже о Linq2Sql / Linq2Nhibernate, где ваш код C # «магическим образом» выполняется как SQL, а не как код C #.

Это был длинный ответ на первую часть вашего вопроса ... сейчас ...

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

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

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

Если вы знакомы с .NET, я настоятельно рекомендую F #. С другой стороны, если вы более знакомы с JVM, всегда есть Clojure . Если вы более академичны, чем практичны, я бы выбрал Common Lisp или Scheme. Если вы уже знаете Python, я думаю, что там уже есть множество функциональных конструкций.

Скотт Уитлок
источник
@ Scott Спасибо за ваше подробное объяснение. Я предполагаю, что то, что вы описываете как самую большую ловушку, было бы исключено из уравнения с использованием чисто функционального языка программирования, такого как Haskell. Вот почему я начал с этого, потому что я всю жизнь был императивным программистом, и я не хочу сниматься с нечистого языка программирования и рисковать, не выучив хороший путь. Если вы не возражаете, я задаю другой вопрос: две вещи, которые меня беспокоят, - это инструменты и библиотеки. Насколько хороша интеграция F # с другими инструментами и библиотеками .Net?
edalorzo
Я не понимаю, почему вы смешиваете код во время выполнения и генерации и проверки кода во время выполнения с помощью функционального программирования. Два не имеют никакого отношения друг к другу. Возможности метапрограммирования, которые вы описываете, могут быть добавлены практически к любому языку, функциональному или нет. Я думаю, что lisp начал код как тренд данных, но теперь он доступен на ruby ​​и других нефункциональных языках.
davidk01
1
Интеграция @edalorzo - F # с .NET очень хорошая, только с одним небольшим исключением: нет дизайнера графического интерфейса. Вы можете обойти это, создав свой графический интерфейс в сборке C # и ссылаясь на него из F #, или создавая GUI внутри F # только в коде (не используя конструктор).
Скотт Уитлок
@ davidk01 - хороший вопрос о метапрограммировании. Я просто обнаружил, что лямбда-синтаксис и метапрограммирование строятся друг на друге, но вы правы, они могут быть разделены. Просто кажется, что у вас больше шансов получить метапрограммирование с функциональным языком.
Скотт Уитлок
1
@ Скотт: Я думаю, что во многих отношениях это проще - например, когда вам не нужно беспокоиться о побочных эффектах, вы можете изменить часть кода на лету с гораздо большей уверенностью - это ограничивает то, что вы должны изменить.
Майкл К
15

И это имело место в течение достаточно долгого времени. Функциональное программирование просто не стало таким популярным, как другие модели (т.е. объектно-ориентированное программирование).

Это верно, если вы считаете программы, разработанные профессиональными программистами (или, по крайней мере, люди видят себя таковыми). Если вы расширите свою сеть более широко, включив в нее программы, разработанные людьми, которые не считают себя таковыми, FP (или, по крайней мере, программирование в функциональном стиле) будет очень близок к ОО (Excel, Mathematica, Matlab, R ... даже «современный» JavaScript ).

В каких сценариях мне следует рассмотреть функциональные языки программирования, более подходящие для выполнения определенной задачи? Помимо недавно популярной многоядерной проблемы параллельного программирования.

Мое личное мнение таково, что многоядерный процессор не является отличительной чертой FP (по крайней мере, до тех пор, пока компиляторы Haskell, Scala, Clojure, F # не решат проблему локальности кэша). Функция убийца map, filter, foldи друзья , которые позволяют более лаконичное выражение большой группы алгоритмов. Это усугубляется тем, что языки FP имеют более лаконичный синтаксис, чем большинство популярных аналогов ОО.

Кроме того, FP, находящийся ближе к реляционной модели, уменьшает несоответствие импеданса с RDBMS ... что, опять же, по крайней мере для непрограммистов, очень приятно.

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

Если я решил перейти на функциональный язык программирования, который, по вашему мнению, является самой большой ошибкой, с которой я столкнусь?

  • отсутствие поддержки инструмента (F # и некоторые Lisps - исключение, Scala - в пути)
  • труднее выжать последнюю часть производительности из вашего оборудования
  • сообщества часто сосредотачиваются на вопросах, отличных от тех, с которыми сталкивается большая группа коммерческих проектов разработки программного обеспечения
  • очень немногие разработчики имеют опыт использования FP в промышленных условиях, и если вы сможете их найти, вам, вероятно, придется конкурировать с зарплатой и выгодами, которые может предложить финансовая индустрия.
  • функциональный стиль программирования сложнее отлаживать; т.е. наблюдение между результатами в длинной цепочке составных функций обычно невозможно в большинстве (всех?) отладчиков

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

  • Сколько ваших проблем может быть решено уже существующими библиотеками / фреймворками на какой платформе (например, JVM или .Net), сколько новых? Существуют ли языковые конструкции, способные выражать эти проблемы напрямую?

  • Насколько низкоуровневый контроль необходим для пространственно-временной производительности вашего приложения?

  • Насколько строги ваши требования к «правильности»?

  • Можете ли вы позволить себе переобучить разработчиков и / или конкурировать с преимуществами, предлагаемыми некоторыми высокодоходными нишами в разработке ПО?

Александр Баттисти
источник
+1 @ Александр, это, безусловно, один из лучших ответов в этой дискуссии. Вы привели в дискуссию новое измерение аргументов, представив человеческий фактор, сложность поиска квалифицированных разработчиков и их мотивации. Я полностью согласен с вашим видением убийственных свойств FP-языков, потому что с каждым днем ​​я вижу, что все более и более императивные языки также принимают их. Но ваш пост открыл мне глаза, чтобы понять, что есть много вещей, которые я до сих пор не знаю о FP. Наконец, ваша точка зрения на основе существующей платформы, такой как .Net или Java, безусловно, очень правильная и абсолютно разумная.
edalorzo
9

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

Предполагая, что вы являетесь разработчиком C ++ / C # / Java в промышленности ...

Будьте готовы к сварливым сверстникам, которые не хотят ничего изучать. Будьте готовы к заостренным боссам, навязывающим неправильный выбор языка «потому что когда-то они были кодером». Будьте готовы к содержательным академикам на форумах, покровительствующих вам о моноидах. Будьте готовы к бесконечным языковым войнам, потому что у Scala даже нет устранения хвостовых вызовов, а Clojure действительно требует ножных педалей для всех скобок, и не заводите меня на Erlang.

Если вы веб-программист, то самой большой ошибкой, вероятно, будут ваши волосы.

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

Я бы начал с платформы:

  • OCaml хорош в Linux и ужасен в Windows.
  • F # отлично подходит для Windows и ужасно для Linux.
  • Scala и Clojure отлично подходят для JVM.
Джон Харроп
источник
1
Когда я читаю «Будьте готовы к сварливым сверстникам, которые не хотят ничего учить». Я хотел кричать: "Так верно! Так чертовски верно!" но это действительно грустно
Зельфир Кальцталь
3

Для одного (по общему мнению) предвзятого взгляда на этот вопрос вы можете обратиться к блогу Боба Харпера « Existential Type» . Карнеги-Меллон недавно переделал свой учебный план по CS, чтобы сначала преподавать функциональное программирование, а другие парадигмы преподаются только после того, как будет заложено прочное основание в функциональном программировании, и Харпер дает обильный удар, когда новый учебный план внедряется на практике. ,

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

jimwise
источник
1
+1 Эта статья, безусловно, очень интересная, и теперь я буду держать ее в избранном. Я думаю, что сначала обучение FP - это, конечно, хороший подход, потому что действительно трудно избавиться от императивного мышления, если вы делаете это иначе, и, прежде всего, если вы не используете чисто функциональный язык программирования, трудно сломать старое привычки. Я также вижу, что основные языки ООП включают функциональные функции, и поэтому приобретение навыков и состояния функционального программиста должно быть действительно удобным в ближайшем будущем. Интересное понимание, спасибо!
edalorzo
@jimwise: +1 за статью Харпера. Я считаю его подход очень подходящим. @edalorzo: Когда вы начинаете мыслить функционально, вы видите императивную парадигму как последнее средство, которое вам нужно применять для оптимизации вашей программы, когда она недостаточно быстра. Недавно я написал несколько небольших инструментов в Scala, не очень большие, но нетривиальные и обладающие реальной функциональностью. К моему удивлению, я ни varразу не использовал ни одну изменяемую коллекцию. Итак, императивное мышление - это IMO, своего рода преждевременная оптимизация, которая, как мы все знаем, является корнем всего зла.
Джорджио
2

В каких сценариях мне следует рассмотреть функциональные языки программирования, более подходящие для выполнения определенной задачи? Помимо недавно популярной многоядерной проблемы параллельного программирования.

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

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

Функциональное программирование не имеет ничего общего с ленью. ML и OCaml - функциональные и строгие языки. Самое большое препятствие, с которым вы столкнетесь, - это структурирование вещей в терминах неизменяемых значений и сведение головы вокруг любой абстракции, используемой в системе типов для побочных эффектов. Функциональные языки лучше подходят для оптимизации из-за того, что они делают явные побочные эффекты в системе типов. Haskell использует монады, но существуют другие подходы к использованию эффектов в чисто функциональных языках. У Clean есть уникальные типы, а у некоторых других языков в разработке есть и другие вещи.

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

Среди известных мне языков программирования я бы сказал, что только Haskell и Clean можно назвать функциональными языками. Все остальные допускают побочные эффекты, не делая их явными в системе типов. Так что, если вы собираетесь посвятить время изучению функционального программирования, то Haskell, вероятно, единственный, который отвечает всем требованиям. Все остальные, которые я знаю, Erlang, Scala, Clojure и т. Д., Просто предоставляют функциональные абстракции поверх императивного языка. Поэтому, если вы хотите подойти к функциональной парадигме в битах, я бы порекомендовал Scala или Erlang, и если вы хотите заняться всем сразу и, возможно, разочароваться, тогда вам следует пойти на Haskell.

davidk01
источник
@ Dadivk01 +1 Мне нравится рассуждение о том, что FP-языки являются просто конкурентным инструментом, как и любой другой, и могут использоваться для решения тех же проблем, что и другие модели. Почему вы думаете, что они менее популярны, тогда? И согласны ли вы с тем, что они лучше подходят для решения проблемы параллельных вычислений, чем, например, большинство языков ООП? Вы бы сказали, что неизменяемый тип данных влияет на объем памяти и производительность по сравнению с императивным языком? Я давал ему шанс на Хаскел, почему ты говоришь "сдаться в отчаянии", ты
пугаешь
@edalorzo: Я не думаю, что функциональное программирование лучше для параллельных алгоритмов. Люди путают декларативное программирование с функциональным программированием. Функциональное программирование связано с его декларативным характером и группой действительно умных людей, которые пишут превосходные компиляторы для преобразования декларативного кода в машинный код. Любой другой язык, который больше склоняется к описанию проблем, а не к четкому изложению мелких деталей, будет так же хорош для параллельного программирования.
davidk01
@edalorzo: Что касается «сдачи в отчаянии», я говорю это, потому что, если императивное программирование - это все, что вы знаете, тогда система типов haskell и ее монадический подход к описанию эффектов могут быть слишком сложными. Я думаю, что лучше начать с языка, который использует более прагматичный подход к побочным эффектам, такой как Erlang и Scala.
davidk01
0

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

РЕДАКТИРОВАТЬ: так как это не очевидно для всех.

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

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

Несколько примеров FP, используемых для параллелизма:

  • CouchDB - опираться на Erlang
  • Фейсбук чат - опираться на Erlang
  • Twitter - большая часть, основанная на Scala
Vartec
источник
3
Все заявляют о параллельном программировании, но данных для этого очень мало. Если вам известны какие-либо из таких источников, вам следует процитировать их. Сложные вычисления часто имеют сложные зависимости данных, и если вы используете функциональную парадигму программирования, внутренняя взаимозависимость данных некоторых моделей не исчезает волшебным образом. Программирование на GPU так же параллельно, как и раньше, но они получают благодаря использованию императивных языков просто отлично, потому что модели, с которыми они работают, имеют встроенный параллелизм.
davidk01
4
@vartec: В интересах объективности было бы неплохо, если бы вы могли предоставить ссылку, подтверждающую ваши претензии. Это поможет невежественным читателям гораздо больше, чем встречный вопрос ...
blubb
1
@vartec: На самом деле нет, мне никогда не приходило в голову, что многие люди, делающие какие-то заявления, подтверждают это. Я виню мою подготовку по математике, но не все из нас верят в такие вещи, как неопровержимые факты и конкретные обоснования наших утверждений, и ваша редакция по-прежнему не отвечает моему комментарию.
davidk01
1
@vartec Вы можете поместить ссылку на заслуживающий доверия источник, подтверждающий ваши претензии.
quant_dev
1
+1 @ davidk01 "Все заявляют о параллельном программировании, но данных для его подкрепления очень мало". Я знаю огромное количество доказательств обратного. Например, в статьях Cilk описывается, насколько важна мутация на месте, если вам нужна хорошая сложность кэша, которая является требованием масштабируемого параллелизма на многоядерном компьютере.
Джон Харроп