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

Ответ 1

Потому что все эти преимущества также являются недостатками.

Программы без гражданства; Никаких побочных эффектов

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

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

Concurrency; Воспроизводится очень хорошо с растущей многоядерной технологией

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

Программы обычно короче и в некоторых случаях легче читать

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

Производительность повышается (пример: Erlang)

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

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

Императивное программирование - очень старая парадигма (насколько мне известно) и, возможно, не подходит для XXI века

Функциональное программирование тоже очень старое. Я не вижу, насколько актуальна возраст концепции.

Не поймите меня неправильно. Мне нравится функциональное программирование, я присоединился к этой команде, потому что хотел помочь привнести концепции из функционального программирования в С#, и я думаю, что программирование в неизменном стиле - это путь будущего. Но есть огромные затраты на программирование в функциональном стиле, который просто не может быть желателен. Переход к более функциональному стилю будет происходить медленно и постепенно в течение нескольких десятилетий. И что это будет: переход к более функциональному стилю, а не оптовую торговлю чистотой и красотой Haskell и отказ от С++.

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

Ответ 2

Попытки программирования: беседы с создателями основных языков программирования

[Haskell]

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

Не так ли?

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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

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

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

Ответ 8

Не нужно воспринимать

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

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

Ответ 9

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

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

Программы без гражданства; Никаких побочных эффектов

Проще протестировать программы без учета состояния. Это сейчас широко оценено и часто используется в промышленности.

Concurrency; Воспроизводит многоядерную технологию Программы обычно короче и в некоторых случаях легче читать Производительность повышается (пример: Erlang)

Вы объединяете параллельные и parallelism.

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

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

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

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

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

Чисто функциональное программирование имеет множество серьезных недостатков, поэтому мы используем нечистые функциональные языки, такие как Lisp, Scheme, SML, OCaml, Scala и С#.

Ответ 10

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

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

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

Ответ 11

Две вещи:

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