Tweet
Tweet

Slide 1

Slide 1 text

Functional Programming Ionut G. Stan - OpenAgile 2010

Slide 2

Slide 2 text

Functional Programming what why how

Slide 3

Slide 3 text

Functional Programming what why how

Slide 4

Slide 4 text

What is FP a programming style

Slide 5

Slide 5 text

What is FP a programming style conceptually derived from lambda calculus (1930s)

Slide 6

Slide 6 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming

Slide 7

Slide 7 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions

Slide 8

Slide 8 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions math function: input completely determines the output

Slide 9

Slide 9 text

Imperative Programming programming: telling a computer what to do

Slide 10

Slide 10 text

Imperative Programming programming: telling a computer what to do imperative languages are leaky abstractions

Slide 11

Slide 11 text

Imperative Programming programming: telling a computer what to do imperative languages are leaky abstractions also called von Neumann languages

Slide 12

Slide 12 text

Imperative Programming programming: telling a computer what to do imperative languages are leaky abstractions also called von Neumann languages von Neumann architecture is about modifying the state of the computer

Slide 13

Slide 13 text

von Neumann architecture

Slide 14

Slide 14 text

Imperative Programming programming: telling a computer what to do imperative languages are leaky abstractions also called von Neumann languages von Neumann architecture is about modifying the state of the computer computation model in imperative languages reflects von Neumann architecture

Slide 15

Slide 15 text

Imperative Programming programming: telling a computer what to do imperative languages are leaky abstractions also called von Neumann languages von Neumann architecture is about modifying the state of the computer computation model in imperative languages reflects von Neumann architecture imperative programming: what and how to do

Slide 16

Slide 16 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions trying to plug the abstraction leak

Slide 17

Slide 17 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions trying to plug the abstraction leak tell the computer what to do, not how

Slide 18

Slide 18 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions trying to plug the abstraction leak tell the computer what to do, not how mutations not allowed (no variables, just identifiers)

Slide 19

Slide 19 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions trying to plug the abstraction leak tell the computer what to do, not how mutations not allowed (no variables, just identifiers) no statements, just expressions (if/then/else is expression)

Slide 20

Slide 20 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions trying to plug the abstraction leak tell the computer what to do, not how mutations not allowed (no variables, just identifiers) no statements, just expressions (if/then/else is expression) functions are deterministic and side-effect free

Slide 21

Slide 21 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions trying to plug the abstraction leak tell the computer what to do, not how mutations not allowed (no variables, just identifiers) no statements, just expressions (if/then/else is expression) functions are deterministic and side-effect free functions are all we need to model computation

Slide 22

Slide 22 text

What is FP a programming style conceptually derived from lambda calculus (1930s) not procedural programming functions as in mathematical functions trying to plug the abstraction leak tell the computer what to do, not how mutations not allowed (no variables, just identifiers) no statements, just expressions (if/then/else is expression) functions are deterministic and side-effect free functions are all we need to model computation execution order is not guaranteed

Slide 23

Slide 23 text

Functional Programming what why how

Slide 24

Slide 24 text

Why FP easier to reason about programs

Slide 25

Slide 25 text

Why FP easier to reason about programs heisenbugs

Slide 26

Slide 26 text

Why FP easier to reason about programs heisenbugs race conditions

Slide 27

Slide 27 text

Why FP easier to reason about programs heisenbugs race conditions off by one errors

Slide 28

Slide 28 text

Why FP easier to reason about programs heisenbugs race conditions off by one errors objects trashing another object's internal state

Slide 29

Slide 29 text

Why FP easier to reason about programs

Slide 30

Slide 30 text

Why FP easier to reason about programs easier to parallelize

Slide 31

Slide 31 text

Why FP easier to reason about programs easier to parallelize program correctness proving

Slide 32

Slide 32 text

Why FP easier to reason about programs easier to parallelize program correctness proving composability results in greater and easier reuse

Slide 33

Slide 33 text

Just for fun - reuse in OO languages "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." Joe Armstrong, creator of Erlang

Slide 34

Slide 34 text

Why FP easier to reason about programs easier to parallelize program correctness proving composability results in greater and easier reuse try out new perspectives

Slide 35

Slide 35 text

Functional Programming what why how

Slide 36

Slide 36 text

Functional Programming what why how (even in imperative languages)

Slide 37

Slide 37 text

How to FP avoid side-effects/mutation as much as possible

Slide 38

Slide 38 text

How to FP avoid side-effects/mutation as much as possible at least keep them as private as possible in OO

Slide 39

Slide 39 text

How to FP avoid side-effects/mutation as much as possible at least keep them as private as possible in OO treat variables as immutable (constants/final)

Slide 40

Slide 40 text

How to FP avoid side-effects/mutation as much as possible at least keep them as private as possible in OO treat variables as immutable (constants/final) return values (output) based on params (input) only

Slide 41

Slide 41 text

How to FP avoid side-effects/mutation as much as possible at least keep them as private as possible in OO treat variables as immutable (constants/final) return values (output) based on params (input) only play with a functional language

Slide 42

Slide 42 text

Functional Programming what why how example

Slide 43

Slide 43 text

Example

Slide 44

Slide 44 text

Example

Slide 45

Slide 45 text

Example

Slide 46

Slide 46 text

"Conventional programming languages are growing ever more enormous, but not stronger. Inherent defects at the most basic level cause them to be both fat and weak: their primitive word- at-a-time style of programming inherited from their common ancestor -- the von Neumann computer, their close coupling of semantics to state transitions, their division of programming into a world of expressions and a world of statements, their inability to effectively use powerful combining forms for building new programs from existing ones, and their lack of useful mathematical properties for reasoning about programs." John Backus, known for Fortran, Algol and BNF

Slide 47

Slide 47 text

Thank You igstan.ro | [email protected] | @igstan

Slide 48

Slide 48 text

Questions? igstan.ro | [email protected] | @igstan