Reactive Programming Study
I am concerned that the idea behind reactive programming is great, but I may end up dismissing it. After the fran tutorial internet is being bombarded by slew of FRP oriented frameworks. Most of them disregard what they're supposed to solve and present FRP as an all-useful paradigm.
Today I wrote a series of interactive apps:
mousedrag.py: A basic dragging behavior. During the drag it draws a line, which then remains on the screen until the next mouse press.buttons.py: Builds up bunch of on-screen buttons that match to the keyboard keys. A character is moved whenever keys are pressed.rocket.py: When mouse button is pressed, a rocket is spawned, which then explodes with an animation when it gets near enough at the mouse cursor.robot.py: When mouse button is pressed, it produces an explosion that damages the robot. Robot contains a finite state machine, consisting of states such as: "flee", "chase", "heal". Specifically, robot is attacking the mouse cursor. If its health declines then it starts to flee to a distance so it can stop for a moment and heal itself. Once it recovers it comes to attack again. The robot can be destroyed by explosions.boids.py: Robots following bunch of steering behaviors. Basically the Boids algorithm.
These are the references that I've quickly implemented in pygame without reactive programming elements. The last three programs are derived from the earlier programs. Each program takes the simplest way to do what is required, therefore if I wanted to compose them together, it'd take some effort. They're all more or less animated interactive programs.
Next I'm trying to implement a reactive programming library which makes it easier to describe the above programs and compose them together with little or no effort. I suppose if there's any advantage in reactive programming, it should appear in these programs. I will likely read the Fran paper carefully before proceeding with this.
I'm doing this because I first tried to study reactive programming as an idea or paradigm. I realised that kind of approach mystifies the whole thing. Both the Elm programming language and the paper "Deprecating the Observer Pattern" contributes to the problem by forcing upon the concept. Some of the samples that are gibberish in Elm would form fairly acceptable imperative programs. In the another paper, the observer-formed mouse dragging code is clean aside the reactive programming counterpart. It doesn't exactly seem like a sign that this would be the next big programming that obsoletes most of the everything else.