Welcome to the talk!
=<< What's up with that Title? >>=
=<< What's up with that Title? >>=
It’s functions, pure functions! Pure functions and their values, PURE FUNCTIONS FOREVER AND FOREVER AND FOREVER A HUNDRED YEARS monad... some... things... Me and monads runnin' around and...applicative functor time... a- all day long forever... All a - a hundred days applicatives and functors! Forever a hundred times.... OVER and over monad transformers... adventures dot com... W W W dot at lambda calculus and category theory dot com w..w..w... function composition adventures... Ah- hundred years… Every minute referential... transparency dot com.... w w w a hundred times... composition dot com...
Fig 1.1 What most people thing a typical functional programming advocate looks like
=<< Obligatory Quote >>=
=<< Obligatory Quote >>=
If you wish to build a ship, do not divide the men into teams and send them to the forest to cut wood. Instead, teach them to long for the vast and endless sea.
=<< Obligatory Quote >>=
If you wish to build a ship, do not divide the men into teams and send them to the forest to cut wood. Instead, teach them to long for the vast and endless sea.

- Some French Guy. Idk. Who cares, I'm not cultured. I'm Australian.
=<< What is this Talk About? >>=
=<< What is this Talk About? >>=

This talk is not about:

  • Haskell
  • Convincing you to stop using whichever language you like
  • Maths nonsense
  • So what is it about?
=<< What is this Talk About? >>=
Perspective
=<< What is Functional Programming? >>=
Programming with functions.
=<< What is Functional Programming? >>=
Programming with functions.

No, really. Everything is a function.
=<< What is a Function? >>=
A mapping between sets that associates every element of the first set to exactly one element of the second set.
=<< What is a Function? >>=

No equivalent constructs for:

  • For loops
  • While loops
  • Gotos
  • Variables*
  • Probably a bunch of other constructs I forgot
*In pure functional programming, there are true variables. That is, once you declare the value of a variable, you cannot change it. Contrast this with procedural languages where you can reassign a variable whenever you like.
=<< Huh? >>=
=<< Huh? >>=
Who in their right mind would wanna do that?!
=<< Huh? >>=

Why tho?

  • Learning is good
  • Brain plasticity
  • Greater perspective
=<< Paradigms >>=
Paradigms
=<< Paradigms >>=
Declarative
Functional
  • Haskell
  • Elm
  • Elixir
  • Clojure
Imperative
Procedural
  • PHP
  • C
  • Java
  • DamoScript
=<< Gramatical Mood >>=
Declarative A sentence which expresses a statement of fact.
  • He runs.
  • I like climbing.
  • Ice is cold.
  • Mathieu is shredded.
Imperative A sentence which expresses instructions, or requests.
  • Shut the door.
  • Don't eat my burger.
  • Let's go to the pub.
  • Don't make eye contact with Mathieu.
=<< Gramatical Mood >>=
Declarative This is this.
Imperative Do this.
=<< Big Brain Moment >>=
=<< Big Brain Moment >>=
Programming languages ARE human languages.
=<< Why is declaritive mood good? >>=
=<< Why is declaritive mood good? >>=
Atemporality
=<< Why is declaritive mood good? >>=
Independant of or unaffected by time.
=<< Why is declaritive mood good? >>=
Declarative programs express what they actually do Leaving more "brain space" to focus on solving the problem.
=<< To Recap >>=

Why tho?

  • Because sometimes there is such a thing as too much freedom
  • Functional programming is awesome because it stops you shooting yourself in the foot
  • "Constraints liberate, liberties constrain"
  • Some problems are simply very difficult to solve in an imperative way.
  • Especially when we are talking about events that are happening in parallel and may run at different speed/times
  • In the imperative paradigm, you quite easily come up against data races by virtue of the way the program is expressed
=<< Some Code (Finally) >>=
=<< Some Code (Finally) >>=
Enough of this philosophy and linguistics mumbo jumbo, already!
=<< Some Code (Finally) >>=

The Great Dividers

Consider:

x = x + 1;
and:
function repeat(x) {
                    return x + repeat(x);
                    }

OK, so what?

In the declaritive paradigm, this code hangs while this code runs. In the imperative paradigm this code hangs, while this code runs.
=<< Some Code (Finally) >>=
x = x + 1;
Declarative "x is the same as itself plus one."




Complete nonsense!
Imperative "Evaluate the thing on the right of `=` then store it in the thing on the left of `=`."


A list of instructions that can be followed.
=<< Some Code (Finally) >>=
function repeat(x) {
    return x + repeat(x);
}
Declarative "The repeat of `x` is `x` appended to the repeat of `x`"


An infinite list of `x`!
Imperative "To evaluate the repeate of `x`, first evaluate the repeat of `x`"


...Yeah, you see the problem?
=<< Big Brain Moment >>=
Programming languages ARE human languages.
=<< Some Code (Finally) >>=

Real Haskell Code That Runs

repeat x = x ++ repeat x
threeFs = take 3 (repeat "f")

> "fff"
            
=<< Some Code (Finally) >>=

Real JavaScript Code That Hangs

function repeat(x) {
    return x + repeat(x);
}

threeFs = repeat("f").substr(0,3);

> InternalError: too much recursion
            
=<< Big Brain Moment >>=

What did declaritive mode give us?

  • Atemporality
  • The ability to wield infinity!
=<< Promises >>=

Promises

=<< Promises >>=
>:(
>:(
>:(
>:(
>:(
>:(
>:(
>:(
>:(
>:(
Promises do not make things asynchronous!
=<< Promises >>=

What problems do promises solve?

  • Asynchronous request management
  • Error handling for computations which may fail
  • Probably more too

What are promises then?

  • A value (which may or may not be available yet) wrapped in some additional context
  • Functions to instantiate the wrapper (Promise.resolve, Promise.reject)
  • A rule for composing these wrapped values (then)
=<< Promises >>=

Terminology/syntax recap

JavaScript arrow functions

x => x + 1;
is equivalent to:
function(x) {
    return x+1;
}

Composition

A method of combining two things of the same type in to another thing that is also of the same type
=<< Promises >>=

Promise composition

The `then` method of a promise accepts a function as an argument. This function takes a value and returns a new promise. The new promise "combines" the previous two using the "composition rule" given to `then`.
Promise.resolve("Some value").then(x => Promise.resolve(x + " and another value")).then(x => Promise.resolve(x + " and another one!"));
There are three promises in the above snippet. One, two, three.
Promise.resolve("Some value").then(x => Promise.reject("It's all gone wrong")).then(x => Promise.resolve(x + " and another one!"));
The above snippet still results in a promise, but it is a "failed" one. Any subsequent `then` after the `reject` has no effect.
=<< Promises >>=

OK great but who cares?

  • We are declaring how we want promises to compose
  • The order that the promises actually resolve their values in is not important
    • In other words, we don't have to worry about timing anymore
  • We can declare a failure anywhere in the chain
=<< Promises >>=
atemporality?
declaritive?
functions?
composition?
=<< Promises >>=

Woah!

JavaScript

Promise.resolve("We start here")
                .then(x => Promise.resolve(x + " then get here"))
                .then(x => Promise.resolve(x + " and finally here!"))

Haskell

Right("We start here")
                >>= (\x -> Right (x ++ " then get here"))
                >>= (\x -> Right (x ++ " and finally here!"))
=<< Promises >>=

Woah!

JavaScript

Promise.resolve("We start here")
                .then(x => Promise.resolve(x + " then get here"))
                .then(x => Promise.reject("Oh noes!"))
                .then(x => Promise.resolve(x + " and finally here!"))

Haskell

Right("We start here")
                >>= (\x -> Right (x ++ " then get here"))
                >>= (\x -> Left ("Oh noes!"))
                >>= (\x -> Right (x ++ " and finally here!"))
=<< Composition >>=

Composition

=<< Composition >>=
=<< Composition >>=
If we can go from here to here
=<< Composition >>=
If we can go from here to here
And we can go from here to here
=<< Composition >>=
If we can go from here to here
And we can go from here to here
Then the composition (if it exists) goes from here to here
=<< Composition >>=

OK great but who cares?

=<< Composition >>=

OK great but who cares?

Big problems can often be chopped up in to smaller, easier to solve problems. If we can be clever about how we chop them up, such that the solutions to the individual problems can compose together to form a full solution, then we can infinitely speed up the process by adding more workers!
=<< Composition >>=

Examples

  • The pyramids
  • The LHC
  • McDonald's
  • Moodle!
=<< Composition >>=
=<< Composition >>=

Do you get one "leet" dev to solve the whole thing?

With these biceps I can solve ANYTHING
=<< Composition >>=

No, you get friends to take a piece and help!

henlo
henlo
henlo
henlo
henlo
henlo
=<< Composition >>=
Composition is nature's greatest hack
=<< Composition >>=

What's this got to do with FP?

When writing programs (as an individual in this case, not as a group) we naturally want to break the solution up in to "building blocks" that we put together to solve the problem (it's composition again).
The building blocks you use matter. Some compose better than otheres. Because of all the restrictions the functional paradigm places on the programmer (lack of mutation, lack of control flow), functions in a pure language are naturally well-suited to composition.
This is becoming more relevant than ever in the age of parallel computing
=<< Composition >>=

What's this got to do with FP?

When writing programs (as an individual in this case, not as a group) we naturally want to break the solution up in to "building blocks" that we put together to solve the problem (it's composition again).
The building blocks you use matter. Some compose better than otheres. Because of all the restrictions the functional paradigm places on the programmer (lack of mutation, lack of control flow), functions in a pure language are naturally well-suited to composition.
This is becoming more relevant than ever in the age of parallel computing
Thanks for listening!!