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

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

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

Я бы сказал, что одной из причин того, что функциональное программирование не является более распространенным, является отсутствие базы знаний. Мой опыт показывает, что корпорации очень склонны к риску с точки зрения внедрения технологий, которые не являются основным потоком и предпочитают инвестировать в проверенные и настоящие фреймворки (java, c ++, c #). Только тогда, когда есть потребность бизнеса (как в Ericsson), новые парадигмы рассматриваются. Но даже в случае Эрикссон я слышал, что руководство потребовало использования c ++, и Джо Армстронг был вынужден кодировать вызовы erlang на c ++ !! Это должно показать, как корпорации неохотно внедряют новые технологии!

Я был профессором, и, как программисты, профессора всегда ищут Next Big Thing. Когда они думают, что нашли один, они делают его победителем, и все накапливаются. Поскольку они проповедуют студентам, которые считают, что профессора должны быть очень умными, иначе почему они будут профессорами, они не получают никакого сопротивления.

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

Учитывая это, функциональное программирование - это всего лишь одна стрелка в вашем колчане, а не единственная, точно так же как ООП не единственная.

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

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

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

Например, созданный мной стартап использует функциональный язык (Clojure) в качестве основного языка разработки по следующим причинам:

• Производительность - изучать FP сложно, но как только вы освоите его, его очень трудно превзойти с точки зрения силы и выразительности. Я, вероятно, пишу около 1/10 от количества строк для реализации какого-либо компонента функциональности по сравнению с тем, что мне понадобилось бы в C # или Java

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

• Параллелизм - функциональные языки подчеркивают неизменность, что дает огромные преимущества для параллельных приложений, чем необходимость эффективной работы на нескольких ядрах. И нравится это или нет, но будущее за несколькими ядрами. См. Http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey для блестящего объяснения того, почему это так важно

• Композиционность / модульность - функциональные языки, по-видимому, легче объединяют компоненты, чем сложные ОО-системы. Я до сих пор не выяснил всех причин этого, но отчасти это связано с тем, что у вас нет всей «случайной сложности», которую модели OO таскают с собой. Доклад Стюарта Хэллоуэя о радикальной простоте раскрывает эти идеи гораздо глубже.

РЕДАКТИРОВАТЬ : В ответ на комментарий Деспертара, примером «случайной сложности» систем ООП, которая ограничивает модульность, являются проблемы с глубоким клонированием или мелким клонированием: вы не можете составлять объекты вместе и передавать их как составные структуры без тщательный анализ семантики клонирования и мутации. В небольших случаях это управляемо, но в сложных системах это быстро становится серьезной проблемой. Эта проблема не будет существовать в первую очередь, если вы полагаетесь на чисто функциональные структуры данных.

Отсутствие приложения убийцы

Эй, этот здесь выглядит свежо. (копать копать копать)

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

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

• C: Работает везде (это был конец 70-х и 80-х)
• C ++: GUI-фреймворки (начало 90-х)
• Ява: апплеты и сервлеты (в конце 90-х)
• Objective-C: приложения для iOS (до этого приложения для OS X)
• Рубин: Рельсы
• C #: ASP.NET, WinForms
• PHP: Wordpress и др.
• Javascript: AJAX, особенно через фреймворки
• Луа: Сценарии игр, особенно WoW

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

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

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

• Emacs Lisp: Постоянное использование разработчиками в Emacs с 80-х годов. ( Вряд ли когда-либо используется где-либо еще.)
• Эрланг: Везде, где вы хотите много одновременных агентов.
• Схема: образование
• APL / J / K: Финансы (давайте назовем их функционалом ради аргумента)
• Common Lisp: «ИИ» - это то, что люди обычно говорят, для чего он используется, что является благословением и проклятием.

Теперь, единственный основной язык, который я чувствую, что я оставил из этого обсуждения, это Python. Python сделал что-то очень интересное; он преуспел, не выглядя победителем в любой крупной нише. Это может означать, что я совершенно не прав, рассматривая таким образом популярность языка. Это также может означать, что достаточно хороший язык может стать популярным без приложения-убийцы, чтобы стимулировать принятие и принятие, но это очень сложно и может занять очень много времени. (У Perl похожая история, но она появилась несколькими годами ранее и сейчас имеет меньшее распространение.)

Исходя из этого, я могу сказать, какие функциональные языки, на мой взгляд, находятся на подъеме:

• Clojure: веб-программирование, особенно через Героку
• Scala: Lift (или, может быть, Play, в наши дни) - JVM без Java

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

По той же причине, по которой Лисп так и не завоевал популярность (пусть начнутся огненные войны!). Функциональное программирование - очень чуждая парадигма по сравнению с императивным и объектно-ориентированным программированием. Если, как и подавляющее большинство учеников CS, вы начали с C и перешли на C ++ / Java, вы, как правило, не хотите учиться мыслить так, чтобы это было абсолютно ортогонально тому, как вы обычно думаете.

Давайте рассмотрим бизнес и программирование.

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

Более того, в бизнесе самая дешевая вещь - это то, что они делали вчера. Изменение, однако, желательно, стоит дорого. Если бы компания перешла от, скажем, решения C # / .NET, даже к F #, у них были бы проблемы. Их программисты (которые, вероятно, не самые проницательные программисты) должны будут выучить новый язык, быть опытными в обоих и часто использовать оба языка. Там будут подпрограммы, написанные на обоих в течение длительного времени. Если бы они перешли на что-то вроде Haskell, или если бы они в первую очередь использовали C ++ / MFC, они бы изменились намного больше, и это было бы намного дороже.

Кроме того, в течение долгого времени ожидается поставка программистов на C # и продолжение поддержки Microsoft. На нынешние ИТ-практики можно рассчитывать. Не существует такого же уровня институциональной поддержки или гарантии постоянной доступности программистов.

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

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

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

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

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

Вот:

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

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

Настоящая проблема - это государство.

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

Но мы запускаем код на машинах с архитектурой Von-Neuman, которые по своей природе полны состояния. Таким образом, мы на самом деле не избавились от состояния, функциональные языки просто скрывают сложность состояния от разработчика. Это означает, что язык / компилятор должен иметь дело с состоянием за кулисами и управлять им.

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

Таким образом, возникает вопрос: может ли язык эффективно управлять состоянием за смыслом? Особенно, когда размер данных намного превышает размер архитектуры.

Глядя на это с аппаратной стороны

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

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

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

Глядя со стороны промышленности:

В промышленности много неэффективных штатных программистов.

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

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

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

С точки зрения найма

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

Этот вопрос имеет несколько неправильную предпосылку. По следующим причинам:

1. Функциональное программирование на самом деле довольно распространено в отрасли. Но он используется только там, где есть опытные программисты. Нельзя ожидать, что новички это знают. Почти все крупные программные проекты используют его, но они просто держат его в областях, которые обрабатываются опытными программистами. Новички будут иметь дело с простыми модулями, которые не требуют функционального программирования.
2. Учитывая эту реальность, компании, которые нанимают людей (обычно молодых, поступающих из университета), не могут на самом деле запросить опыт функционального программирования. Любой, кто участвует в проектах, требующих функционального программирования, уже 15 лет работает в одной компании.
3. Университеты начинают учить этому, потому что уже сейчас знают, что знания по функциональному программированию будут очень полезны через 30 лет. Их временной диапазон составляет 30 лет, а не нормальное полугодие, как в компаниях.
4. Эти моменты являются причиной того, что люди разочаровываются, когда входят в рабочую силу и видят, что то, что они узнали в университете, не используется. Но они были рассчитаны на 30 лет, и в конечном итоге это будет полезно - просто компании используют простые вещи - то, что они могут ожидать от людей.
5. Также вы были бы высокомерны, если думаете, что после нескольких лет обучения в университете вы достаточно хорошо знаете функциональное программирование, чтобы использовать его в реальных программных проектах. Начните с простых вещей в первую очередь. Вам не нужно делать самое сложное программное обеспечение в качестве первой задачи, когда вы начинаете работать. Вы в конечном итоге доберетесь до сложных вещей, но это займет время.

Потому что сложнее отлаживать FP.