Вопрос

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

Это было полезно?

Решение

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

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

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

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

Другие советы

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

Однако языки, которые обеспечивать соблюдение функциональный стиль в наши дни получает все большее распространение, и станут ли эти языки доминирующими в будущем, остается открытым вопросом.Мое собственное подозрение заключается в том, что гибридные, многопарадигмальные языки, такие как Скала или OCaml вероятно, будет доминировать над "пуристскими" функциональными языками точно так же, как чистый язык OO (Smalltalk, бета и т.д.) Повлиял на основное программирование, но не стал наиболее широко используемыми обозначениями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

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

  •   

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

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

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

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

    Это только вопрос времени. Ваш обычный корпоративный программист узнает, что это такое. 15 лет назад они не понимали ООП. IF FP привлекает ваших "средних корпоративных программистов" будет следовать.

      

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

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

      

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

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

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

    Профессиональный:

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

    Contra:

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

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

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

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

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

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

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

    Это пройдет.

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

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

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

    PPT

    HTML-версия Google

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

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

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

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

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

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

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

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

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

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

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

    В конце 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%.

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

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

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top