ted.neward@newardassociates.com | Blog: http://blogs.newardassociates.com | Github: tedneward | LinkedIn: tedneward
Pick up on what "functional programming" is
Discover how to use Java to do it
dependences on mutable state
compiler out-of-order rewrites
difficulties reasoning about the code
concurrency planning/programming
functional as in mathematics' notion of function
for every x, there is a corresponding value y
this implies no side effects
not imperative statements, but expressions
x = x+1 is not increment... it's impossible
this implies expressions can be substituted
... or executed independently (parallellism)
spectrum of "functional-ness", known as purity
"pure" functional languages allow for no side effects
"impure" functional languages allow for side effects
immutable values over mutable variables
functions as first-class values
currying, partial-application of functions
expressions-not-statements
laziness/deferred execution
strongly-typed, type-inferenced
recursion
tuples, lists
pattern-matching
immutable values over mutable variables
functions as first-class values
currying, partial-application of functions
expressions-not-statements
laziness/deferred execution
once bound, a binding remains constant throughout its lifetime
thus offers no opportunity for confusion/reassignment/etc
"values" are not "variables"
name/value binding is fixed once bound
A functional pseudocode example
let x = 0 // or sometimes "val" let y = 1 let z = x + y
think about common operations-if we could vary the actual operation itself as a parameter, how much work could be saved?
example: you need to iterate through a collection to...
... and each time you write it as a "for" loop, you're violating DRY
this enables the use of functions as "higher-order" functions
"take this function, and execute inside your context"
similar in some ways to a callback, but with clearer semantics
in a lot of ways, this is Inversion-of-Control all over again
Higher-order functions
let numbers = [1, 2, 3, 4, 5] let squares = numbers.map((num) -> num * num); // squares = [1, 4, 9, 16, 25]
In functional languages, we can build functions out of functions
This allows us to achieve reuse through the composition/combination of functional parts into larger functions
By doing so, we "build up" larger more complex functions
When combining several in a row using currying, this is also called "pipelining"
providing some of the parameters (but not all) to a function and capturing that as a function to be called
Partial application
let add x y = x + y let five = add 2 3 // = 5 let addBy2 = add 2 // = (anonymous fn) = 2 + y let six = addBy2 addBy2 2 // = 6
it turns out (thank you Alonzo Church!) that all functions can be reduced to functions taking one parameter and either yielding a result or another function
this permits easy "pipelining" and composition of functions in a highly reusable manner (at the micro level)
this is an outgrowth of the functions-as-first-class-citizens idea: if functions yield values, what is the practical difference between a keyword and a function?
even C++ tried to make user-defined elements look and feel like built-in constructs and vice versa
if we're really good about this, developers can create new "language" primitives and nobody will know the difference
object-oriented laziness has nothing on functional laziness
don't compute anything until absolutely necessary (but make sure to maintain the dependency graph so everything is there when needed)
laziness is highly encouraged/permissible in pure FP
just to be fair, laziness is highly desirable inside the process, not so across processes unless carefully managed
lots of things can be seen as sequences
characters in a string
fields in a record
records in a database
files in a directory
algorithmic calculations (factorial, fibonacci, ...)
lines in a file
user interactions
sequences and collections have a deep relationship
in many ways, this is the gateway to FP ideas/concepts
strongly-typed, type-inferenced
recursion
tuples, lists
pattern-matching
Strongly-typed
the dynamic language community will have you believe that it's better to write unit tests by hand than to have a system that can do common-sense checking for you
Type-inferenced
why do I have to be explicit to the language/compiler, when it can figure out what I'm trying to do and when?
Recursion
immutable values doesn't mean no state changes
instead, hold state on the stack, not in mutable memory
Tuples, lists
"bundles" of data in different directions
tuples give developers a "lightweight" object that needn't be named or otherwise formalized
Pattern-matching
switch/case is to pattern-matching as my kid's soccer team is to Arsenal or Manchester United
pattern-matching also encourages "destructuring" of data when necessary/desired
pattern-matching can operate off of collections of values
Web
Wikipedia: It all starts with the Lambda calculus
http://en.wikipedia.org/wiki/Lambda_calculus
Learned about functions as first-class citizens
Understood how Java embraces some of it
Discovered some ways to apply FP
Architect, Engineering Manager/Leader, "force multiplier"
http://www.newardassociates.com
http://blogs.newardassociates.com
Sr Distinguished Engineer, Capital One
Educative (http://educative.io) Author
Performance Management for Engineering Managers
Books
Developer Relations Activity Patterns (w/Woodruff, et al; APress, forthcoming)
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)