FRP consiste à diffuser des événements et des comportements via des fonctions pures. Le modèle Actor - du moins, tel qu'il est implémenté dans Akka - consiste à diffuser des messages immuables (qui peuvent être considérés comme des événements discrets) à travers des objets potentiellement impurs, appelés acteurs.
Donc, en surface, ils semblent liés.
Que pouvons-nous dire d'autre sur leur relation? De plus, que peut-on dire de ceux qui conviennent le mieux à différents domaines d'application?
Ni les acteurs ni le FRP ne concernent le streaming. Les acteurs ne prennent même pas en charge la configuration externe d'un flux de sortie.
FRP est fortement caractérisé par sa modélisation des signaux et des événements sur une chronologie linéaire, ce qui permet aux comportements FRP de composer de manière déterministe. Les acteurs sont fortement caractérisés par le traitement des messages dans un ordre non déterministe et n'ont pratiquement aucune propriété de composition (c'est-à-dire que vous ne pouvez pas traiter un arrangement de deux acteurs comme un acteur plus grand).
Si vous recherchez des similitudes, les acteurs et FRP ont une relation étroite avec le calcul lambda. Les deux peuvent modéliser des systèmes sensibles à l'apport humain. Les deux prennent en charge la modélisation de l'état interne (local).
FRP prend en charge l'état local via des intégrales ou des accumulateurs (repli dans le temps), tandis que le modèle d'acteurs prend en charge l'état en permettant à chaque acteur de spécifier son comportement pour le message suivant en réponse à l'actuel. Cette prise en charge omniprésente pour l'État local rend FRP et les acteurs inadéquats pour la programmation en direct (ou la mise à niveau d'exécution du code de programme); il devient trop facile de perdre un état important.
Concernant les domaines d'application:
Le modèle des acteurs est bien adapté aux systèmes ouverts, où nous pourrions souhaiter installer ou maintenir des acteurs à l'exécution. Le modèle des acteurs est également peu adapté aux systèmes distribués, car l'ordre non déterministe des messages peut faciliter une mise en œuvre conforme. (La raison pour laquelle les acteurs ne sont pas plus adaptés aux systèmes distribués est qu'il est assez difficile de garantir que le message arrive `` une seule fois '' face aux perturbations, et les acteurs ont également tendance à exiger un GC distribué, ce qui est pénible.)
FRP est bien adapté aux systèmes fermés qui fonctionnent dans le temps - par exemple, les contrôleurs robotiques, la programmation musicale, les jouets informatiques. Le déterminisme et les caractéristiques de composition rendent FRP plus pratique à utiliser que les acteurs, du moins dans les cas où FRP peut directement modéliser une solution. L'intégration de FRP avec des effets (élégamment, sans pirater le modèle avec une impureté) s'est avérée difficile. Il y a eu des travaux récents sur la FRP efficace via des «trous de ver» - un accès typiquement efficace, unique ou linéaire aux ressources.
Il existe d'autres modèles qui se situent quelque part entre le FRP et les acteurs.
La programmation basée sur les flux (FBP), développée par John Paul Morrison, prend vraiment en charge le streaming de messages.
Les protocoles Time Warp (ou les travaux plus récents sur Lightweight Time Warp (LTW)) placent les messages de type acteurs sur une chronologie logique pour fournir une notion plus contrôlée et plus compositionnelle de la transmission des messages. La déformation temporelle est souvent utilisée pour les grands systèmes parallèles et distribués, par exemple le calcul scientifique. La distorsion temporelle d'origine n'était pas adaptée aux simulations interactives (réactivité aux entrées humaines), et LTW n'est que marginalement adapté.
Je développe la programmation réactive à la demande (RDP) qui permet une manipulation et un traitement réactifs, de type FRP, de signaux dans des systèmes ouverts et distribués, et élimine l'état local. Le RDP est obtenu en limitant les effets secondaires à l'influence commutative et idempotente sur l'état des ressources par les signaux au fil du temps. RDP nécessite de repenser les modèles de ressources et d'état.
Je veux souligner en quoi ils diffèrent d'un point de vue pratique:
1) les acteurs envoient des messages à d'autres acteurs, ce passage de message est décrit de manière explicite et impérative .
Par exemple:
send msg to Actor137.2) dans FRP, le flux de données est décrit de manière déclarative :
Par exemple:
Cell134=Cell185+Cell42.Le passage de message est géré par le framework FRP et vous n'avez pas à décrire "manuellement" comment passer des messages d'une cellule (semblable à Actor, encapsule l'état, alias Comportement) à une autre.
En d'autres termes:
L'essence de la programmation réactive fonctionnelle est de spécifier complètement le comportement dynamique d'une valeur au moment de la déclaration. Ainsi, toutes les dépendances de
Cell134sont définies au point de déclaration.Ce n'est pas vrai pour le modèle d'acteur. Les acteurs qui influencent le comportement d'un acteur
Ane sont pas définis au même endroit dans le code source où l'acteurAest défini.Récemment, j'ai remarqué qu'il existe un hybride intéressant entre les deux: les flux Akka, où le flux de données est décrit de manière déclarative mais est mis en œuvre à l'aide d'acteurs.
Une autre différence est: les acteurs ont tendance à être asynchrones tandis que FRP a tendance à être synchrone (souvent sans pépin ).
la source