## Foreword

A good friend of mine convinced me about the benefits of [_Reactive Programming_](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754) not that long ago. It almost feels wrong not to write _Functional Reactive Programming_ -- the functional methodology lends itself magnificently to compliment reactive programming. So I decided to learn this stuff.

Knowing myself, I soon realized I would only ever get in the mindset if I had to solve some actual problems using the techniques. Having written JavaScript for the past few years, I could have just gone for RxJS. But again, I knew myself and felt it would give me way too much room for "going against the grain". I needed something that would enforce me to solve everything in a functional manner. This is where Elm comes in.

### Elm? What's that?

- Haskell-inspired language that compiles into HTML5
- immutable data
- strong types
- functional
- reactive

## Part I. Restriction proves helpful

- all functions are pure
- no way to cause side-effects
- type annotations clarify the goal
- there are no loops
- mind-twister: `Signal.foldp`

## Part II. State is a result of an immutable past

- a signal is a function of time
  - for each moment, there exists a pure value of a signal
- `Signal.foldp` reduces the value in the same sense as `List.foldl`
-> each state of the interactive program is explicitly derived from all things that have happened in the past

## Part III. The learnings

- FP is often terse and readable
- reactive pattern makes input and output explicit
- no worries about weird states