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

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

Один из пользователей сказал, что императивный код легче понять, чем код функционального программирования. Это верно только в том случае, если читатель уже видел императивный код, особенно если предыдущие примеры относятся к одной "семье" (например, C/C++, Perl, PHP и Java). Я бы не стал утверждать, что это верно для любого императивного языка; для крайнего примера возьмем сравнение Java и Forth.

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

Если бы нас с самого начала обучали на языке типа Lisp или Haskell, мы бы все считали функциональные языки программирования совершенно нормальными.

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

Императивное и объектно-ориентированное программирование - это пошаговое описание проблемы и ее решения. Таким образом, это может быть легче понять. Функциональное программирование может быть немного непонятным.

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

Современное состояние таково, что императивные языки (такие как C #) заимствуют функции из функционального мира (например, лямбда-выражения) и наоборот.

Masterminds of Programming: Беседы с создателями основных языков программирования

[Haskell]

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

Джон Хьюз: Плохой маркетинг! Я не имею в виду пропаганду, ее у нас было предостаточно. Я имею в виду тщательный выбор целевой рыночной ниши для доминирования, за которым следуют решительные усилия сделать функциональное программирование самым эффективным способом решения этой ниши. В счастливые дни 80-х мы думали, что функциональное программирование хорошо для всего - но называть новую технологию "хорошей для всего" - это то же самое, что называть ее "особенно хорошей ни в чем". Каким должен быть бренд? Это проблема, которую Джон Лончбери очень четко описал в своем приглашенном докладе на ICFP. Компания Galois Connections чуть не разорилась, когда ее брендом было "программное обеспечение на функциональных языках", но они переживают бурный рост, сосредоточившись на "программном обеспечении высокой надежности".

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

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

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

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

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

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

С функциональной стороны это гораздо менее верно. Просто, например, я вполне разумно могу написать Scheme, но от этого мало толку при чтении Ocaml или Haskell (только для пары примеров). Даже в пределах одной семьи (например, Scheme vs. Common Lisp) знакомство с одним, похоже, не так хорошо переносится на другое.

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

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

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

Нет осознанной необходимости

Я вспоминаю реакцию моего старого босса Рика Клайна, когда я показал ему копию лекции Джона Бэкуса на премии Тьюринга под названием Можно ли освободить программирование от стиля фон Неймана?

Его реакция: "Может быть, некоторые из нас не хотят освобождаться от стиля фон Неймана!"

Не так ли?

В свое время Smalltalk был отличной объектно-ориентированной системой. Почему объектно-ориентированное программирование не взяло верх? Что ж, это так. Это просто не похоже на Smalltalk. Основные языки становятся все более похожими на Smalltalk с C ++, Java, C # и т. Д. Мода и стиль меняются медленнее, чем что-либо, поэтому, когда объектно ориентированный объект стал массовым, мы получили его, склеив части объектно-ориентированного программирования со старыми языками, так что он выглядел достаточно похожим на C, чтобы проглотить .

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

Две вещи:

1. Просто требуется время, независимо от того, насколько хороша технология. Идеям, лежащим в основе FP, около 70 лет. Но его массовое использование в разработке программного обеспечения (в окопах, в промышленности), вероятно, составляет менее 10 лет. Попросить разработчиков принять расово новое мышление можно, но это займет время (много, много лет). Например, ООП действительно получил широкое распространение в начале 1980-х годов. Однако до конца 1990-х гг. Он не выходил из строя.
   
2. Вам нужно, чтобы люди столкнулись с мощью технологии, прежде чем она станет популярной . В настоящее время люди используют инструменты, в которых не используется параллелизм, и все работает нормально. Когда приложения, не использующие параллелизм, становятся невыносимо медленными; тогда многие люди будут вынуждены использовать инструменты параллелизма, и популярность FP может резко возрасти. Это также может относиться к другим сильным сторонам FP.

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

1. Чтобы получить все преимущества функционального программирования, вам нужна лень . Да, есть строгие функциональные языки, но реальные преимущества функционального программирования не проявляются так же хорошо в строгом коде. Например, в Haskell легко создать последовательность ленивых операций над списком, объединить их и применить к списку. Например. op1 $ op2 $ op3 $ op4 $ someList . Я знаю, что он не собирается строить весь список, и внутри я просто собираюсь получить хороший цикл, который просматривает элементы по одному. Это позволяет писать действительно модульный код. Интерфейс между двумя модулями может включать в себя передачу потенциально обширных структур данных, но при этом вам не обязательно иметь эту структуру резидентно.

2. Но когда вам лень, становится трудно рассуждать об использовании памяти. Изменение флагов компилятора Haskell часто приводит к изменению объема памяти, используемой алгоритмом, с O (N) на O (1), но иногда это не так. Это неприемлемо, когда у вас есть приложения, которым необходимо максимально использовать всю доступную память, и это не очень хорошо даже для приложений, которым не нужна вся память.