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?
Odpowiedzi:
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.
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 ).