Above is a talk I gave at cyber.wizard.institute (start around 2:20).

The code to accompany this talk, and below explanation, are here

five-second introduction to FRP

There are many ways of thinking about how asynchronous programs fit together. Streams are one way of composing asynchronous programs.

Varibales in a program change over time. Imagine each value a given variable takes throughout the course of a program. We can place these values on a timeline, with an x representing each time the value changed:

--x--x-----xx---x-x-

If values of a variables are events on a timeline (x's), then a stream is the timeline itself.

(Still confused? Ok. Streams are like a TV channel. In some sense, TV channels are just the images that come over them; however, the idea of a channel can be a useful tool for reasoning about the images).

Streams tie events together - they create a temporal relationship between events. We can turn events into actions by transforming the events as they travel through the stream (e.g., from a click into a POST request; from a POST request into an element on the HTML page).

If you think about it, the state of a software interface is a function of the events (users' mashing buttons, data coming in from server) that happen over time. By describing streams of these events, where we transform these events into outcomes ("side-effects"), we can write interfaces in a more declarative style, where everything our interface does has a clear, causal relationship to something that happened during the application lifecycle.

a note on terms

FRP (functional-reactive programming) seems to have caught on widely to refer to this type of stream. Really, FRP refers to something a little different. I prefer the term CES - Compositional Event System. But, this is minor semantic quibbling.