Como a Programação Reativa Funcional e o modelo do Ator se relacionam?

30

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?

Robin Green
fonte

Respostas:

26

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.

dmbarbour
fonte
Uma coisa que não me agrada com o FRP é que o mapeamento de uma função em um evento leva um tempo finito, mas o FRP considerará que o evento resultante aconteceu ao mesmo tempo que o evento original. Isso pode fazer com que a noção interna de tempo do FRP fique fora de sintonia com o tempo de parede e, em particular, pode causar a ordenação incorreta de eventos em relação ao tempo de parede. Também não gosto da ficção de que o evento B pode acontecer após o evento A, mas no mesmo tempo registrado internamente que o evento A.
Robin Green
1
@RobinGreen A capacidade de modelar progressão 'instantânea' ou transformação de eventos é bastante útil. Os desenvolvedores são livres para compensar o atraso de modelagem no upstream ou no downstream. Com tipos dependentes ou lineares, poderia-se desenvolver uma noção de segurança no tempo (propriedades em tempo real; alocação de latência como recurso) para sistemas de FRP que seriam difíceis de modelar em sistemas atemporais.
precisa saber é o seguinte
@RobinGreen - em relação à "ficção de que o evento B pode acontecer após o evento A, mas ao mesmo tempo registrado", a noção de eventos ocorrendo em tempo instantâneo ou transcendental (lim (x-> 0 +) (T + x)) é uma das falácias universais da abstração do "evento". A ordem dos eventos ao duplicar, dividir e mesclar fluxos de eventos se torna arbitrária, inconsistente e perde facilmente informações temporais. (cf. Why Not Events )
dmbarbour
Você está transformando seu projeto RDP no projeto Awelon?
CMCDragonkai
1
O projeto Awelon fará uso pesado do modelo / paradigma RDP. Pense no RDP de maneira semelhante ao OOP. Um modelo de programação tem implicações na arquitetura e no design da linguagem, mas não é algo que eu chamaria de 'projeto'.
Dmbarbour
7

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 ).

jhegedus
fonte