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

Я вижу много разговоров о функциональных языках и прочем. Почему вы используете один язык вместо «традиционного»? Что они делают лучше? Чем они хуже? Какое идеальное приложение для функционального программирования?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ура, PS

Большинство приложений достаточно просты, чтобы их можно было решить обычным образом.

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

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

Итак, краткое объяснение того, почему этот язык 1950-х годов не устарел, состоит в том, что это была не технология, а математика, и математика не устареет. Правильнее сравнивать Lisp не с аппаратным обеспечением 1950-х годов, а, скажем, с алгоритмом Quicksort, который был открыт в 1960 году и до сих пор является самым быстрым типом общего назначения.

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

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

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

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

Это действительно не преподается в университетах (или это в настоящее время?)

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

Большинство приложений достаточно просты, чтобы их можно было решить обычным образом.

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

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

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

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

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

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

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

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

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

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

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

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

Это делает вас лучше живым существом.

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

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

* 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

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

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

Pro:

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

Contra:

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

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

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

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

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

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

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

Это пройдет.

Функциональное программирование великолепно. Однако это не захватит мир. C, C ++, Java, C # и т. Д. Все еще будут рядом.

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

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

РРТ

HTML-версия Google

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

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

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

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

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

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

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

Большинство приложений достаточно просты, чтобы их можно было решить обычным образом.

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

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

Checkout Почему функциональное программирование имеет значение

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

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

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

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

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

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

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

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

Ух ты - это интересная дискуссия. Мои собственные мысли по этому поводу:

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

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

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

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

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

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

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

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

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

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