O FRP trata de transmitir eventos e comportamentos através de funções puras. O modelo do ator - pelo menos, como implementado no Akka - é sobre o fluxo de mensagens imutáveis (que podem ser consideradas eventos discretos) através de objetos potencialmente impuros, chamados atores.
Então, na superfície, eles parecem relacionados.
O que mais podemos dizer sobre como eles se relacionam? Além disso, o que dizer sobre qual deles pode ser mais apropriado para diferentes domínios de aplicativo?
Respostas:
Nem atores nem FRP são sobre streaming. Os atores nem mesmo suportam a configuração externa de um fluxo de saída.
O FRP é fortemente caracterizado por seus sinais e eventos de modelagem em uma linha do tempo linear, o que permite que os comportamentos do FRP se componham de maneira determinística. Os atores são fortemente caracterizados pelo processamento de mensagens em ordem não determinística e têm quase nenhuma propriedade de composição (ou seja, você não pode tratar um arranjo de dois atores como um ator maior).
Se você está procurando semelhanças, os atores e o FRP têm uma relação estreita com o cálculo lambda. Ambos podem modelar sistemas sensíveis às informações humanas. Ambos suportam a modelagem do estado interno (local).
O FRP suporta o estado local por meio de integrais ou acumuladores (dobra ao longo do tempo), enquanto o modelo de atores suporta o estado, permitindo que cada ator especifique seu comportamento para a próxima mensagem em resposta à atual. Esse amplo suporte ao estado local torna o FRP e os atores inadequados para programação ao vivo (ou atualização em tempo de execução do código do programa); torna-se muito fácil perder um estado importante.
Em relação aos domínios de aplicativo:
O modelo de atores é adequado para sistemas abertos, nos quais podemos instalar ou manter atores em tempo de execução. O modelo de atores também é pouco adequado para sistemas distribuídos, pois a ordem não determinística das mensagens pode facilitar uma implementação em conformidade. (A razão pela qual os atores não se adaptam mais fortemente aos sistemas distribuídos é que garantir que uma mensagem chegue "uma vez e apenas uma vez" é bastante difícil diante de uma interrupção, e os atores também tendem a exigir GC distribuído, o que é uma dor.)
O FRP é adequado para sistemas fechados que operam ao longo do tempo - por exemplo, controladores robóticos, programação musical, brinquedos computacionais. O determinismo e os recursos de composição tornam o FRP mais conveniente para trabalhar do que os atores, pelo menos nos casos em que o FRP pode modelar diretamente uma solução. Integrar FRP com efeitos (elegantemente, sem invadir o modelo com impureza) se mostrou difícil. Tem havido trabalhos recentes sobre FRP eficaz através de 'buracos de minhoca' - efetivamente, acesso tipado exclusivo ou linear a recursos.
Existem outros modelos que se encontram em algum lugar entre o FRP e os atores.
A Programação Baseada em Fluxo (FBP), desenvolvida por John Paul Morrison, realmente suporta o fluxo de mensagens.
Os protocolos Time Warp (ou o trabalho mais recente sobre Lightweight Time Warp (LTW)) colocam mensagens semelhantes a atores em uma linha do tempo lógica para fornecer uma noção mais controlada e composicional da passagem de mensagens. Time warp é frequentemente usado para grandes sistemas paralelos e distribuídos, por exemplo, computação científica. O time warp original não era adequado para simulações interativas (capacidade de resposta às informações humanas) e o LTW é apenas marginalmente adequado.
Estou desenvolvendo RDP (Reactive Demand Programming), que permite manipulação e processamento responsivos, composicionais e semelhantes a FRP e processamento de sinais em sistemas abertos e distribuídos, além de eliminar o estado local. O RDP é alcançado restringindo os efeitos colaterais à influência comutativa e idempotente no estado do recurso por sinais ao longo do tempo. O RDP requer repensar os modelos de recursos e estados.
Quero mostrar como eles são diferentes de um ponto de vista prático:
1) os atores enviam mensagens para outros atores, essa passagem de mensagens é descrita de forma explícita e imperativa .
Por exemplo:
send msg to Actor137.
2) no FRP, o fluxo de dados é descrito declarativamente :
Por exemplo:
Cell134=Cell185+Cell42.
A passagem de mensagens é tratada pela estrutura do FRP e você não precisa descrever "manualmente" como passar mensagens de uma célula (semelhante ao Actor, encapsula o estado, também conhecido como Comportamento) para outra.
Em outras palavras:
A essência da programação reativa funcional é especificar o comportamento dinâmico de um valor completamente no momento da declaração. Portanto, todas as dependências de Cell134são definidas no ponto de declaração.
Isso não é verdade para o modelo de ator. Os atores que influenciam o comportamento de um ator Anão são definidos no mesmo local no código-fonte em que o ator Aestá definido.
Recentemente, notei que há um híbrido interessante entre os dois: fluxos Akka, onde o fluxo de dados é descrito declarativamente, mas é implementado usando atores.
Outra diferença é: os atores tendem a ser assíncronos, enquanto o FRP tende a ser síncrono (geralmente sem falhas ).