Introductory talk about functional programming.

1. Functional programming

2. Functional Programming (Languages) FP(L)

3. Agenda
● Why functional programming?
● Functional Programming
● Benefits of FP
● Concurrency
● How to program functionally

4. In the beginning there was ...

5. Lambda calculus
● Theoretical framework
● Describes functions and their evaluations
● Basis of almost all FPL today

7. Why is functional programming important?

8. The benefits of functional
programming
● succinct, concise and understandable code
● offers different programming perspective
● FP becoming more accessible
● concurrency / parallelism without tears

9. Why FP is important?
Row 1 Row 2 Row 3 Row 4
0
2
4
6
8
10
12
Column 1
Column 2
Column 3

10. Wirth's Law
Software is getting slower more rapidly than
hardware becomes faster

11. FP != FPL

13. If all of these are functional programming
(languages), isn't it overwhelming and difficult?

14. Not really. But why?

15. What is functional programming?
What is a functional programming language?

16. Functional programming is just a style

17. Programming styles
Declarative vs. Imperative programming

18. What? vs. How?

19. What is object-oriented
programming?
● Reuse code via classes
● Eliminate bugs
– Encapsulation
– Data hiding

20. Functional programming
● Reuse code via function composition
● Eliminate bugs
– Immutability
– Pure functions

23. Programs as functions
● No loops but recursion
● Minimise number of variables
● no assignment operation
● only constants, parameters and values

25. The dark side
too much recursion can overflow the stack
(without tail-call optimization)
high memory consumptions from creating so
many objects

26. No variables, no assignment – No
problem
● No notion of the internal state of a function
● referential transparency
● value semantics

27. Referential Transparency
An expression is said to be referentially
transparent if it can be replaced with its value
without changing the behaviour of a program
25 == 5 * 5

28. Value semantics
It means for an object that only its value counts,
not its identity
Coping an object doesn't change the behaviour
of your program

29. Pure Function
● Always evaluates to the same result
● Evaluation does not cause side effects

31. What does it mean in practice?
No bugs due to nasty side effects

32. Mutable state
Map<Person, String> map = …
Person p = new Person('John');
map.put(p, "Hey, there!");

33. p.setName("Dark Lord");

34. Oops!
map.get(p); // => null

35. Immutability
“Object-oriented programming makes code
understandable by encapsulating moving parts.
Functional programming makes code
understandable by minimizing moving parts.”
— Michael Feathers, author of Working with Legacy Code, via
Twitter

36. ● Data once created are never changed
● Need to “update” your data? – create new one
● Safe to share data between threads

37. HOF
Higher order function
– Takes one or more functions as an input
and/or
– Outputs function

38. Ruby
● Map
● Each
● Reduce
● Inject
● Select

39. Ruby
def twice(f, x)
f.call(f.call(x))
end
f1 = ->(x){ x / 3 }
print twice(f1, 9) # 1

40. JavaScript
function twice(f, x){
return f(f(x));
}
function f(x){
return x*3;
}
twice(f, 7); // 63

41. Higher-order functions start to shine when you
need to compose functions

42. JavaScript
function filter(array, test) {
var passed = [];
for (var i = 0; i < array.length; i++) {
if (test(array[i]))
passed.push(array[i]);
}
return passed;
}

43. function map(array, transform) {
var mapped = [];
for (var i = 0; i < array.length; i++)
mapped.push(transform(array[i]));
return mapped;
}

44. function average(array) {
function plus(a, b) { return a + b; }
return array.reduce(plus) / array.length;
}

45. function age(p) { return p.died - p.born; }
function male(p) { return p.sex == "m"; }

46. average(ancestry.filter(male).map(age))

47. Lazy evaluation
● Delaying evaluation of an expression
● Reduction of memory footprint as values are created
when needed not when they are declared
● Potential to construct infinite data structures
● Requires pure functions as order of operations becomes
indeterminate

48. Lazy Fibonacci
● Haskell
● Infinite list
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
● Take only required Fibonacci numbers

49. Memoization
● Storing the result of function calls
● Returning the cached result
● Trade-off between function time cost and space
cost
● Run-time not compile-time optimisation

51. You can program functionally in a variety of
programming languages

52. A functional language provides 'sane' defaults

53. Why is FP important? (again)

54. ● formal provability
● code comprehension modularity
● unit testing and debugging
● automation
● maintainability
● hot code deployment

55. Provability
simpler execution model makes program proving
easier both for computers and humans

56. Code comprehension
easier to understand and reason about because
you don't have to worry about what is happening
behind the scenes

57. Modularity
modular design brings with it great productivity
improvements. Small modules can be coded
quickly and easily and have a greater chance of
re-use which leads to faster development of
programs.
Additionally, the modules can be tested
independently, thus helping to reduce the time
spent unit testing and debugging

58. Testing, debugging & automation
● PF is much easier to reason about
● specific arguments always return specific results
● problems are easy to troubleshoot/duplicate because no
state or external dependencies
● automation is simplified due to lack of environmental,
state or configuration concerns

59. Maintainability
easier to maintain as you don't have to worry
about accidentally changing anything outside a
given function

60. Concurrency
Compilers think, too

63. In the purely functional world, the compiler does
not need proof of non-interference. It is built into
the programming language.

64. Implicit parallelism is free in functional
programming languages.

65. Sadly, this story is naïve and unrealistic and yet it
contains the key to a parallel world.

66. In the imperative world mutation creates too few
opportunities for automatic parallel execution

67. In the functional world a lack of dependencies
means too many opportunities for automatic
parallel execution.

68. The imperative world will see explicit parallel
programming and the big battle against race
condition bugs.

69. The functional world will provide explicit parallel
programming with fewer race conditions.

71. How to program functionally?

72. Avoid side-effects
● do not modify variables passed to functions
● do not modify any global variables

73. ● Use higher-order functions
● Limit variable assignment
● Same input → same output
● Don't share state

74. Does order matter?
Order can be a side effect

75. ● Use immutable data
● Lazy evaluation

76. Decompose problems into functions
(whenever you can)

77. Questions
Any questions?
Slack #fp

78. Resources
http://eloquentjavascript.net/05_higher_order.html
http://www.sitepoint.com/functional-programming-tec
hniques-with-ruby-part-ii/
http://www.functionalprogramming.com/history.html
http://www.cs.kent.ac.uk/people/staff/dat/miranda/w
hyfp90.pdf