A Theory of Functional Programming LambdUp
- 1. A Theory of Functional Programming Eric Normand LambdUp December 6, 2017
- 3. Newton’s Laws of Motion 1. Inertia 2. Acceleration 3. Action-reaction
- 6. Aristotelian Physics (excerpt) Ideal speed Natural place Natural motion Unnatural motion
- 7. For the video and transcript of this presentation, click here: https://lispcast.com/lambdup-2017-theory-functional-prog ramming/
- 8. Why use Functional Programming? What is Functional Programming?
- 9. paradigm a philosophical and theoretical framework of a scientific school or discipline within which theories, laws, and generalizations and the experiments performed in support of them are formulated Merriam-Webster
- 12. basic assumptions, ways of thinking, methodology
- 13. Why use Functional Programming? What is Functional Programming?
- 14. Goals of my Theory • Explain what it is we (functional programmers) actually do • in terms we can all understand • Explain why it has advantages over other paradigms • to people who haven’t done FP • Avoid focusing on features • Give explanatory and predictive power • Self-described functional programmers should agree
- 15. My Theory of FP Actions Data Calculations
- 16. Actions the process of doing something, typically to achieve an aim • Typically called Effects or Side-effects • Depend on when you run them or how many times you run them • Examples • Sending a message over the network • Writing to file system — other programs can see the change • Changing or reading mutable state
- 17. Data factual information used as a basis for reasoning, discussion, or calculation • Inert • Serializable • Requiring interpretation • Examples • Numbers • Bytes • Strings • Collections
- 18. Calculations computation from inputs to outputs • Mathematical functions • Eternal — outside of time • Referentially transparent • Examples • List concatenation • Summing numbers
- 21. Implementation Haskell • Data — built-in types and defined types • Calculations — functions • Actions — IO type
- 22. Implementation Clojure • Data — built-in types • Calculations — pure functions • Actions — impure functions
- 23. Further down the rabbit hole • Everything “First-class” • Data • Calculations • Actions • Minimum necessary to program functionally in a language
- 24. Domains are separate Data Data + Data => Data Examples • Addition • Concatenation Calculations Calc + Calc => Calc
- 25. Actions • Contagious! • Calculation + Action => Action • Data + Action => Action • Examples • Print the square of a number — square => print! • Parse the input as a number — read! => parse
- 26. Calculations • Algebraic manipulation • Turing complete • implies the Halting problem • Opaque • What is this code going to do? • Only way to know is to run it
- 27. Data • Can represent something else • Structure • Known Big-O complexities
- 28. Refactorings Actions • Action => Action + Calculation • Action => Action + Data • Action => Action + Action Calculations • Calculation => Calculation + Data • Calculation => Calculation + Calculation
- 30. What counts as an Action? Calculations Timeless Actions Bound in time Pure function Read/write to disk Pure function takes 24 hours to compute Read/write to temp file as buffer
- 31. Actions how many times they run always matters - 0≠1≠more launching a missile sending an email idempotent - 0≠1=more setting public flag to true free of side-effects - 0=1=more GET request reading mutable state
- 32. Actions when they run transactional read guaranteed to be consistent transactional+serialized writes Order matters, but at least it’s some order exactly once reads Communicating Sequential Processes
- 33. Eric Normand Follow Eric on: Eric Normand @EricNormand eric@lispcast.comlispcast.com