The Joy Of Functional Programming
Upcoming SlideShare
Loading in...5

The Joy Of Functional Programming



Presented at POSSCON 09

Presented at POSSCON 09



Total Views
Views on SlideShare
Embed Views



1 Embed 9 9


Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.


11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • good
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

The Joy Of Functional Programming The Joy Of Functional Programming Presentation Transcript

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