Почему функциональные языки?

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

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

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

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

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

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

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

Многие современные языки содержат элементы функциональных языков программирования. C# 3.0 имеет множество функций функционального программирования, и вы также можете заниматься функциональным программированием на Python. Я думаю, что причины популярности функционального программирования в основном связаны с двумя причинами: параллелизм становится реальной проблемой в нормальном программировании, потому что мы получаем все больше и больше многопроцессорных компьютеров; и языки становятся более доступными.

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

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

Касса Почему так важно функциональное программирование

Я, должно быть, тупица, но все равно не понимаю. Есть ли какие-нибудь реальные примеры небольших приложений, написанных на функциональном языке, таком как F#, где вы можете посмотреть исходный код и увидеть, как и почему было лучше использовать такой подход, чем, скажем, C#?

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

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

На самом деле я изучаю LISP после прочтения «Хакеров и художников», и я действительно верю, что узнаю что-то от LISP, что поможет мне лучше понять все, что я программирую. Теперь я не думаю, что буду использовать LISP в повседневной жизни только потому, что в 1995 году какой-то парень создал веб-сайт, который стал Yahoo Stores. Так что это в любом случае беспроигрышный вариант (если он поймает, я выиграю, если нет, я получу больше точек зрения о том, как программировать и как все работает)

Теперь ... по другому вопросу, связанному с этим, думаю ли я, что программирование сильно изменится с появлением 32-ядерных процессов в следующем году? ДА, я не знаю, будет ли это функциональное программирование, но ... я почти уверен, что будет что-то другое!

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

Они преподавали Haskell и ML в Стэнфорде в конце 90-х. Я уверен, что такие места, как Карнеги-Меллон, Массачусетский технологический институт, Стэнфорд и другие хорошие школы, представляют его студентам.

Я согласен с тем, что большинство приложений, «выставляющих реляционные базы данных в Интернете», будут продолжать действовать в этом направлении еще долгое время. Java EE, .NET, RoR и PHP разработали несколько довольно хороших решений этой проблемы.

Вы натолкнулись на кое-что важное: это может быть проблема, которую нельзя легко решить другими способами, которые улучшат функциональное программирование. Что бы это было?

Смогут ли их подтолкнуть массивное многоядерное оборудование и облачные вычисления?

Most applications are simple enough to be solved in normal OO ways

1. ОО способы не всегда были «нормальными». Стандарт этого десятилетия был маргинализованной концепцией прошлого десятилетия.

2. Функциональное программирование - это математика. Пол Грэм о Лиспе (заменить Lisp функциональным программированием):

So the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn’t get stale. The right thing to compare Lisp to is not 1950s hardware, but, say, the Quicksort algorithm, which was discovered in 1960 and is still the fastest general-purpose sort.

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

Я говорю, что нет причин не учиться этому.

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

Большинство приложений можно решить с помощью [вставьте сюда свой любимый язык, парадигму и т. д.].

Хотя, это правда, для решения разных задач можно использовать разные инструменты. Функциональность просто позволяет еще одну абстракцию высокого (более высокого?) Уровня, которая позволяет выполнять нашу работу более эффективно при правильном использовании.

It's not really taught at universities (or is it nowadays?)

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

Most applications are simple enough to be solved in normal OO ways

В том же курсе CS середины 90-х ОО (преподаваемый с использованием Eiffel) преподавался почти наравне с функциональным программированием. Оба в то время не были популярными. OO сейчас может быть "нормальным", но никогда таким не было.

Мне будет интересно узнать, является ли F# тем, что продвигает FP в мейнстрим.

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

Такие языки, как Clojure или F#, могут быть исключением из правил, учитывая, что они построены на JVM / CLR. В результате у меня нет для них ответа.

F# может завоевать популярность, потому что Microsoft настаивает на этом.

Pro:

• F# станет частью следующей версии Visual Studio
• Microsoft создает сообщество в течение некоторого времени - евангелисты, книги, консультанты, которые работают с известными клиентами, значительное присутствие на конференциях MS.
• F# - это первоклассный язык .Net, и это первый функциональный язык, который имеет действительно большую основу (не то чтобы я сказал, что Lisp, Haskell, Erlang, Scala, OCaml не имеют большого количества библиотек, они просто не так полны, как .Net является)
• Сильная поддержка параллелизма

Contra:

• F# очень сложно начать, даже если вы хорошо разбираетесь в C# и .Net - по крайней мере, для меня :(
• вероятно будет сложно найти хороших разработчиков F#

Итак, я даю 50:50 шанс F# стать важным. Других функциональных языков в ближайшее время не будет.

Потому что FP имеет значительные преимущества с точки зрения производительности, надежности и ремонтопригодности. Многоядерные могут быть убийственным приложением, которое, наконец, заставит крупные корпорации переключиться, несмотря на большие объемы унаследованного кода. Более того, даже крупные коммерческие языки, такие как C#, приобретают особую функциональную окраску в результате многоядерных проблем - просто побочные эффекты не подходят для параллелизма и параллелизма.

Я не согласен с тем, что "нормальные" программисты этого не поймут. Они будут, точно так же, как они в конце концов поняли ООП (что так же загадочно и странно, если не более того).

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

The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it

Но это лишь вопрос времени. Ваш средний корпоративный программист узнает, что такое большое дело в настоящее время. 15 лет назад они не понимали ООП. ЕСЛИ FP завоевывает популярность, ваши «средние корпоративные программисты» последуют за ним.

It's not really taught at universities (or is it nowadays?)

Очень сильно различается. В моем университете SML - это первый язык, с которым студенты знакомятся. Я считаю, что MIT преподает LISP в качестве первого года обучения. Эти два примера, конечно, могут не быть репрезентативными, но я считаю, что большинство университетов, по крайней мере, предлагают некоторые факультативные курсы по FP, даже если они не делают это обязательной частью учебной программы.

Most applications are simple enough to be solved in normal OO ways

Однако на самом деле это не вопрос «достаточно просто». Будет ли решение проще (или более читабельное, надежное, элегантное, производительное) в FP? Многие вещи «достаточно просты, чтобы их можно было решить на Java», но для этого по-прежнему требуется огромное количество кода.

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

Однако одна вещь, которая определенно считается в их пользу, заключается в том, что в последнее время C# резко повернул в сторону FP до такой степени, что фактически превратил поколение программистов в программистов FP, без них даже не заметив. Это могло бы просто подготовить почву для «революции» ФП. Может быть. ;)

Функциональное программирование уже прижилось ИМХО, просто пока не очень заметно. Сильной стороной таких языков является математика / алгоритмы, что является одной из причин, по которой Halo Guys используют его для своих материалов TrueSkill.

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

Это пройдет.

Функциональное программирование - это здорово. Однако он не захватит мир. C, C++, Java, C# и т. д. По-прежнему будут доступны.

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

Некоторое время дела шли в функциональном направлении. Два крутых новичка последних нескольких лет, Ruby и Python, радикально ближе к функциональным языкам, чем те, что были до них - настолько, что некоторые Lispers начали поддерживать один или другой «достаточно близко».

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

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

• Замыкания, анонимные функции, функции передачи и возврата в виде значений раньше были экзотическими функциями, известными только хакерам Lisp и ML. Но постепенно C#, Delphi, Python, Perl, Javascript добавили поддержку замыканий. Невозможно серьезно отнестись к любому многообещающему языку без закрытий.

• Несколько языков, особенно Python, C# и Ruby, имеют встроенную поддержку для понимания списков и генераторов списков.

• ML впервые применил универсальное программирование в 1973 году, но поддержка универсального программирования («параметрический полиморфизм») стала отраслевым стандартом только в последние 5 лет или около того. Если я правильно помню, Fortran поддерживал дженерики в 2003 году, за ним последовали Java 2004, C# в 2005 году, Delphi в 2008 году. (Я знаю, что C++ поддерживает шаблоны с 1979 года, но 90% обсуждений STL C++ начинаются с фразы «вот тут демоны» .)

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

Most applications are simple enough to be solved in normal OO ways

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

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

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

Наконец, я не могу не отметить, что ваши комментарии по поводу FP очень похожи на замечания, которые я слышал от процедурных программистов не так много лет назад:

• (Мифический, ИМХО) "средний" программист этого не понимает.
• Этому не учат.
• Любая программа, которую вы можете написать с его помощью, может быть написана другим способом с использованием современных методов.

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

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

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

Это делает вас более разумным существом.

Вау - это интересное обсуждение. Мои собственные мысли по этому поводу:

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

Я всегда скептически отношусь к следующему важному событию. Зачастую «Следующая большая вещь» - это чистая историческая случайность, когда она оказывается в нужном месте в нужное время, независимо от того, хороша технология или нет. Примеры: C++, Tcl / Tk, Perl. Все несовершенные технологии, все безумно успешные, потому что считалось, что они либо решают проблемы дня, либо почти идентичны устоявшимся стандартам, либо и то, и другое. Функциональное программирование действительно может быть прекрасным, но это не значит, что оно будет принято.

Но я, может, скажу вам, почему люди в восторге относятся к функциональному программированию: многие, многие программисты имели своего рода «опыт преобразования», в котором они обнаруживают, что использование функционального языка делает их вдвое продуктивнее (или, может быть, в десять раз продуктивнее) при создании код, который более устойчив к изменениям и имеет меньше ошибок. Эти люди считают функциональное программирование секретным оружием; Хороший пример такого мышления - Превосходя средние показатели Пола Грэма. О, и его приложение? Веб-приложения для электронной коммерции.

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

В целом американские университеты плохо преподают функциональное программирование. Существует сильная поддержка обучение вводному программированию с использованием Scheme, и Haskell также пользуется некоторой поддержкой, но очень мало возможностей для обучения продвинутой технике для функционального программиста. Я читал такой курс в Гарварде, и этой весной вернусь в Тафтс. Бенджамин Пирс вел такой курс в Пенсильвании. Я не знаю, делал ли Пол Худак что-нибудь в Йельском университете. Европейские университеты работают намного лучше; например, функциональному программированию уделяется большое внимание в важных местах в Дании, Нидерландах, Швеции и Великобритании. У меня меньше понимания того, что происходит в Австралазии.

Он уже прижился с Map / reduce в Hadoop

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

P.S. Когда я учился в колледже Бостонского университета ('98 -'02), мы потратили семестр на изучение Scheme, который является близким родственником LISP. Когда мы только начали изучать это, я хотел вырвать себе волосы. К концу курса это было очень естественно.

Я не вижу здесь никого, кто упоминал бы о слоне в комнате, так что думаю, это зависит от меня :)

JavaScript - это функциональный язык. По мере того, как все больше и больше людей делают более сложные вещи с помощью JS, особенно используя более тонкие аспекты jQuery, Dojo и других фреймворков, FP будет вводиться через черный ход веб-разработчика.

В сочетании с замыканиями FP делает код JS действительно легким, но все же читаемым.

Ваше здоровье, PS

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

Природа FP без состояния более естественным образом соответствует природе Интернета без состояния, и, таким образом, функциональные языки легче поддаются более элегантным, RESTFUL webapps. В отличие от фреймворков JAVA и .NET, которым необходимо прибегать к ужасно уродливым ХАКАМ, таким как ключи VIEWSTATE и SESSION, для поддержания состояния приложения и поддержания (иногда довольно протекающей) абстракции императивного языка с сохранением состояния на функциональной платформе без сохранения состояния, такой как Интернет.

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

Бьюсь об заклад, вы не знали, что занимаетесь функциональным программированием, когда использовали:

• Формулы Excel
• Кварцевый композитор
• JavaScript
• Логотип (графика черепаха)
• LINQ
• SQL
• Underscore.js (или Lodash), D3

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

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

Это завоевывает популярность, потому что это лучший инструмент для управления сложностью. Смотрите:
- слайды 109-116 выступления Саймона Пейтон-Джонса "Вкус Haskell"
- «Следующий мейнстримный язык программирования: взгляд разработчика игр» Тим Суини.

Эээ, извините за педант, но он уже прижился - мы называем это Excel.

http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/

Подавляющее большинство программ, работающих на компьютерах, написано в Excel или в одном из многих его популярных клонов.

(есть много программ, которые запускаются много раз, и программы, написанные в Excel, как правило, НЕ являются одними из них - большинство программ Excel имеют один экземпляр запуска)

ФП - следующая лучшая парадигма, которая точно. Теперь, какой язык может быть следующим шагом. Это сложная задача, но я считаю, что это могут быть Haskell, F#, Clojure, Ocaml или Erlang. Или может быть Python с большим количеством конструкций FP и лучшей поддержкой параллелизма / производительности, или Perl 6 с parrot выглядит очень интересно.

• Сколько времени нужно, чтобы ООП понял средний корпоративный программист ...?
• Меня учили функциональному программированию в Утрехтском университете, я думаю, в 1994 году, и я вижу, что это начинает завоевывать популярность «в реальном мире» только в последние пару лет.
• Не существует такого понятия, как «простое приложение». ;-)

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

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

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

Некоторые мысли:

• Споры между FP и императивным программированием (объектно-ориентированное, структурированное и т. д.) Бушуют со времен Лиспа против Фортрана. Я думаю, вы задаете отличные вопросы, но понимаете, что они не особенно новы.
• Отчасти шумиха вокруг FP заключается в том, что мы, кажется, осознаем, что параллелизм очень сложен, и что блокировки и другие механизмы в объектно-ориентированном программировании (например, Java) - лишь одно из решений. FP предлагает освежающие изменения с такими идеями, как актеры и мощь вычислений без сохранения состояния. Тем, кто борется с ОО, пейзаж кажется очень привлекательным.
• Да, в школах преподают FP. Фактически, Университет Ватерлоо и другие предлагают схему в первый год обучения (ссылка здесь).
• Что касается среднего программиста, я уверен, что те же аргументы были приведены против C++ еще в начале 1990-х годов. И посмотрите, что произошло. Если предприятия могут получить преимущество с помощью технологии, вы можете держать пари, что люди будут проходить обучение.

Это не значит, что это наверняка или что через 3-5 лет не будет обратной реакции (как всегда). Однако тенденция к FP имеет свои достоинства и заслуживает внимания.

Когда я читал «Следующий мейнстримный язык программирования: взгляд разработчика игр» Тима Суини, Epic Games, моей первой мыслью было - мне нужно выучить Haskell.

PPT

HTML-версия Google

Есть отличная статья от Слава Ахмечет под названием Функциональное программирование для всех остальных (кстати, именно эта статья привела меня в FP). Среди преимуществ FP он необычно подчеркивает следующее (что, как я считаю, способствует привлекательности для инженеров-программистов):

• Модульное тестирование
• Отладка
• Параллелизм
• Развертывание горячего кода
• Доказательства и оптимизация с помощью машины

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

Настоятельно рекомендуется !

Многие люди упомянули функциональные языки.

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

Excel, SQL, XSLT, XQuery, J и K используются в финансовой сфере.

Конечно Эрланг.

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

Функциональное программирование, вероятно, будет инструментом, который используют инженеры, ученые для решения проблем, с которыми они сталкиваются. Это не займет мир, как предыдущие языки. Однако сложнее всего превзойти Excel. Если я инженер и мне нужно делать расчеты, Excel - это здорово.

Однако F# станет еще одним источником и, скорее всего, удовлетворит потребности в дизайне не-компьютерных ученых. Посмотрим правде в глаза, компьютерные ученые проделали огромную работу по созданию ВСЕГО нового способа работы. Объектно-ориентированное программирование - это ВЕЛИКОЛЕПНО. Но иногда вам просто нужен способ решить уравнение, получить решение и построить график. Вот и все. Тогда такой язык, как F#, заполняет счет. Или, может быть, вы хотите построить конечный автомат, F# снова может быть одним из решений, но тогда C также может быть решением.

Но когда дело доходит до параллельной обработки, Excel сияет, и со временем F# тоже появится. Однако в дружеской манере F# = дружелюбный.

В ходе обсуждения упущено то, что лучшие системы типов находятся в современных языках программирования FP. Более того, компиляторы могут автоматически определять все (или, по крайней мере, большинство) типов.

Интересно, что при программировании Java половину времени тратится на написание имен типов, однако Java далеко не безопасен по типу. Хотя вы никогда не можете писать типы в программе Haskell (кроме как своего рода проверенной компилятором документации), а код на 100% безопасен по типу.

Microsoft действительно продвигает F# в следующей версии Visual Studio. Это гибридный язык, такой как Scala, и он очень хорошо интегрируется с остальной частью .NET Framework. Я думаю, что многие магазины Microsoft собираются использовать его для ускорения разработки приложений и функций для высокопараллельной обработки данных.

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

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

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

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

Я хотел бы отметить, что все, что вы говорили о функциональных языках, большинство людей говорили об объектно-ориентированных языках около 20 лет назад. В то время очень часто можно было услышать об OO:

* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways

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

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

Функциональное программирование существует уже давно, поскольку LISP был одним из первых языков, имевших компилятор, а также со времен LISP-машин MIT. Это не новая парадигма (OO намного новее), но доминирующие программные платформы, как правило, были написаны на языках, которые легко переводятся на язык ассемблера, а их API-интерфейсы в значительной степени поддерживают императивный код (UNIX с C, Windows с C и Macintosh с Pascal и позже C).

Я думаю, что новое нововведение за последние несколько лет - это распространение разнообразных API-интерфейсов, особенно для таких вещей, как веб-разработка, где API-интерфейсы платформ неуместны. Поскольку вы не кодируете напрямую Win32 API или POSIX API, это дает людям свободу опробовать функциональные языки.

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

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

- Миямото Мусаси, "Книга пяти колец"

Я не думаю, что функциональные языки что-то решат, и что это просто шумиха, которую пытается продать руководство, помните единственную правду:

Серебряной пули нет.

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