FRP - це передача подій та поведінки через чисті функції. Модель Actor - принаймні, як це реалізовано в Akka - стосується потокової передачі незмінних повідомлень (які можна вважати дискретними подіями) через потенційно нечисті об'єкти, звані акторами.
Тож на поверхні вони здаються спорідненими.
Що ще можна сказати про те, як вони пов’язані? Крім того, що може сказати про те, який з них може бути більш підходящим для різних областей додатків?
Відповіді:
Ні актори, ні FRP не збираються в ефірі. Актори навіть не підтримують зовнішню конфігурацію вихідного потоку.
FRP сильно характеризується своїми моделюючими сигналами та подіями на лінійній часовій шкалі, що дозволяє поведінці FRP складати детерміновано. Актори сильно характеризуються тим, що вони обробляють повідомлення в недетермінованому порядку і мають ледве будь-які композиційні властивості (тобто ви не можете ставитися до аранжування двох акторів як до більшого актора).
Якщо ви шукаєте подібності, і актори, і FRP мають тісний зв’язок з обчисленням лямбда. Обидва можуть моделювати системи, що реагують на вклад людини. Обидва підтримують моделювання внутрішнього (локального) стану.
FRP підтримує локальний стан за допомогою інтегралів або акумуляторів (згортання у часі), тоді як модель акторів підтримує стан, дозволяючи кожному актору вказати свою поведінку для наступного повідомлення у відповідь на поточне. Ця поширена підтримка місцевого штату робить як FRP, так і акторів неадекватними для прямого програмування (або оновлення програмного коду під час виконання); втрачати важливий стан стає занадто просто.
Щодо доменів додатків:
Модель акторів добре підходить для відкритих систем, де ми могли б бажати встановлювати або підтримувати акторів під час виконання. Модель акторів також слабо підходить до розподілених систем, оскільки недетермінований упорядкування повідомлень може полегшити відповідну реалізацію. (Причина, з якою актори не сильніше підходять до розподілених систем, полягає в тому, що забезпечити повідомлення надходить "один раз і лише один раз" досить важко в умовах розладу, а також актори також вимагають розподілення GC, що є болем.)
FRP добре підходить для закритих систем, які працюють з часом - наприклад, роботизованих контролерів, музичного програмування, обчислювальних іграшок. Детермінізм та композиційні особливості роблять FRP зручніше працювати, ніж акторів, принаймні в тих випадках, коли FRP може безпосередньо моделювати рішення. Інтегрувати FRP з ефектами (елегантно, без злому моделі з домішками) виявилося складно. Нещодавно була проведена робота над ефективним FRP через «черв’ячні отвори» - ефективний, унікальний або лінійний набір доступу до ресурсів.
Є й інші моделі, які лежать десь між FRP та Actors.
Потокове програмування (FBP), розроблене Джоном Полом Моррісоном, справді підтримує потокове передавання повідомлень.
Протоколи Time Warp (або новіша робота над Lightweight Time Warp (LTW)) розміщує повідомлення, подібні акторам, на логічну шкалу часу, щоб забезпечити більш контрольоване та композиційне поняття проходження повідомлень. Частотну основу часто використовують для великих паралельних і розподілених систем, наприклад, для наукових обчислень. Початковий деформатор часу був непридатний для інтерактивних симуляторів (чутливість до вступу людини), а LTW - лише незначно.
Я розвиваю програмування реактивного попиту (RDP), що дозволяє реагувати на реакцію, композиційну, FRP-подібну маніпуляцію та обробку сигналів у відкритих та розподілених системах, а також усуває місцевий стан. RDP досягається обмеженням побічних ефектів до комутативного, безсильного впливу на стан ресурсу сигналами з часом. RDP вимагає переосмислення ресурсних та державних моделей.
Я хочу зазначити, чим вони відрізняються з практичної точки зору:
1) актори надсилають повідомлення іншим суб'єктам, проходження цього повідомлення описується чітко і обов'язково .
Наприклад:
send msg to Actor137.
2) у FRP потік даних описується декларативно :
Наприклад:
Cell134=Cell185+Cell42.
Передача повідомлень обробляється рамкою FRP, і вам не доведеться "вручну" описувати, як передавати повідомлення з однієї комірки (схожої на Actor, інкапсулює стан, він же "Поведінка") в іншу.
Іншими словами:
Суть функціонального реактивного програмування , щоб визначити динамічну поведінку значення повністю в момент декларації. Отже всі залежності Cell134визначені в точці декларування.
Це не вірно для акторської моделі. Актори, що впливають на поведінку актора A, не визначаються там же, у вихідному коді, де визначено актора A.
Нещодавно я помітив, що між цими двома потоками є цікавий гібрид: потоки Akka, де потік даних описується декларативно, але реалізується за допомогою акторів.
Ще одна відмінність: Актори, як правило, асинхронізуються, тоді як FRP має тенденцію бути синхронним (часто без збоїв ).