Skip to content

Instantly share code, notes, and snippets.

@lobo
Forked from ohanhi/frp.md
Created August 8, 2016 21:20
Show Gist options
  • Select an option

  • Save lobo/5e521e67aa4e3d4963a9c6f54c82fc93 to your computer and use it in GitHub Desktop.

Select an option

Save lobo/5e521e67aa4e3d4963a9c6f54c82fc93 to your computer and use it in GitHub Desktop.
Learning FP the hard way: Experiences on the Elm language

Foreword

A good friend of mine convinced me about the benefits of Reactive Programming 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment