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