FRP riguarda eventi e comportamenti in streaming attraverso funzioni pure. Il modello Actor - almeno, come implementato in Akka - riguarda lo streaming di messaggi immutabili (che possono essere considerati eventi discreti) attraverso oggetti potenzialmente impuri, chiamati attori.
Quindi in superficie sembrano collegati.
Cos'altro possiamo dire su come si relazionavano? Inoltre, cosa si può dire su quale di essi potrebbe essere più appropriato per domini applicativi diversi?
Risposte:
Né attori né FRP riguardano lo streaming. Gli attori non supportano nemmeno la configurazione esterna di un flusso di output.
FRP è fortemente caratterizzato dai suoi segnali di modellazione ed eventi su una linea temporale lineare, che consente ai comportamenti FRP di comporre in modo deterministico. Gli attori sono fortemente caratterizzati dall'elaborazione di messaggi in ordine non deterministico e hanno a malapena proprietà compositive (cioè non è possibile trattare un arrangiamento di due attori come un attore più grande).
Se stai cercando somiglianze, sia gli attori che il FRP hanno una stretta relazione con il calcolo lambda. Entrambi possono modellare sistemi che rispondono all'input umano. Entrambi supportano la modellazione dello stato interno (locale).
FRP supporta lo stato locale attraverso integrali o accumulatori (fold nel tempo), mentre il modello degli attori supporta lo stato consentendo a ciascun attore di specificare il suo comportamento per il messaggio successivo in risposta a quello corrente. Questo supporto pervasivo per lo stato locale rende sia FRP che Actors inadeguati per la programmazione live (o l'aggiornamento di runtime del codice del programma); diventa troppo facile perdere lo stato importante.
Per quanto riguarda i domini dell'applicazione:
Il modello Actors è adatto per sistemi aperti, dove potremmo voler installare o mantenere attori in fase di esecuzione. Il modello degli attori è anche debolmente adatto ai sistemi distribuiti, poiché l'ordinamento non deterministico dei messaggi può facilitare un'implementazione conforme. (La ragione per cui gli attori non sono più adatti ai sistemi distribuiti è che garantire che un messaggio arrivi "una volta e una volta sola" è piuttosto difficile di fronte a un'interruzione, e gli attori tendono anche a richiedere GC distribuiti, il che è un dolore.)
FRP è adatto a sistemi chiusi che funzionano nel tempo, ad esempio controller robotici, programmazione musicale, giocattoli computazionali. Il determinismo e le caratteristiche compositive rendono FRP più comodo da lavorare rispetto agli attori, almeno nei casi in cui FRP può modellare direttamente una soluzione. Integrare FRP con effetti (elegantemente, senza compromettere il modello con impurità) si è rivelato difficile. Ci sono stati lavori recenti su FRP efficaci tramite 'wormholes' - accesso alle risorse efficace, unico o lineare.
Ci sono altri modelli che si trovano da qualche parte tra FRP e attori.
Flow Based Programming (FBP), sviluppato da John Paul Morrison, supporta davvero lo streaming di messaggi.
I protocolli Time Warp (o il lavoro più recente su Lightweight Time Warp (LTW)) collocano i messaggi simili agli attori su una sequenza temporale logica per fornire una nozione più controllata e compositiva del passaggio dei messaggi. La distorsione temporale viene spesso utilizzata per grandi sistemi paralleli e distribuiti, ad esempio informatica scientifica. La distorsione temporale originale non era adatta per simulatoni interattivi (reattività all'input umano) e LTW è adatto solo marginalmente.
Sto sviluppando la Reactive Demand Programming (RDP) che consente la manipolazione e l'elaborazione reattiva, compositiva, simile a quella del FRP, dei segnali in sistemi aperti e distribuiti ed elimina lo stato locale. Il PSR si ottiene vincolando gli effetti collaterali all'influenza commutativa e idempotente sullo stato delle risorse mediante segnali nel tempo. RDP richiede un ripensamento dei modelli di risorse e di stato.
Voglio sottolineare come sono diverse da un punto di vista pratico:
1) gli attori inviano messaggi ad altri attori, questo passaggio di messaggi è descritto in modo esplicito e imperativo .
Per esempio:
send msg to Actor137.
2) in FRP il flusso di dati è descritto in modo dichiarativo :
Per esempio:
Cell134=Cell185+Cell42.
Il passaggio dei messaggi è gestito dal framework FRP e non è necessario descrivere "manualmente" come passare i messaggi da una cella (affine ad Attore, incapsula lo stato, noto anche come Comportamento) ad un'altra.
In altre parole:
L'essenza della programmazione reattivo funzionale è per specificare il comportamento dinamico di un valore completamente al momento della dichiarazione. Quindi tutte le dipendenze di Cell134sono definite al punto di dichiarazione.
Questo non è vero per il modello dell'attore. Gli attori che influenzano il comportamento di un attore Anon sono definiti nello stesso posto nel codice sorgente in cui Aè definito l'attore .
Di recente ho notato che esiste un ibrido interessante tra i due: flussi Akka, in cui il flusso di dati è descritto in modo dichiarativo ma è implementato usando attori.
Un'altra differenza è: gli attori tendono ad essere asincroni mentre FRP tende ad essere sincrono (spesso privo di difetti ).