Deconstructing Functional Programming

Deconstructing Functional
Programming
Gilad Bracha

Wednesday, November 13, 13

Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/functional-pros-cons

InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month

Presented at QCon San Francisco
www.qconsf.com
Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide

The Heart of Darkness


What is Functional
Programming?
Deﬁnitions vary, but tend to involve
Higher order functions (HOFs)
Absence of effects


Higher Order Functions
Functions are values
Can be passed as arguments and returned as results
Function literals are expressions that can be written
anywhere an expression can appear


Languages with HOFs

Smalltalk, Self, Newspeak, Dart, Javascript ... and now
even Java (gasp)


Languages with Effects

Lisp, Scheme, Racket, Clojure, ML, OCaml, F#, Erlang


Languages w/o HOFs

Backus’ FP, SISAL, the original versions of Erlang ...
These are functional languages; in fact FP was the
original functional language


What is Functional
Programming?
1. A style which utilizes HOFs and minimizes effects
2. A cult(ure)
3. All of the above
In particular, there is no contradiction with object
orientation (see Scala as an example)


HOFs/Closures
HOFs are awesome. Lambdas even more so.
The great classical HOFs: map, ﬁlter, reduce
They’ve been around since Lisp & Smalltalk (i.e., long
before the term FP was introduced)


User-deﬁned Control
Structures

a > b ifTrue:[ a - b].


Structures

A boolean, an object, the target of ...


Structures

The method, invoked with ...


Structures

The argument, a block/lambda/closure


Structures
In class True, ifTrue: evaluates its argument and returns
the result.
In class False, ifTrue: returns nil.


Tail Calls
Look ma, no loops:
while(b, s) { if b() then {s(); while(b,s)} else null}
How to express computation unbounded in time but
bounded in space.
A language is functional if it supports proper tail calls?


Tail Calls
What about debugging? Where’s my stack trace?

http://gbracha.blogspot.com/2009/12/chased-byones-own-tail.html


Hindley-Milner

If it typechecks, it works .... ?
But error messages are terrible
Leaks implementation information


Currying
All functions take one argument, produce one result
Extremely compositional, BUT
We lose almost all structure
Forced to rely on type system


Pattern Matching
Nice
Allows FPLs to pretend they don’t do dynamic typechecks
and casts
Usually second class
First class patterns are interesting
http://gbracha.blogspot.com/2010/05/patterns-of-dynamic-typechecking.html
http://gbracha.blogspot.com/2010/06/patterns-as-objects-in-newspeak.html


Monads


A Monad by any other name
would smell ...


A Monad by any other name
would smell as sweet


Ye Highlands and ye Lowlands,
Oh, where hae ye been?
They hae slain the Earl O' Moray,
And laid him on the green.
The Bonny Earl O’Moray


And Lady Mondegreen.
The Bonny Earl O’Moray, revised by Sylvia Wright


And Lady Monadgreen.
The Bonny Earl O’Moray, revised by me


Monad Metaphors, aka
Monadgreens
Nuclear waste containers
Romantic conquests
Space Suits
Monsters
Macros
Containers
Conversations
Black holes

Lady Monadgreen’s Curse

Once you understand monads, you immediately
become incapable of explaining them to anyone else


Monads

http://gbracha.blogspot.com/2011/01/maybemonads-might-not-matter.html


abstract class FlatMappable {
FlatMappable(a);
ﬂatMap(f);
}


abstract class Monad {
Monad(a);
ﬂatMap(f);
}


Monad.unit(a);
ﬂatMap(f);
}


Monad.return(a);
ﬂatMap(f);
}


Monad.return(a);
bind(f);
}


Monad.return(a);
operator * (f);
}


Monad.return(a);
operator >>= (f);
}


abstract class FlatMappable {
FlatMappable(a);
ﬂatMap(f); // map, then ﬂatten
}


abstract class Mappable {
Mappable(a);
map(f);
}
abstract class MappableAndFlattenable
extends Mappable {
MappableAndFlattenable(a): super(a);
ﬂatten();
}

abstract class FlatMappable extends
MappableAndFlattenable {
FlatMappable(a): super(a);
ﬂatMap(f) => map(f).ﬂatten();
}


What’s the Contract Like?
Sample Clause:
new Mappable(x).map(f) ==
new Mappable( f(x));


Sample Clause:
new FlatMappable(x).ﬂatMap(f) == f(x);


Sample Clause:
new C(x).ﬂatMap(f) == f(x);
for any class C that implements the contract


The Whole Contract
new C(x).flatMap(f) == f(x);
c.flatMap((x)=> new C(x)) == c;
c.flatMap((x)=> f(x).flatMap(g)) ==
c.flatMap(f).flatMap(g);


FlatMappable is more useful
than you think

Collections of all kinds: in-memory, databases, streams
“Singleton collections”: functions, continuations, futures


A simple expression

e.b.c
what could possibly go wrong?


A simple expression
e.b.c
e could be null. Ok
e == null ? null : e.b.c


A simple expression
e.b.c
e could be null. Ok
e == null ? null : e.b.c
oops, e.b could be null
e == null ? null : e.b == null ? null : e.b.c


A simple expression
e == null ? null : e.b == null ? null : e.b.c
what about side effects?
(var it = e) == null ?
null :
(var ab = it.b) == null ?
null :
ab.c

Safe Navigation Operator
e?.b?.c
e?.id(a1, .. an) is sugar for
e.ifNotNull((x) => x.id(a1, .. an))
where we deﬁne
class Object {
ifNotNull(f) => this == null ? null : f(this);
}


Promise Pipelining
e <- id(a1, .. an) is sugar for
e.then((x) => x.id(a1, .. an))
where we deﬁne
class Object {
then(f) => f(this);
}


Safe Promise Pipelining
where we deﬁne
class Object {
then(f) => this == null ? null : f(this);
}


Async message pipelining
where we deﬁne
class Object {
then(f) => Future.immediate(this).then(f);
}


Scalar operators extended
pointwise to collections
e.* id(a1, .. an) is sugar for
e.map((x) => x.id(a1, .. an))
where we deﬁne
class Object {
map(f) => f(this);
}
[‘abc’, ‘de’, ‘wxyz’].* length evaluates to [3, 2, 4]

Scalar operators extended
pointwise to collections
e.* id(a1, .. an) is sugar for
e.map((x) => x.id(a1, .. an))
where we deﬁne
class Object {
map(f) => this == null ? null : f(this);
}
[‘abc’, null, ‘wxyz’].* length evaluates to [3, null, 4]

Stream transformers

mouseclicks.* x


Is There a Pattern Here?
The Curse of the Monadgreens prevents me from
discussing this further
In practice, we see generalizations of set notation
rather than navigation
LINQ is an example. However, you didn’t need to have
even heard of monads to invent LINQ. Just look at
Smalltalk’s collection API, Glorp etc.
http://gbracha.blogspot.com/2011/01/maybemonads-might-not-matter.html

The Killer App for FP?


The Killer App for FP?

Live Programming
http://gbracha.blogspot.com/2012/11/debug-mode-is-only-mode.html
http://gbracha.blogspot.com/2013/04/making-methods-live.html
https://www.youtube.com/watch?v=74WqdS_58uY


Summary
Much to learn from FP
FP and OOP are often complementary
Filter out propaganda
Separate cultural baggage from core values


The Newspeak eye
on slide 5 was designed by
Victoria Bracha and is used by permission.

The cartoon on slide 2 comes from http://xkcd.com/
1270/ and is licensed by xkcd.com under http://
creativecommons.org/licenses/by-nc/2.5/
The rose on slide 16 is by Kikuo Teranishi and licensed
under http://creativecommons.org/licenses/by-sa/3.0/
deed.en


Watch the video with slide synchronization on
InfoQ.com!
http://www.infoq.com/presentations/functional
-pros-cons

Deconstructing Functional Programming

Recommended

Recommended

More Related Content

Similar to Deconstructing Functional Programming

Similar to Deconstructing Functional Programming (20)

More from C4Media

More from C4Media (20)

Recently uploaded

Recently uploaded (20)

Deconstructing Functional Programming