FRP se trata de transmitir eventos y comportamientos a través de funciones puras. El modelo de actor, al menos, tal como se implementa en Akka, se trata de transmitir mensajes inmutables (que pueden considerarse eventos discretos) a través de objetos potencialmente impuros, llamados actores.
Así que en la superficie parecen relacionados.
¿Qué más podemos decir sobre cómo se relacionan? Además, ¿qué puede decir sobre cuál de ellos podría ser más apropiado para diferentes dominios de aplicación?
Respuestas:
Ni los actores ni FRP tratan sobre streaming. Los actores ni siquiera admiten la configuración externa de una secuencia de salida.
FRP se caracteriza fuertemente por sus señales y eventos de modelado en una línea de tiempo lineal, lo que permite que los comportamientos de FRP se compongan de manera determinista. Los actores se caracterizan fuertemente por procesar mensajes en un orden no determinista y apenas tienen propiedades de composición (es decir, no se puede tratar una disposición de dos actores como un actor más grande).
Si busca similitudes, ambos actores y FRP tienen una relación cercana con el cálculo lambda. Ambos pueden modelar sistemas que respondan a las aportaciones humanas. Ambos admiten el modelado del estado interno (local).
FRP admite el estado local a través de integrales o acumuladores (plegado en el tiempo), mientras que el modelo de actores admite el estado al permitir que cada actor especifique su comportamiento para el siguiente mensaje en respuesta al actual. Este soporte generalizado para el estado local hace que tanto FRP como Actors sean inadecuados para la programación en vivo (o la actualización en tiempo de ejecución del código del programa); se vuelve demasiado fácil perder un estado importante.
En cuanto a los dominios de aplicación:
El modelo de actores es muy adecuado para sistemas abiertos, donde podríamos instalar o mantener actores en tiempo de ejecución. El modelo de actores también se adapta débilmente a los sistemas distribuidos, ya que el orden no determinista de los mensajes puede facilitar una implementación conforme. (La razón por la cual los actores no son más adecuados para los sistemas distribuidos es porque asegurar que un mensaje llegue 'una y solo una vez' es bastante difícil frente a la interrupción, y los actores también tienden a requerir GC distribuido, lo cual es una molestia).
FRP es muy adecuado para sistemas cerrados que funcionan con el tiempo, por ejemplo, controladores robóticos, programación musical, juguetes computacionales. El determinismo y las características de composición hacen que trabajar con FRP sea más conveniente que los actores, al menos en los casos en que FRP puede modelar directamente una solución. Integrar FRP con efectos (elegantemente, sin hackear el modelo con impureza) ha resultado difícil. Ha habido un trabajo reciente sobre FRP eficaz a través de 'agujeros de gusano': acceso de tipo efectivo, único o lineal a los recursos.
Hay otros modelos que se encuentran en algún lugar entre FRP y Actors.
La programación basada en flujo (FBP), desarrollada por John Paul Morrison, realmente admite la transmisión de mensajes.
Los protocolos de Time Warp (o el trabajo más reciente sobre Lightweight Time Warp (LTW)) coloca los mensajes de actores en una línea de tiempo lógica para proporcionar una noción más controlada y compositiva del paso de mensajes. Time warp se usa a menudo para grandes sistemas paralelos y distribuidos, por ejemplo, computación científica. La distorsión de tiempo original no era adecuada para simulaciones interactivas (capacidad de respuesta al aporte humano), y LTW solo es marginalmente adecuado.
Estoy desarrollando la Programación de demanda reactiva (RDP) que permite la manipulación y el procesamiento receptivo, compositivo, similar a FRP de señales en sistemas abiertos y distribuidos, y elimina el estado local. El PDR se logra al restringir los efectos secundarios a la influencia conmutativa e idempotente en el estado de los recursos mediante señales a lo largo del tiempo. RDP requiere repensar los modelos de recursos y de estado.
Quiero señalar cómo son diferentes desde un punto de vista práctico:
1) los actores envían mensajes a otros actores, este paso del mensaje se describe de manera explícita e imperativa .
Por ejemplo:
send msg to Actor137.
2) en FRP el flujo de datos se describe de manera declarativa :
Por ejemplo:
Cell134=Cell185+Cell42.
El marco de FRP maneja el paso de mensajes y no tiene que describir "manualmente" cómo pasar mensajes de una celda (similar a Actor, encapsula el estado, también conocido como Comportamiento) a otra.
En otras palabras:
La esencia de la programación reactiva funcional es especificar el comportamiento dinámico de un valor completamente al momento de la declaración. Por lo tanto, todas las dependencias de Cell134se definen en el punto de declaración.
Esto no es cierto para el modelo de actor. Los actores que influyen en el comportamiento de un actor Ano se definen en el mismo lugar en el código fuente donde Ase define el actor .
Recientemente noté que hay un híbrido interesante entre los dos: las secuencias de Akka, donde el flujo de datos se describe de manera declarativa pero se implementa utilizando actores.
Otra diferencia es: los actores tienden a ser asíncronos, mientras que FRP tiende a ser sincrónico (a menudo sin fallas ).