Jak funkcjonalne programowanie reaktywne i model aktora odnoszą się do siebie?

30

FRP dotyczy przesyłania strumieniowego zdarzeń i zachowań za pomocą czystych funkcji. Model aktora - przynajmniej taki, jak zaimplementowany w Akce - dotyczy przesyłania strumieniowego niezmiennych komunikatów (które można uznać za zdarzenia dyskretne) przez potencjalnie nieczyste obiekty, zwane aktorami.

Na pozór wydają się spokrewnione.

Co jeszcze możemy powiedzieć o ich związku? Co też można powiedzieć o tym, który z nich może być bardziej odpowiedni dla różnych domen aplikacji?

Robin Green
źródło

Odpowiedzi:

26

Ani aktorzy, ani FRP nie chcą streamować. Aktorzy nie obsługują nawet zewnętrznej konfiguracji strumienia wyjściowego.

FRP silnie charakteryzuje się sygnałami i zdarzeniami modelującymi na liniowej osi czasu, co umożliwia komparację zachowań FRP w sposób deterministyczny. Aktorzy są silnie scharakteryzowani przez przetwarzanie komunikatów w niedeterministycznej kolejności i mają prawie żadne właściwości kompozycyjne (tzn. Nie można traktować układu dwóch aktorów jako większego aktora).

Jeśli szukasz podobieństw, zarówno aktorzy, jak i FRP mają bliski związek z rachunkiem lambda. Oba mogą modelować systemy reagujące na wkład człowieka. Oba obsługują modelowanie stanu wewnętrznego (lokalnego).

FRP obsługuje stan lokalny poprzez całki lub akumulatory (krotnie w czasie), podczas gdy model aktorów obsługuje stan, umożliwiając każdemu aktorowi określenie swojego zachowania dla następnego komunikatu w odpowiedzi na bieżący. Ta wszechobecna obsługa stanu lokalnego sprawia, że ​​zarówno FRP, jak i Aktorzy nie są odpowiednie do programowania na żywo (lub aktualizacji kodu programu w czasie wykonywania); zbyt łatwo jest stracić ważny stan.

W odniesieniu do domen aplikacji:

Model aktorów doskonale nadaje się do otwartych systemów, w których możemy chcieć zainstalować lub utrzymywać aktorów w czasie wykonywania. Model aktorów jest również słabo dostosowany do systemów rozproszonych, ponieważ niedeterministyczne porządkowanie komunikatów może ułatwić implementację zgodną. (Powodem, dla którego aktorzy nie są bardziej przystosowani do systemów rozproszonych, jest to, że zapewnienie wiadomości przychodzącej „raz i tylko raz” jest dość trudne w obliczu zakłóceń, a aktorzy również często wymagają rozproszonej GC, co jest uciążliwe).

FRP jest dobrze dostosowany do zamkniętych systemów, które działają w czasie - np. Kontrolery robotów, programowanie muzyki, zabawki obliczeniowe. Determinizm i cechy kompozycyjne sprawiają, że FRP jest wygodniejszy w pracy niż aktorzy, przynajmniej w tych przypadkach, w których FRP może bezpośrednio modelować rozwiązanie. Integracja FRP z efektami (elegancko, bez hakowania modelu nieczystością) okazała się trudna. Niedawno pracowano nad skutecznym FRP poprzez „tunele czasoprzestrzenne” - efektywny, unikalny lub liniowy dostęp do zasobów.

Istnieją inne modele, które leżą gdzieś między FRP a aktorami.

Programowanie oparte na przepływie (FBP), opracowane przez Johna Paula Morrisona, naprawdę obsługuje przesyłanie strumieniowe wiadomości.

Protokoły Time Warp (lub nowsze prace nad Lightweight Time Warp (LTW)) umieszczają wiadomości podobne do aktorów na logicznej osi czasu, aby zapewnić bardziej kontrolowane i kompozycyjne pojęcie przekazywania wiadomości. Dopasowanie czasu jest często stosowane w dużych systemach równoległych i rozproszonych, np. W obliczeniach naukowych. Pierwotne dopasowanie czasowe nie było odpowiednie dla interaktywnych symulacji (reagowanie na wkład człowieka), a LTW jest tylko nieznacznie odpowiedni.

Zajmuję się programowaniem Reactive Demand Programming (RDP), które umożliwia responsywną, kompozycyjną, podobną do FRP manipulację i przetwarzanie sygnałów w systemach otwartych i rozproszonych oraz eliminuje stan lokalny. RDP osiąga się poprzez ograniczenie efektów ubocznych do przemiennego, idempotentnego wpływu na stan zasobów za pomocą sygnałów w czasie. RDP wymaga ponownego przemyślenia modeli zasobów i stanów.

dmbarbour
źródło
Jedną z rzeczy, z których nie jestem zadowolony z FRP, jest to, że mapowanie funkcji na zdarzenie zajmuje skończoną ilość czasu, jednak FRP uzna, że ​​powstałe zdarzenie miało miejsce w tym samym czasie, co pierwotne zdarzenie. Może to doprowadzić wewnętrzne pojęcie FRP do przekroczenia czasu ściany, a w szczególności może spowodować błędne uporządkowanie zdarzeń w stosunku do czasu ściany. Nie podoba mi się również fikcja, że ​​zdarzenie B może się zdarzyć po zdarzeniu A, ale w tym samym wewnętrznie zarejestrowanym czasie, co zdarzenie A.
Robin Green
1
@RobinGreen Zdolność modelowania „natychmiastowej” progresji lub transformacji zdarzeń jest bardzo przydatna. Deweloperzy mogą swobodnie kompensować opóźnienie modelowania w górę lub w dół. W przypadku typów zależnych lub liniowych można opracować pojęcie bezpieczeństwa czasowego (właściwości w czasie rzeczywistym; alokacja opóźnienia jako zasobu) dla systemów FRP, które byłyby trudne do modelowania w systemach przedporodowych.
dmbarbour
@RobinGreen - w odniesieniu do „fikcji, że zdarzenie B może nastąpić po zdarzeniu A, ale w tym samym zarejestrowanym czasie”, pojęcie zdarzeń zachodzących w czasie natychmiastowym lub transcendentalnym (lim (x-> 0 +) (T + x)) jest jeden z powszechnych błędów abstrakcji „zdarzenia”. Porządkowanie zdarzeń podczas powielania, dzielenia i łączenia strumieni zdarzeń staje się arbitralne, niespójne, łatwo traci informacje czasowe. (por. Dlaczego nie wydarzenia )
dmbarbour
Czy przekształcasz swój projekt RDP w projekt Awelon?
CMCDragonkai
1
Projekt Awelon będzie intensywnie wykorzystywać model / paradygmat RDP. Pomyśl o PROW w sposób podobny do OOP. Model programowania ma wpływ na architekturę i projektowanie języka, ale nie nazwałbym go „projektem”.
dmbarbour
7

Chcę wskazać, czym różnią się od praktycznego punktu widzenia:

1) aktorzy wysyłają wiadomości do innych aktorów, przekazywanie wiadomości jest opisane wyraźnie i bezwzględnie .

Na przykład:

send msg to Actor137.

2) we FRP przepływ danych jest opisany deklaratywnie :

Na przykład:

Cell134=Cell185+Cell42.

Przekazywanie wiadomości jest obsługiwane przez frameworki FRP i nie trzeba opisywać „ręcznie”, jak przekazywać wiadomości z jednej komórki (podobnie jak aktor, enkapsuluje stan, czyli zachowanie) do drugiej.

Innymi słowy:

Istotą funkcjonalnego programowania reaktywnego jest całkowite określenie dynamicznego zachowania wartości w momencie deklaracji. Więc wszystkie zależności Cell134są zdefiniowane w punkcie deklaracji.

To nie jest prawdą dla modelu aktorem. Aktorzy wpływający na zachowanie aktora Anie są zdefiniowani w tym samym miejscu w kodzie źródłowym, w którym aktor Ajest zdefiniowany.

Ostatnio zauważyłem, że istnieje ciekawa hybryda między nimi: strumienie Akka, w których przepływ danych jest opisany deklaratywnie, ale jest realizowany za pomocą aktorów.

Inna różnica polega na tym, że aktorzy mają tendencję do asynchronizacji, a FRP mają tendencję do synchronizacji (często bez usterki ).

Jhegedus
źródło