4 ms·
Programming is arguably the process of abstracting data (and functions which are also data). Abstraction does hide information, but it does so to expose the ess
by proc0 9y ago
Programming is arguably the process of abstracting data (and functions which are also data). Abstraction does hide information, but it does so to expose the essentials. Good abstraction should lead to DRY code.
Streams are a form of abstraction that allow for __pure__ functional "event" patterns. OOP world like JS events and event handlers, allow mutations and have no problem sending messages with objects to process. The problem with this from a pure functional paradigm is that it isn't very composable. Two functions called one after another may not always compute the same thing if they each respond to random events whenever. The solution is to create a "stream" abstraction, and to have specific data types handling different types of streams. By thinking of events as streams, you now have a "neutral" signal that you tap into, and you just wait until you have a message. Without explaining and going into details, this allows for composable, pure function 'events'.
To summarize, streams are taking mutable event patterns into the world of pure (immutable) functional "event" patterns. And this is good if you already are convinced mutations are bad (different topic).
- bsaul 9y agoPure functional only takes you so far. If you’re using transient servers to process http queries that has no local state, then the frp abstractions are probably a good fit. When you’re dealing with an app or a single page web app, you’re spending the whole user session mutating one big state (represented on the UI). Every events are going to apply some diff over that big state, and so what you have in practice is a stream of effects.
- proc0 9y agoFRP is purely functional. Side effects can be managed with pure functions using Monads, and Streams are also Monads because of the interface they implement.