Comparaison de la programmation réactive fonctionnelle et core.async (+ Rx)

Question

Je semble un peu confus lorsque l'on compare les Clojure du noyau.async les Reactive Extensions (Rx) et de PRF en général. Ils semblent s'attaquer à des problèmes similaires de async-hronicity, alors je me demande quelles sont les principales différences et dans quels cas est un privilégié par rapport à l'autre. Quelqu'un peut-il expliquer?

EDIT: afin D'encourager plus en profondeur les réponses que je veux faire de la question plus spécifique:

1. De base.async me permet d'écrire synchrone à la recherche de code. Cependant, comme je le comprends DP besoin que d'un seul niveau d'imbrication des rappels (toutes les fonctions qui traitent de la logique sont passés comme arguments de l'appel d'offres de l'API). Ceci semble que les deux approches de faire le rappel des pyramides inutiles. Il est vrai qu'en JS, je dois l'écrire function() {...} de nombreuses fois, mais le principal problème, le imbriquée rappels, est allé dans le PRF. Puis-je l'obtenir?

2. "[FRP] complects la communication des messages avec le flux de contrôle" Pouvez-vous (quelqu'un) veuillez donner des explications plus précises?

3. Je ne peux pas me passer autour de PRF observables points de terminaison de la même façon que je passe canaux?

Dans generel je comprends d'où les deux approches historiquement venir, et j'ai essayé quelques tutoriels en deux. Cependant il me semble être "paralysé" par la non-évidence de différences. Est-il un exemple de code qui serait difficile à écrire dans l'un de ces et facile à l'aide de l'autre? Et qu'est-ce que l'architecture de la raison de cela?

Answer 1

Je pense que principal problème, c'est votre hypothèse sur le problème abordé ne sont pas assez, car aucun d'entre eux sont la lutte contre l' asynchronicité "problème".

Les abstractions

FRP idée principale est de propagation du changement, pensez à accomplir la même chose, Excel, lorsque vous définissez des cellules en fonction les uns des autres dans une cascade, et quand on les modifications de cellules, toutes les cellules dépendantes sur la cascade sont recalculées.

core.async idée principale est les systèmes de décomposition, de penser que la séparation des préoccupations à l'aide d'un queue au moyen de différents procédés, en core.async des cas au lieu de files d'attente que vous avez canaux, mais vous obtenez l'idée.

Ainsi, le retrait de la pyramidaux code n'est pas l'objectif de la technologie, et ils agissent sur différentes couches d'abstraction.

Sur complecting flux de contrôle

L'idée de complecting de la communication et le contrôle de flux est prise à partir de la carotte d'origine asynchrone post.

Bien qu'il existe divers mécanismes pour faire les événements/rappels de produit de nettoyage (PRF, Rx/Observables), ils ne changent pas leur nature fondamentale, qui est que lors d'un événement, d'une quantité arbitraire de code est exécuté, peut-être sur le même thread, conduisant à des injonctions telles que "ne pas faire trop de travail de votre gestionnaire", et des phrases comme "le rappel de l'enfer".

Reformuler, si vous avez des affaires de domaine de code à l'intérieur d'un gestionnaire d'événement, vous avez complected le X de traitement des événements avec la que faire lorsque X se produit.

Qui est ce qui core.async cordages, depuis l'adoption d'une file d'attente/canal dans le milieu, contribue à une meilleure séparation des préoccupations.

La mise en œuvre

Toutes vos questions concernant les rappels et en passant observable des paramètres de mesure des paramètres sont juste des questions de mise en œuvre, cela dépend vraiment de l' Rx de la mise en œuvre et de l'API.

Si vous regardez Réagir de composants réutilisables que vous n'avez vraiment pas beaucoup d'un rappel à l'enfer d'être vu, et vous obtenez cette idée de transmission observables autour de.

Réflexions finales

Même si Rx peut être utilisé pour modéliser n'importe quel flux de données, est plus couramment utilisé pour l' INTERFACE de Rendu de la Excel, afin de simplifier la façon dont vous mettez à jour votre point de vue lors de vos changements de modèle.

D'autre part, Core.Async peut être utilisé pour le modèle de la séparation des préoccupations lorsque deux sous-systèmes de communiquer les uns avec les autres (même scénario d'utilisation que les files d'attente), en l'utilisant sur l'INTERFACE de rendu de la chaîne principale idée est de séparer:

• Côté serveur de génération d'événements et de traitement
• Comment cet événement affecte votre modèle

Vous pouvez donc avoir core.async et FRP ensemble, depuis core.async sera préoccupations distinctes, et FRP permettra de définir votre en cascade des flux de données, une fois que votre modèle est mis à jour.

Answer 2

Au moins l'une des principales différences principales, et, je pense, ce Riche ment par "[FRP] complects la communication des messages avec le flux de contrôle", est la suivante.

Les rappels sont code qui est exécuté. Et que l'exécution doit se faire dans un thread à un certain point dans le temps. Souvent, le temps est lorsque l'événement se produit, et le fil est le fil qui avis/produit l'événement. Si le producteur au lieu de mettre un message sur un canal, vous êtes libre de consommer le message quand vous voulez, en quel que soit le sujet que vous voulez. Des rappels, qui sont essentiellement une forme de communication, complect la communication avec les flux de contrôle en dictant quand et où le rappel de code est exécuté. Si vous utilisez des rappels pour quelque raison que ce soit, juste de les utiliser pour mettre un message dans une file d'attente/canal et vous êtes de retour sur la bonne voie.

Parce que de base.async est moins complexe, il doit être préféré, tant qu'il n'est pas une bonne raison pour utiliser les solutions de rechange.

Answer 3

Clojure de base.async est un port de go pâtés de maisons du langage Go. Le concept fondamental est canaux représentant de communication asynchrone entre les threads.

L'objectif est d'être capable d'écrire de la normale à la recherche de blocs de code séquentiel que les canaux d'accès pour obtenir de l'entrée, et c'est parfaitement traduit dans une machine d'état qui fonctionne le CSP traduction pour vous.

Contrairement à la fibre de verre, qui est encore fondamentalement à propos des rappels, et il complects la communication de messages avec le flux de contrôle. de base.async élimine les rappels à partir de votre code entièrement, et sépare le flux de contrôle de la transmission du message. Aussi, dans PRF un canal n'est pas une première classe de l'objet (ie. vous ne pouvez pas envoyer de PRF canal comme une valeur sur un PRF canal).

Answer 4

EDIT:

Pour répondre à vos questions:

1. Oui, de nombreuses fois, les rappels peuvent être éliminés, par exemple avec la logique de nouvelle tentative, distinctUntilChanged et beaucoup d'autres choses telles que:

   var obs = getJSON ("de l'histoire.json').retry(3);

   var obs = Rx.Observables.fromEvent(document, 'keyup').distinctUntilChanged();

2. Je ne suis pas sûr de ce qui se réfère à la rendant plus complexe avec le contrôle de flux.

3. Oui, vous pouvez passer autour d'un objet comme vous le feriez d'un canal, avec le dessous de l'objet.

Par exemple, vous pouvez avoir canal comme le comportement ici à l'aide de RxJS avec un ReplaySubject:

var channel = new Rx.ReplaySubject();

// Send three observables down the chain to subscribe to
channel.onNext(Rx.Observable.timer(0, 250).map(function () { return 1; }));
channel.onNext(Rx.Observable.timer(0, 1000).map(function () { return 2; }));
channel.onNext(Rx.Observable.timer(0, 1500).map(function () { return 3; }));

// Now pass the channel around anywhere!
processChannel(channel);

Pour rendre les choses un peu plus concrètes, de comparer le code de David Nolen post ici avec un RxJS PRF exemple ici