Является ли реактивное программирование ограниченным функциональным программированием?

Ответ 1

Я использую то, что я бы назвал Reactive Programming, или SEDA (Staged Event Driven Architecture), но я мало использую способ функционального программирование. http://www.slideshare.net/PeterLawrey/writing-and-testing-high-frequency-trading-engines-in-java

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

Часто разработчики считают, что им приходится использовать несколько потоков или ядер, потому что они есть. Это похоже на то, что вам нужно использовать 100% дискового пространства или тратить его впустую.

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

Ответ 2

Я предполагаю, что вы проводите курс реактивного программирования Одерски/Мейер/Кун? Затем вы увидели интерпретацию Мартина Одерского в первой сессии: он использует очень широкое описание из словаря, в котором реактивные средства "легко реагируют на стимул". Так что это о программе, наблюдающей и ожидающей некоторого стимула, на который он реагирует.

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

Функциональное реактивное программирование или FRP, с другой стороны, - это термин, придуманный Коналом Эллиоттом и Полом Худаком (первоначально: Функциональная реактивная анимация, поскольку она имела в виду графические интерфейсы). Он тесно связан с их работой и языком программирования Haskell.

Многие библиотеки, которые реализуют реактивные идеи (см., например, статью WP по реактивному программированию), разделяют аспект структуры событий с FRP, в то время как они не обязательно распространяются на аналитические/непрерывные сигналы или "поведение" FRP, которые дополняют события.

Вы обнаружите, что некоторые люди утверждают, что реактивное программирование без привязки к каноническому FRP-к примеру. при использовании актеров или каналов - это "красть" термин от "истинных носителей" этого названия. Таким образом, это обсуждение может легко стать идеологическим. С другой стороны идеологического, вы обнаружите, что реактивный часто (ab) используется в качестве нового слова. "Реактивный манифест" (манифест... действительно!? вы можете даже подписать этот материал...), вероятно, будет примером этой стороны.

Ответ 3

Для меня этот "Реактивный манифест" - просто модное слово. Эрланг реализует все это с 80-х бесплатно и тихо.

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

Удача в реализации "реактивной" системы с использованием общих состояний, потоков, блокировок, семафоров... И вы знаете, они говорят, что только два человека могут получить правильную параллельную систему Java, Дуг Ли и Брайан Гетц.

Ответ 4

Вам может быть интересно взглянуть на Реактивный манифест.

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

Ответ 5

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