Для каких общих проблем функциональное программирование не подходит? [закрыто]

22

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

Для каких общих проблем не подходит функциональное программирование?

functional-programming paradigms Jonas
источник
Уф! Какое-то время я думал, что вы сказали, что «это дефектная парадигма». Потом я вернулся и проверил.
Марк С
1
Я думаю, что точнее сказать, что побочные эффекты изолированы (в любом случае в Haskell), чем их можно избежать. Монады допускают изменения состояния, и одна даже называется «Состояние».
Ларри Коулман
Как объяснил Ларри Коулман, это неправда, что функциональное программирование избегает побочных эффектов, но что оно не поощряет их использование и, в некоторых языках, оно явно изолирует их. Прочитайте, например, раздел 7 research.microsoft.com/en-us/um/people/simonpj/papers/…
Джорджио

Ответы:

17

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

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

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

Мэтт Оленик
источник
9
В статье «Следующие основные языки программирования: Перспектива разработчика игр» приводятся аргументы в пользу pl, специально для разработки игр, где по умолчанию используется чисто функциональное поведение, а изменение состояния отслеживается с помощью типов, чтобы избежать ошибок. Поэтому не все считают, что функциональная парадигма изначально не подходит для программирования игр.
sepp2k
1
@ sepp2k, спасибо за ссылку. Я рад видеть перспективу, спорную от того, кто сделал настоящие игры.
Мэтт Оленик
3
@ sepp2k подожди, я что-то пропустил? После более внимательного прочтения презентации кажется, что Суини спорил о том, чтобы большая часть основного движка была написана с чисто функциональным кодом, а большая часть игровой логики была написана императивно (или, по крайней мере, позволила) и использовала STM для обеспечения параллелизма. , Это кажется мне очень разумным.
Мэтт Оленик
@Matt: Нет, вы правы, он говорит, что игровая логическая часть будет содержать изменяемое состояние. Однако это не мешает языку отслеживать изменчивость по типам (что он предлагает в разделе «размышления»). Конечно, «отслеживание состояния через типы» не равно «функционалу», поэтому я мог бы сформулировать свой предыдущий комментарий слишком оптимистично.
sepp2k
@ sepp2k правильно, я понимаю, что ты имеешь в виду.
Мэтт Оленик
17

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

AShelly
источник
3
Ну, если вы просто имеете в виду аппаратный интерфейс, я сомневаюсь, что что-то кроме C / C ++ - хороший выбор. Однако на верхнем уровне этого языка иногда используются такие языки, как Erlang, особенно в телекоммуникационных системах. Erlang - это функциональный язык, разработанный для критических и отказоустойчивых встроенных систем реального времени.
Джонас
@Jonas: Erlang может минимизировать мутации, но он сильно зависит от IO для передачи сообщений, что, конечно, является побочным эффектом.
Джон Харроп
11

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

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

mipadi
источник
-1: Вы говорите о чистоте и игнорируете использование первоклассных функций, например, обратные вызовы в коде GUI намного проще с нечистыми языками FP, чем с языками ООП.
Джон Харроп
4
@Jon Harrop: Первоклассные функции не являются уникальными для функциональных языков программирования. Я до сих пор утверждаю, что стиль FP не очень подходит для GUI.
Mipadi
1
Зависит от того, кого вы спрашиваете. Для большинства функциональных программистов первоклассные функции - это само определение функционального программирования.
Джон Харроп
@ Джон Харроп: Большинство функциональных программистов сказали бы, что функциональное программирование - это метод описания программ как состава и оценки математических функций. Функции первого класса являются важной частью этой парадигмы, но одни только функции первого класса не делают функционального языка программирования (или функциональной программы). Парадигма функционального программирования стремится минимизировать использование структур состояний и изменчивых данных, и даже нечистые языки FP поддерживают этот стиль. FP - это как стиль программирования, так и отдельные функции, такие как первоклассные функции, и ...
mipadi
... Я не считаю, что эта парадигма особенно подходит для программирования GUI - вообще говоря, объектно-ориентированные языки лучше подходят для GUI.
Mipadi
5

Управляемые данными бизнес-приложения. Пользовательский интерфейс и простые операции с данными не требуют FP.

Бранимир
источник
2
И любое другое приложение для просмотра / просмотра данных. Большинство игр все о состоянии и изменении его, и поэтому не очень хорошо переводят в функциональный стиль.
Джон Пурди
18
В самом деле? Я всегда думал, что FP будет особенно хорош для этого. Разве не 99% того, что эти приложения выбирают, объединяют и проецируют данные? Это в основном filter, reduceи map. Бросьте в некоторых sort, partition, groupBy. В конце концов, наиболее широко используемый язык программирования для написания таких приложений - это Excel, который является функциональным языком.
Йорг Миттаг
3
Управляемые данными бизнес-приложения и приложения с простыми операциями с данными звучат как очень подходящие для FP, и я слышал, что FP популярен для таких вещей. Например, см. Приключения для функционального программиста на Уолл-стрит
Джонас
1
-1: Вы перечислили несколько приложений, в которых FP превосходит.
Джон Харроп
2

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

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

Одним из примеров является уже упоминавшийся Erlang для встроенных систем реального времени.

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

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

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

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

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

Пер Стритцингер
источник
Приложения с полным состоянием, такие как приложения с графическим интерфейсом, на самом деле сложно сделать функциональными, или у вас есть какие-либо рекомендации?
Джонас
Если у вас есть какая-то абстракция процесса / потока (например, как в Erlang), вы можете передать свое состояние в процессе.
Пер Стритцингер
3
Приложения с графическим интерфейсом обычно строятся вокруг цикла обработки событий. Вы можете написать цикл обработки событий довольно хорошо на функциональном языке. Если это сложнее, вы, вероятно, добавите несколько потоков / процессов для фоновой обработки. Но если у вас есть какая-то абстракция процесса / потока (например, как в Erlang), вы можете легко передать свое состояние в процессе. Продолжения также могут пригодиться. Я думаю, что это просто привыкает делать вещи функциональным способом, чтобы даже справиться с GUI. Одна из причин, почему программирование GUI сегодня считается сложным, заключается в том, что большинство наборов инструментов не предназначены для функционального использования.
Пер Стритцингер
1
@Jonas: в Haskell вы бы использовали либо монаду IO, либо монаду State, либо их комбинацию.
Ларри Коулман
1
@Jonas: это зависит от вашего определения полезного. Пример викибук использует wxHaskell, в то время как в реальном мире Haskell использует gtk2hs. Я тоже не пробовал, так как мое приложение на Haskell основано на командной строке.
Ларри Коулман