The Joy Of Functional Programming
- 1. The Joy of Functional Programming Jason Dew Mark Gunnels John Long jason@catamorphiclabs.com mark@catamorphiclabs.com john@catamorphiclabs.com
- 2. About Us Catamorphic Labs strives to create more value than it takes by applying open source software, emerging technology, and data analysis to complex issues confronting organizations.
- 3. Agenda Theory: why are we interested in functional programming languages? Praxis: demonstration of interesting characteristics of functional languages
- 4. Theory There is an impedance mismatch between hardware and software Current software paradigms are too complex to be reasoned about easily
- 5. Brooks’ Thesis No technology in the near future will yield an order-of-magnitude improvement in software productivity “accidental complexity” eliminated Only “essential complexity” remained
- 6. Brooks was right Twenty years later and no order-of- magnitude step has occurred in mainstream software.
- 7. But... Thesis was correct, assumptions were not Several studies indicate that functional programming may provide this increase
- 8. Case Study Ericsson’s “Four-fold Increase in Productivity and Quality” paper A ten-fold reduction in lines of code when C++ code was rewritten in Erlang Defect count fell in proportion to the lines of code
- 9. The Cause? Suggests Erlang was removing “accidental complexity” by reducing the presence of: Shared state Side-effects
- 10. Characteristics of Functional Programming Side-effects are the exception, not the rule Shared state is avoided Variables are immutable
- 12. Haskell A lazy, purely functional language Difficult to master but very rewarding to learn One of the few good things designed by a committee
- 13. Haskell The type system Non-strict evaluation Pure functions
- 14. Basic Types All of the regular types, Int, Double, Char, String, etc. Type synonyms Makes your code more expressive
- 15. Algebraic Data Types similar to an enumeration define several values instantiated with a “type constructor”
- 16. Integer Tree ADT Integer Tree 2 4
- 17. Integer Tree ADT my_tree Node Leaf 2 Node Empty Leaf 4
- 18. Algebraic Data Types More concise way to define data structures Automatically type check your data types at compile time
- 19. Non-strict Evaluation Also known as “lazy” evaluation Function arguments are not computed until required Infinite data structures possible
- 20. Infinite Lists
- 21. Pure Functions Functions with no side effects The default in Haskell Impure functions encapsulated inside of the IO monad
- 22. Examples Pure functions look normal Impure functions have type annotations
- 23. Erlang Designed for scalability and reliability Ericsson achieved 99.9999999% uptime over the course of a year on a core router Processes are very cheap in the Erlang VM
- 25. Recursion “To understand recursion, you must understand recursion” A function that calls itself Tail call optimization
- 26. Recursion Increases the call stack May overflow
- 27. Recursion Tail call optimization Call stack remains constant in size
- 28. Pattern Matching Simpler functions (less errors) Abstract away logical branching (if, switch, etc)
- 29. Simple Example
- 31. Complex Pattern Matching Match complex patterns or types
- 33. Concurrency Able to take advantage of multiple processors across multiple machines Actor based concurrency
- 34. Shared State Is Evil Locking Race conditions Deadlock
- 35. Solution? No Shared State No locking needed, you don’t access the same memory Processes keep their own memory (copies of what they need) Changed something? Send a message.
- 36. Actor based Concurrency In Erlang, processes are the actors Each process has a mailbox Processes communicate via message passing
- 37. Actor based Concurrency Send a process a message with the ! operator Processes run on any processor or computer Able to run millions of processes inside one virtual machine
- 38. Performance Scales almost linearly with number of cores Still being improved upon
- 39. Examples
- 41. Clojure Lisp on the JVM Embraces its Java roots
- 42. Clojure Higher order functions Pattern matching via multimethods Concurrency and STM
- 43. Higher-order Functions Can take other functions as arguments Able to return functions as results
- 44. Higher-order Functions Take a function as an argument Applies a given function to a sequence of elements and returns a sequence of results
- 45. Higher-order Functions Return a function
- 46. Currying, sortof
- 47. Pattern Matching “Switch statements are a code smell.”
- 48. Multimethods Clojure supports multimethods Dispatching on types, values, attributes and metadata of, and relationships between, one or more arguments
- 49. Problem Statement Define an “area” function for the shapes Rectangle and Circle
- 50. Defining Multimethods Dispatching method must be supplied Will be applied to the arguments and produce a dispatch value
- 51. Defining Multimethods Must create a new method of multimethod associated with a dispatch value
- 52. Defining Multimethods Voila... le multimethod Use of if, switch, etc. is eliminated by dispatching on type
- 53. Concurrency Clojure has several concurrency mechanisms The most interesting is... Shared Transactional Memory (STM)
- 54. STM Analogous to database transactions for controlling access to shared memory Works with refs, a mutable type for synchronous, coordinated changes to one or more values
- 55. Atomic. Consistent. Isolated. Updates are atomic If you update more than one ref in a transaction, the update appears as a simultaneous event to everything outside of the transaction
- 56. Atomic. Consistent. Isolated. Updates are consistent A new value can be checked with a validator function before allowing the transaction to commit
- 57. Atomic. Consistent. Isolated. Updates are isolated No transaction sees the effects of any other transaction while it is running
- 59. Questions?