Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Joy Of Functional Programming

2,559 views

Published on

Presented at POSSCON 09

Published in: Technology, News & Politics

The Joy Of Functional Programming

  1. 1. The Joy of Functional Programming Jason Dew Mark Gunnels John Long jason@catamorphiclabs.com mark@catamorphiclabs.com john@catamorphiclabs.com
  2. 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. 3. Agenda Theory: why are we interested in functional programming languages? Praxis: demonstration of interesting characteristics of functional languages
  4. 4. Theory There is an impedance mismatch between hardware and software Current software paradigms are too complex to be reasoned about easily
  5. 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. 6. Brooks was right Twenty years later and no order-of- magnitude step has occurred in mainstream software.
  7. 7. But... Thesis was correct, assumptions were not Several studies indicate that functional programming may provide this increase
  8. 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. 9. The Cause? Suggests Erlang was removing “accidental complexity” by reducing the presence of: Shared state Side-effects
  10. 10. Characteristics of Functional Programming Side-effects are the exception, not the rule Shared state is avoided Variables are immutable
  11. 11. Praxis Haskell Erlang Clojure
  12. 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. 13. Haskell The type system Non-strict evaluation Pure functions
  14. 14. Basic Types All of the regular types, Int, Double, Char, String, etc. Type synonyms Makes your code more expressive
  15. 15. Algebraic Data Types similar to an enumeration define several values instantiated with a “type constructor”
  16. 16. Integer Tree ADT Integer Tree 2 4
  17. 17. Integer Tree ADT my_tree Node Leaf 2 Node Empty Leaf 4
  18. 18. Algebraic Data Types More concise way to define data structures Automatically type check your data types at compile time
  19. 19. Non-strict Evaluation Also known as “lazy” evaluation Function arguments are not computed until required Infinite data structures possible
  20. 20. Infinite Lists
  21. 21. Pure Functions Functions with no side effects The default in Haskell Impure functions encapsulated inside of the IO monad
  22. 22. Examples Pure functions look normal Impure functions have type annotations
  23. 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
  24. 24. Erlang Recursion Pattern matching Actor-based concurrency
  25. 25. Recursion “To understand recursion, you must understand recursion” A function that calls itself Tail call optimization
  26. 26. Recursion Increases the call stack May overflow
  27. 27. Recursion Tail call optimization Call stack remains constant in size
  28. 28. Pattern Matching Simpler functions (less errors) Abstract away logical branching (if, switch, etc)
  29. 29. Simple Example
  30. 30. No Logic Branches
  31. 31. Complex Pattern Matching Match complex patterns or types
  32. 32. Complex Pattern Matching
  33. 33. Concurrency Able to take advantage of multiple processors across multiple machines Actor based concurrency
  34. 34. Shared State Is Evil Locking Race conditions Deadlock
  35. 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. 36. Actor based Concurrency In Erlang, processes are the actors Each process has a mailbox Processes communicate via message passing
  37. 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. 38. Performance Scales almost linearly with number of cores Still being improved upon
  39. 39. Examples
  40. 40. Output “hello!” {message, today} timeout ok
  41. 41. Clojure Lisp on the JVM Embraces its Java roots
  42. 42. Clojure Higher order functions Pattern matching via multimethods Concurrency and STM
  43. 43. Higher-order Functions Can take other functions as arguments Able to return functions as results
  44. 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. 45. Higher-order Functions Return a function
  46. 46. Currying, sortof
  47. 47. Pattern Matching “Switch statements are a code smell.”
  48. 48. Multimethods Clojure supports multimethods Dispatching on types, values, attributes and metadata of, and relationships between, one or more arguments
  49. 49. Problem Statement Define an “area” function for the shapes Rectangle and Circle
  50. 50. Defining Multimethods Dispatching method must be supplied Will be applied to the arguments and produce a dispatch value
  51. 51. Defining Multimethods Must create a new method of multimethod associated with a dispatch value
  52. 52. Defining Multimethods Voila... le multimethod Use of if, switch, etc. is eliminated by dispatching on type
  53. 53. Concurrency Clojure has several concurrency mechanisms The most interesting is... Shared Transactional Memory (STM)
  54. 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. 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. 56. Atomic. Consistent. Isolated. Updates are consistent A new value can be checked with a validator function before allowing the transaction to commit
  57. 57. Atomic. Consistent. Isolated. Updates are isolated No transaction sees the effects of any other transaction while it is running
  58. 58. Questions?

×