¿Qué es la programación reactiva (funcional)?

Si quieres familiarizarte con FRP, puedes comenzar con el antiguo tutorial de Fran de 1998, que tiene ilustraciones animadas. Para los artículos, comience con Animación reactiva funcional y luego siga los enlaces en el enlace de publicaciones en mi página de inicio y el enlace de FRP en la wiki de Haskell .

Personalmente, me gusta pensar en lo que significa FRP antes de abordar cómo podría implementarse. (El código sin una especificación es una respuesta sin una pregunta y, por lo tanto, "ni siquiera está mal".) Por lo tanto, no describo FRP en términos de representación/implementación como lo hace Thomas K en otra respuesta (gráficos, nodos, bordes, disparo, ejecución, etc). Hay muchos estilos de implementación posibles, pero ninguna implementación dice qué es FRP .

Resueno con la simple descripción de Laurence G de que FRP se trata de "tipos de datos que representan un valor 'a lo largo del tiempo'". La programación imperativa convencional captura estos valores dinámicos sólo indirectamente, a través de estados y mutaciones. La historia completa (pasado, presente, futuro) no tiene representación de primera clase. Además, sólo se pueden capturar (indirectamente) valores que evolucionan discretamente , ya que el paradigma imperativo es temporalmente discreto. Por el contrario, FRP captura estos valores en evolución directamente y no tiene dificultades con los valores en continua evolución.

FRP también es inusual en el sentido de que es concurrente sin entrar en conflicto con el nido de ratas teórico y pragmático que plaga la concurrencia imperativa. Semánticamente, la concurrencia de FRP es detallada , determinada y continua . (Estoy hablando de significado, no de implementación. Una implementación puede implicar o no concurrencia o paralelismo). La determinación semántica es muy importante para el razonamiento, tanto riguroso como informal. Si bien la concurrencia añade una enorme complejidad a la programación imperativa (debido al entrelazado no determinista), en FRP no supone ningún esfuerzo.

Entonces, ¿qué es FRP? Podrías haberlo inventado tú mismo. Comience con estas ideas:

• Los valores dinámicos/evolutivos (es decir, valores "a lo largo del tiempo") son valores de primera clase en sí mismos. Puede definirlos y combinarlos, pasarlos dentro y fuera de funciones. A estas cosas las llamé "comportamientos".

• Los comportamientos se construyen a partir de algunas primitivas, como comportamientos constantes (estáticos) y tiempo (como un reloj), y luego con combinaciones secuenciales y paralelas. n comportamientos se combinan aplicando una función n-aria (sobre valores estáticos), "puntualmente", es decir, de forma continua en el tiempo.

• Para dar cuenta de los fenómenos discretos, hay otro tipo (familia) de "eventos", cada uno de los cuales tiene un flujo (finito o infinito) de sucesos. Cada ocurrencia tiene un tiempo y un valor asociados.

• Para encontrar el vocabulario compositivo a partir del cual se pueden construir todos los comportamientos y eventos, juegue con algunos ejemplos. Siga deconstruyendo en partes que sean más generales/simples.

• Para que sepas que estás en terreno sólido, dale a todo el modelo una base de composición, usando la técnica de la semántica denotacional, lo que simplemente significa que (a) cada tipo tiene un correspondiente tipo matemático simple y preciso de "significados", y ( b) cada primitiva y operador tiene un significado simple y preciso en función de los significados de los constituyentes. Nunca, nunca mezcle consideraciones de implementación en su proceso de exploración. Si esta descripción le parece un galimatías, consulte (a) Diseño denotacional con morfismos de clases de tipos , (b) Programación reactiva funcional push-pull (ignorando los bits de implementación) y (c) la página de wikilibros de Haskell sobre semántica denotacional . Tenga en cuenta que la semántica denotacional tiene dos partes, según sus dos fundadores, Christopher Strachey y Dana Scott: la parte de Strachey, más fácil y útil, y la parte de Scott, más difícil y menos útil (para el diseño de software).

Si sigue estos principios, espero que obtenga algo más o menos similar al espíritu de FRP.

¿De dónde saqué estos principios? En diseño de software, siempre hago la misma pregunta: "¿qué significa?". La semántica denotacional me dio un marco preciso para esta pregunta, y uno que se ajusta a mi estética (a diferencia de la semántica operativa o axiomática, las cuales me dejan insatisfecho). Entonces me pregunté ¿qué es el comportamiento? Pronto me di cuenta de que la naturaleza temporalmente discreta del cálculo imperativo es una adaptación a un estilo particular de máquina , más que una descripción natural del comportamiento en sí. La descripción precisa más simple del comportamiento que se me ocurre es simplemente "función del tiempo (continuo)", así que ese es mi modelo. Sorprendentemente, este modelo maneja la concurrencia continua y determinista con facilidad y gracia.

Ha sido todo un desafío implementar este modelo de manera correcta y eficiente, pero esa es otra historia.

Jun 23 '2009 04:06 Conal