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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я говорю, что нет никакой причины не изучить его.

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

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

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

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

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

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

1. OO, пути не всегда были "нормальны". Стандарт этого десятилетия был маргинализованным понятием прошлого десятилетия.

2. Функциональное программирование является математикой. Paul Graham на Lisp (заменяют функциональным программированием Lisp):

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

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

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

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

С наилучшими пожеланиями, PS

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

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

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

, Что каждый - просто вопрос времени все же. Ваш средний корпоративный программист изучает то, что текущая Большая Вещь. 15 лет назад они не поняли ООП. , ЕСЛИ FP завоевывает популярность, Ваши "средние корпоративные программисты" будут следовать.

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

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

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

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

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

Одна вещь, которая определенно рассчитывает в их пользу, тем не менее, состоит в том, что недавно, C# принял крутой оборот к FP, до такой степени, что это практически превращает поколение программистов в программистов FP, без них даже замечающий . Это могло бы просто проложить путь к FP "оборот". Возможно.;)

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

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

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

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

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

Pro:

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

Мятежник:

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

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

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

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

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

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

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

Это передаст.

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

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

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

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

При чтении "Следующего Основного Языка программирования: Игра Перспектива Developer’s" Tim Sweeney, Эпическими Играми, моя первая мысль была - я добрался для изучения Haskell.

версия

PPT

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

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

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

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

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

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

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

Это завоевывает популярность, потому что это - лучший инструмент вокруг для управления сложностью. См.:
- двигает 109-116 из разговора Simon Peyton-Jones "Вкус Haskell"
- "Следующий Основной Язык программирования: Перспектива Разработчика игр" Tim Sweeney

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

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

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

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

Это делает Вас лучшим разумным существом.

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

природа не сохраняющая состояние FP отображается более естественно на природу не сохраняющую состояние сети, и таким образом функциональные языки предоставляют себя более легко более изящным, УСПОКОИТЕЛЬНЫМ веб-приложениям. Контраст с JAVA и платформами.NET, которые должны обратиться к ужасно ужасным ВЗЛОМАМ как СОСТОЯНИЕ ОТОБРАЖЕНИЯ и СЕАНСОВЫЕ КЛЮЧИ, чтобы поддержать состояние приложения и поддержать (иногда довольно текучий) абстракция императивного языка с сохранением информации, на функциональной платформе чрезвычайно не сохраняющей состояние как сеть.

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

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

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

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

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

мне будет интересно видеть, является ли F# вещью, которая продвигает FP в господствующую тенденцию.

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

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

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

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