Presented at POSSCON 09

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

11. Praxis
Haskell
Erlang
Clojure

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

24. Erlang
Recursion
Pattern matching
Actor-based concurrency

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

30. No Logic Branches

31. Complex Pattern Matching
Match complex patterns or types

32. Complex Pattern Matching

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

40. Output
“hello!”
{message, today}
timeout
ok

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?