FRP - это потоковая передача событий и поведения через чистые функции. Модель Actor - по крайней мере, как реализована в Akka - предназначена для потоковой передачи неизменяемых сообщений (которые можно считать дискретными событиями) через потенциально нечистые объекты, называемые акторами.
Так что на первый взгляд они кажутся родственными.
Что еще можно сказать о том, как они связаны? Кроме того, что можно сказать о том, какие из них могут быть более подходящими для разных областей применения?
Ни актеры, ни FRP не занимаются потоковым вещанием. Актеры даже не поддерживают внешнюю конфигурацию выходного потока.
FRP сильно характеризуется своими модельными сигналами и событиями на линейной временной шкале, что позволяет составлять поведение FRP детерминистическим образом. Актеры сильно характеризуются обработкой сообщений в недетерминированном порядке и почти не имеют композиционных свойств (то есть вы не можете рассматривать расположение двух акторов как более крупного актера).
Если вы ищете сходства, оба актера и FRP тесно связаны с лямбда-исчислением. Оба могут моделировать системы, реагирующие на человеческий вклад. Оба поддерживают моделирование внутреннего (локального) состояния.
FRP поддерживает локальное состояние через интегралы или накопители (складываются со временем), в то время как модель акторов поддерживает состояние, позволяя каждому субъекту указывать свое поведение для следующего сообщения в ответ на текущее. Эта распространенная поддержка локального состояния делает FRP и Actors неадекватными для прямого программирования (или обновления программного кода во время выполнения); потерять важное состояние становится слишком легко.
Относительно доменов приложений:
Модель акторов хорошо подходит для открытых систем, где мы можем установить или поддерживать акторов во время выполнения. Модель акторов также слабо подходит для распределенных систем, так как недетерминированный порядок сообщений может упростить соответствующую реализацию. (Причина, по которой действующие лица не так сильно подходят для распределенных систем, заключается в том, что обеспечение доставки сообщения «один раз и только один раз» довольно сложно перед лицом срыва, и субъекты также, как правило, требуют распределенного GC, что является болью.)
FRP хорошо подходит для закрытых систем, которые работают в течение долгого времени - например, роботизированные контроллеры, программирование музыки, вычислительные игрушки. Детерминизм и композиционные особенности делают FRP более удобным для работы, чем актеры, по крайней мере в тех случаях, когда FRP может напрямую моделировать решение. Интеграция FRP с эффектами (элегантно, без взлома модели с примесями) оказалась сложной задачей. Недавно была проведена работа над эффективным FRP через «червоточины» - эффективный, уникальный или линейный типизированный доступ к ресурсам.
Есть другие модели, которые лежат где-то между FRP и Актерами.
Потоковое программирование (FBP), разработанное Джоном Полом Моррисоном, действительно поддерживает потоковую передачу сообщений.
Протоколы Time Warp (или более поздняя работа над Lightweight Time Warp (LTW)) размещают подобные актерам сообщения на логической временной шкале, чтобы обеспечить более контролируемое и составное представление о передаче сообщений. Time Warp часто используется для больших параллельных и распределенных систем, например, для научных вычислений. Первоначальная временная деформация была непригодна для интерактивных симуляций (реагирование на человеческий вклад), а LTW подходит лишь в незначительной степени.
Я занимаюсь разработкой Reactive Demand Programming (RDP), которая позволяет реагировать на композиционные, FRP-подобные манипуляции и обработку сигналов в открытых и распределенных системах и устраняет локальное состояние. RDP достигается путем ограничения побочных эффектов коммутативным, идемпотентным воздействием на состояние ресурса сигналами во времени. RDP требует переосмысления моделей ресурсов и состояния.
Я хочу указать, как они отличаются с практической точки зрения:
1) актеры отправляют сообщения другим акторам, эта передача сообщений описана явно и обязательно .
Например:
send msg to Actor137,2) в FRP поток данных описывается декларативно :
Например:
Cell134=Cell185+Cell42,Передача сообщений обрабатывается платформой FRP, и вам не нужно описывать «вручную», как передавать сообщения из одной ячейки (сродни Actor, инкапсулирует состояние, иначе называемое поведение) в другую.
Другими словами:
Сущность функционального реактивного программирования , чтобы определить динамическое поведение значения полностью в момент декларации. Таким образом, все зависимости
Cell134определены в точке объявления.Это не верно для актерской модели. Актеры, влияющие на поведение актера
A, не определены в том же месте в исходном коде, где определен актерA.Недавно я заметил, что между этими двумя потоками существует интересный гибрид: потоки Akka, где поток данных описывается декларативно, но реализуется с использованием акторов.
Другое отличие: актеры, как правило, асинхронны, а FRP - синхронны (часто без сбоев ).
источник