FullStack 2016 - Elm - Speaker Deck

Slide 1

Slide 1 text

FP lessons from Haskell & Elm Elm app with d3 displays & solves a puzzle How to create a basic elm app, the exact pattern that influenced redux FP building blocks can feel like huge obstacles and how to make use of them IoT gadgets coded with FP Never been easier to build elm app but how easy is that?

Slide 2

Slide 2 text

Please watch the cartoons They are there for your education. Thank you.

Slide 3

Slide 3 text

Questions welcome! Time is a bit tight, but it's fine to ask questions. One to one chats better for the bar later or emails My contact details are at the end, do get in touch Also fine not to understand everything at once, I'm working through a lot of this myself Yesterday's keynote speaker said earlier this year that we are all writing good code now. I completely agree, this talk is to present new ideas, not to downplay anything we're doing now.

Slide 4

Slide 4 text

Don't believe everything you hear! I'm not a Haskell programmer, I just write Haskell programs What follows is how I see/understand things It may or may not exactly match the books, wikis, academic papers, mathematical proofs etc.

Slide 5

Slide 5 text

FP examples LINQ RxJs Redux d3

Slide 6

Slide 6 text

Why might any of this be useful?

Slide 7

Slide 7 text

Dev projects start off so well

Slide 8

Slide 8 text

So, how does this happen?

Slide 9

Slide 9 text

Elm, what's with that, then ● Node got me back doing FP, I've been looking to improve since then ● We hear a lot about Elm and it's benefits ● However, many people try it and drop it quickly ● Why? Is it useful or not?

Slide 10

Slide 10 text

FP example code ● Wrote Haskell program to solve computer game puzzle ● Converted Haskell to interactive Elm app – It simulates the puzzle and calculates the solution ● We'll consider the solution(s) ● Can we take lessons from FP back to js ? – We'll see the Elm/Haskell code converted to Angular2,RxJs, Typescript app ● Is elm a temporary fad or part of all our futures?

Slide 11

Slide 11 text

Time travel debugging DEMO !

Slide 12

Slide 12 text

Game

Slide 13

Slide 13 text

Game - puzzle

Slide 14

Slide 14 text

Time-travel in PuzzleLand ● Does someone want to click some buttons? ● How do we get back from here? ● Anyone fancy a play with an IoT gadget?

Slide 15

Slide 15 text

We are already FP coders! ● Lisp (created 1956) is now on Esp8266 – it's got me thinking! ● Map, reduce etc ● The blueprint for Js, with some C constructs on top. – No wonder we have such a great time with it! – Private data closure pattern from lisp ● Abelson and Sussman’s classic Structure and Interpretation of Computer Programs ● ES6 just catching up Lisp 30 years later – backticks, symbols

Slide 16

Slide 16 text

How to build a basic Elm app ● Model (one String!) ● Update, View ● Html is code Pro - great for refactoring Con - rebuild for changes ● Fully uni-directional – Just like RxJs, Redux etc

Slide 17

Slide 17 text

Scientific jargon to follow

Slide 18

Slide 18 text

FP building blocks (or obstacles!) ● Unfamiliar data types ● Type signatures ● Quick interactive demo of lists ● No loops, you're kidding ? – Elm-syntax page, search for loop, there's nothing there! – Map, filter etc

Slide 19

Slide 19 text

Haskell type strictness Haskell is relentless in type checking. No casts or ignore flags … Can decide not to specify type – Haskell complains if this does not hold up It does have the notion of type groups – num, equality … (C# generic constraints)

Slide 20

Slide 20 text

Haskell - immutability Nothing changes, we create new things only Functions have no side effects - Same input - same output, always except for when we have side effects, but let's move on!

Slide 21

Slide 21 text

FP types The usual Int, Float, String, Bool suspects Lists are like arrays Any length – can only hold a single type Tuples are like, er, multiples ? Fixed length – may store multiple types Algebraic create our own from the above (diy) plus a part we specify (e.g. Tree Int) Records object-like syntactic sugar in Elm, a bit duck type-y

Slide 22

Slide 22 text

Lists – quick intro Build [1,2,3] like this 1: 2: 3: [] Pass as params like this xs entire list x:xs x is “head”, xs is “tail” (destructuring like es6) FP functions are designed to work with head of list as much as possible

Slide 23

Slide 23 text

Recursion, pattern matching Pattern matching – a bit like if … then … or switch, case factorial 0 = 1 end condition Factorial n = n * factorial (n – 1) recurse step

Slide 24

Slide 24 text

Recursion, pattern matching e.g. leng [1, 2, 3] Haskell - leng [] = 0 end condition leng (x:xs) = 1 + leng xs recurse step Elm - leng xs = Case xs of [] -> 0 end condition x::xs -> 1 + leng xs recurse step

Slide 25

Slide 25 text

Map - type signature (a -> b) -> List a -> List b e.g. List.map (\x -> x + 1) [1, 2, 3]

Slide 26

Slide 26 text

Elm state FP langs have different styles of state handling Haskell – I/O monad (leave for now) Elm state – a bit like juggling, state never touches the ground once started

Slide 27

Slide 27 text

Strange stuff on the way This might all seem a bit weird … Feel free to let it go by !

Slide 28

Slide 28 text

Solution – List operations Wheels represented as lists of Ints One list is a Wheel Pos TurnWheel int Wheel Pos drop, take are list operations - ideal for small lists, slower for larger lists

Slide 29

Slide 29 text

Turn Wheel WheelPos turn WheelPos IN OUT

Slide 30

Slide 30 text

Solution - Recursion List of Wheel Pos Wheel Loop Not a great name, any suggestions? Created by buildWheelLoop Gives us secLoop, thrLoop and ansLoop As shown in app

Slide 31

Slide 31 text

build WheelLoop List WheelPos newP os WheelLoop WheelLoop From StartPos WheelPos WheelLoop Is called by

Slide 32

Slide 32 text

Solution - Map Given first Wheel, and secLoop Use map to go through secLoop and attach to copy of first item This creates a LoopsPermutation - two loops mixed, perhaps In effect, basis for solution/algorithm – see in app Here, Haskell code is little different from any modern language (that uses an anonymous function)

Slide 33

Slide 33 text

TwoWheel Perms WheelPos Wheel Loop List LoopsPermutation ThreeWheel Perms WheelPos Wheel Loop List LoopsPermutation Wheel Loop

Slide 34

Slide 34 text

Solution – sumPlusPerms Go through permutations and add anwers to each set Add across lists – this is what I wondered about for nought and crosses Here it seems natural enough - for a single column

Slide 35

Slide 35 text

Solution – findSpecificAnswer Go through permutations and anwers Trawl through answers, compare to answers loop Dropwhile is part of a range of elegant functions

Slide 36

Slide 36 text

Type transformations Quite like the sense of types being transformed

Slide 37

Slide 37 text

Something better Solution works – not sure it scales well More on this later Feels big and unwieldy, all those permutations

Slide 38

Slide 38 text

Something better, surely

Slide 39

Slide 39 text

Something better I had this in mind when I started out

Slide 40

Slide 40 text

Solution – Second version Wanted a way not to build perms items So keep memory use limited to a small amount Since then, have heard about “constant space” Created a revised version of this, which filters the items before processing

Slide 41

Slide 41 text

Solution – Third version Based on early idea More memory per iteration than second But limited to 2 wheel perms So scales infinitely beyond that

Slide 42

Slide 42 text

FP on IoT ● All the gadgets are programmed with FP ● FP can be as lightweight as Lua ● These programs were written or prototyped in Haskell and Elm, then converted ● Bit of a proof of concept, much like micro-python

Slide 43

Slide 43 text

Lessons from fp ● Write code, optimise later ● Write small code, test it, fit together – pattern from lisp 30 years ago, much like tdd – Do the same with data structures ● Types show transformations, search for type pattern, not just code ● Tail recursion (waiting on Node for this!)

Slide 44

Slide 44 text

Haskell – Lazy evaluation Other languages find one item easy

Slide 45

Slide 45 text

Haskell – Lazy evaluation But many are overwhelming

Slide 46

Slide 46 text

Haskell – Lazy evaluation

Slide 47

Slide 47 text

Elm/FFI/js/d3 ● Works nicely, but raw js can kill off elm just like anything else ● Mechanism for swapping data works fine and it intuitive

Slide 48

Slide 48 text

My views ● I find that I really trust Elm ● Pros – Solid - failure of Elm app never occurred to me – Type checking saves a lot of work ● Cons – Fiddly, breaking changes, wider adoption chances

Slide 49

Slide 49 text

Bonus code - RxJs Uni-directional UI RxJs – deals with infinite streams we can choose to get first item only Typescript – preserves Haskell types They stand out clearly Are they useful? What have we gained or lost by this functional programming style ?

Slide 50

Slide 50 text

Bonus code – C# Linq Not so much done here, but get a flavour Like that the Haskell types transfer well We have lazy eval – we declare operations But nothing happens until x amount of data requested What have we gained or lost by this functional programming style ?

Slide 51

Slide 51 text

Thanks for listening Github: https://github.com/jkbits1 Repo: talkUI (nodejs server for apps) HaskellElmTalk (code only) [email protected] Resources: http://learnyouahaskell.com/ http://guide.elm-lang.org/ https://en.wikibooks.org/wiki/Haskell Lisp original repo: https://github.com/yesco/esp-lisp/wiki