Functional Programming - Worth the Effort
1 like6,021 views
The document discusses the significant benefits of functional programming, including reliability, conciseness, and enhanced maintainability through type systems and pure functions. It contrasts functional programming's advantages with limitations of traditional development paradigms, emphasizing type inference and type safety to minimize errors. Additionally, it highlights the growing adoption of functional programming in various industries and languages, while stressing the importance of properly designed types for effective software development.
Functional Programming - Worth the Effort
- 1. Why Func)onal Programming is Worth the Effort
- 2. Contents • Benefits of func)onal programming • Focus on reliability • Examples: Using the right types • Func)onal Programming in Industry • Live Coding in Scala
- 3. Audience Polls I am most experienced in: ● Java ● C/C++/Obj-‐C/C# ● PHP ● VB ● Python ● JavaScript ● Ruby ● Perl ● Racket ● Other
- 4. Audience Polls My programs work perfectly the first )me I run them: 1. Nearly every )me 2. Frequently 3. Some)mes 4. Rarely 5. Almost Never
- 5. What is Func)onal Programming? ● Computa)on as evalua)on of func)ons o No side-‐effects (pure func)ons)
- 6. Consequences of Purity ● FP requires higher order func)ons ● Order of evalua)on has no impact on returned value (as in mathema)cs)
- 7. Evalua)on Order: Illustra)on Given the func)on square(x) = x*x square(max(3, 4)) max(3, 4) * max(3, 4) square (4) 4 * 4
- 8. Benefits ● Clarity o Referen)al transparency facilitates reasoning ● Conciseness o HOFs enable abstrac)on and favor reuse ● Safety o Effects are values and can be type checked! ● Maintainability o As a consequence
- 9. More Benefits ● Concurrency Determinis)c Parallelism: Order of evalua)on is irrelevant, so parallel evalua)on is fine too.
- 10. Type Checking Type: Essen)ally, a set of admissible values for a variable, a parameter, a field or a return value. When designing a program we make decisions about types. We should tell the compiler! Type inference means you don’t have to repeat types constantly to the compiler. It reasons about types, it doesn’t just check them. You can do pair programming with the compiler.
- 11. What about Dynamic Type Checking Almost no type checking; only primi)ve func)ons are checked. Adding run)me checks in user func)ons is possible but is slow and is more trouble than sta)c checking. Failed checks require )me-‐consuming diagnosis with debuggers.
- 12. Classes of Bugs Es)mates for illustra)on purposes. No real data behind this.
- 13. Extreme Reliability When you play by the rules of type system you avoid almost all errors. Once it compiles, it works!
- 14. Curry-‐Howard Correspondence Equivalence between ● Proofs (in some logic) ● Programs (in some typed FP language)
- 15. Dependently Typed Languages ● Agda ● Idris
- 16. Types vs Tests Tests check a few execu)ons Types check all poten)al execu)ons!
- 17. Test Driven to Type Driven Development Test Driven Development has benefits but also important costs. With the safety brought by types, many tests are no longer required. Tests can become stale. Some automated tests are s)ll useful.
- 18. Documenta)on is Brihle Change is omnipresent and documenta)on will frequently become stale. More precise types can act as documenta)on that cannot be out of date. So you might need a bit less documenta)on.
- 19. My Exposure to Func)onal Programming In 1992: Miranda Was told not to expect to write real sojware with that, more of a toy language. Func)onal Programming is no longer a toy.
- 20. Func)onal Programming in Industry ● Not yet mainstream, but seeing more adop)on ● Many ecosystems sufficiently mature
- 21. Func)onal Programming Languages in Industry ● Dynamically Typed o Scheme, Racket, Common Lisp, Clojure, Erlang ● Typed o Haskell o F# o Scala o OCaml
- 22. Func)onal Programming at BoldRadius ● Scala is our main JVM language ● .NET developers looking seriously at F#
- 23. Using the Right Types The right type is ● not too strict (strong formula) ● not too loose (weak formula)
- 24. Too Strict Producer works too hard to produce informa)on the consumer does not need. ● Extraneous fields (conjunc)ons, “and”) ● Not enough alterna)ves (disjuc)ons, “or”)
- 25. Too Loose Consumer is missing informa)on that the Producer could easily have provided. ● Missing fields (conjunc)ons, “and”) ● Too many alterna)ves (disjuc)ons, “or”)
- 26. Avoid Trying to Future Proof Building a type for the future ojen makes it too strong or too weak for the current producers and consumers. Extreme examples: ● “Stringly typed” code encodes everything in strings. ● Using Object in Java
- 27. Type Change As needs change, both types and func)ons should change. Compiler errors will indicate inconsistencies during refactoring. Persisted data increases fric)on however.
- 28. Examples
- 29. Op)onal Values Dis)nguish what is op)onal and required. Null references should be banned because they can be assigned to all types, making everything op)onal. data Maybe a = Nothing | Just a data Car = Car Engine Wheels (Maybe AC) Car consumers can rely on the presence of an Engine.
- 30. Non Applicable Field data Account = Account {open :: Boolean, balance :: Dollars} Too loose: ● We want to disallow a closed account with a non-‐ zero balance data Account2 = Open {balance :: Dollars} | Closed
- 31. Duplicate Data data AgeInfo = AgeInfo {age: Int, minor: Boolean} Too loose: ● Consumers may rely on these two fields having consistent values. data AgeInfo2 = AgeInfo2 {age: Int} isMinor :: AgeInfo2 -> Boolean
- 32. List with a Selected Element data Selected1 a = Selected1 (List a) Int Too loose: ● Int index could be out of range ● List could be empty Consumer may get input it does know how to handle. data Selected2 a = Selected2 (List a) a (List a)
- 33. Binary Tree data Node i a = Node i a a data Tree i a = Leaf a | Internal (Node i (Tree i a)) What if we needed to represent a full binary tree? ● Could use Tree and maintain the “fullness” invariant at run)me. Error prone. ● Or use the right type that checks this at compile )me...
- 34. Full Binary Tree (non-‐regular type!) data Node i a = Node i a a data Full i a = Last a | Level (Full i (Node i a)) a | Node i a | Node i (Node i a) | ... a | (i, a, a) | (i, (i, a, a), (i, a, a)) | ...
- 35. Free Monad data Free f a = Pure a | Roll (f (Free f a)) Equivalent to this: a | f (a | f ( a | … )) Not this: a | f a | f (f a) | ... data Node i a = Node i a a Free (Node i) a is equivalent to Tree i a, not Full i a
- 36. More Free Monads data Command a = WriteLine String a | ReadLine (String -> a) Free Command a = a | Command (a | Command (a | Command (...))) Represents computa)ons doing specific IO opera)ons in a type-‐safe manner!
- 37. Patrick Prémont Func)onal Programming Architect BoldRadius Solu)ons @ppremont www.boldradius.com