Introduction to type systems & Elm

Slide 1

Slide 1 text

Introduction to type systems & ELM

Slide 2

Slide 2 text

$ cat whoami.elm name : Anler twitter: @anler tech : PHP -> Python -> JS -> Scala

Slide 3

Slide 3 text

$ cat whoami.elm name : Anler twitter: @anler tech : PHP -> Python -> JS -> Scala

Slide 4

Slide 4 text

Disclaimer This is not a rant, this is a sales pitch. I don’t want to attack your community, but I do want to steal some brains for mine I love the work you do as a community and I wish we could have the same in ours.

Slide 5

Slide 5 text

The need of a type system

Slide 6

Slide 6 text

History of Programming as seen from JS JavaScript Assembly M aintainability problem s C Java

Slide 7

Slide 7 text

History of Programming as seen from JS JavaScript Assembly M aintainability problem s M em ory m anagem ent  problem s C Java

Slide 8

Slide 8 text

History of Programming as seen from JS JavaScript Assembly M aintainability problem s M em ory m anagem ent  problem s Expressivity problem s C Java

Slide 9

Slide 9 text

History of Programming as seen from JS JavaScript Assembly M aintainability problem s M em ory m anagem ent  problem s Expressivity problem s M aintainability problem s C Java

Slide 10

Slide 10 text

There’s a limit in the amount of things we can handle at a time. In order to increase that limit we need abstractions

Slide 11

Slide 11 text

But with abstractions there come other problems: maintainability, debugging, learning curve

Slide 12

Slide 12 text

Learning curve is solved with familiarity

Slide 13

Slide 13 text

Debugging is solved with tooling

Slide 14

Slide 14 text

But for solving maintainability we need something else…

Slide 15

Slide 15 text

Stop thinking: I don’t need this nonsense

Slide 16

Slide 16 text

Before thinking “Why should I learn yet another language…” let’s keep our minds open.

Slide 17

Slide 17 text

“Technology changes quickly, people’s minds change slowly”

Slide 18

Slide 18 text

Same situation in the past Assembly Binary

Slide 19

Slide 19 text

"why would you want more than machine language?”

Slide 20

Slide 20 text

Same situation in the past Fortran Assembly

Slide 21

Slide 21 text

“Can programming be liberated from the Von Neumann Style?

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Same situation in the past Functional Imperative Static Types Dynamic Types Types Tests … …

Slide 24

Slide 24 text

Typesystems & Methods for ensuring correctness

Slide 25

Slide 25 text

When writing software, program correctness is an issue of increasing importance because we are living in a world with increasing reliance on computer programs

Slide 26

Slide 26 text

Formal methods Algebraic Speciﬁcation Languages Denotational Semantics Hoare Logic Modal Logics

Slide 27

Slide 27 text

Lightweight Formal methods (of much more modest power) Model checkers Run-time monitoring Type systems the most popular

Slide 28

Slide 28 text

A type system is a tractable syntactic method for proving the absence of certain program behaviours by classifying phrases according to the kinds of values they compute

Slide 29

Slide 29 text

Strong Weak Static Dynamic The type system is more pedantic and usually forces you to be more explicit. Ex:   - 3 + “hola” is not accepted ❌ - if “hola” … ❌ The type system is less strict and usually performs implicit conversions  for you. Ex: - 3 + “hola” is accepted ✅ - if “hola” … is accepted ✅ The type analysis of expressions is performed at compile time. The type analysis of expressions is performed at run time.

Slide 30

Slide 30 text

Strong Weak Static Dynamic

Slide 31

Slide 31 text

A type system is usually conservative, it has to be because a type system can prove the absence of some bad program behaviours, but they cannot prove their presence!

Slide 32

Slide 32 text

A type system is usually conservative, it has to be because a type system can prove the absence of some bad program behaviours, but they cannot prove their presence! Program testing can be used to prove the presence of bugs, but never show their absence!

Slide 33

Slide 33 text

Type systems and testing complement

Slide 34

Slide 34 text

What type systems are good for?

Slide 35

Slide 35 text

Detecting errors  Documentation Abstraction Language Safety Efficiency What type systems are good for?

Slide 36

Slide 36 text

Detecting errors  Documentation Abstraction Language Safety Efficiency What type systems are good for?

Slide 37

Slide 37 text

Detecting errors  Documentation Abstraction Language Safety Efficiency Those are key for effective Functional Programming What type systems are good for? And here I will talk again about FP :P

Slide 38

Slide 38 text

When I refer to FP I mean constructing the whole program as a composition of referentially transparent functions, not programs where you just use map, ﬁlter or lambdas.

Slide 39

Slide 39 text

FP + Type System + Testing

Slide 40

Slide 40 text

Why Functional Programming?

Slide 41

Slide 41 text

What are the advantages of Functional Programming?

Slide 42

Slide 42 text

1. Functions are very simple Output ➡ Input ➡

Slide 43

Slide 43 text

2. Functions are declarative Output ➡ Input

Slide 44

Slide 44 text

3. Functions always compose ➡ ➡ ➡ The same can’t be said of OOP, the answer would be: it depends. Also I don’t refer to JS functions, those are procedures and their composition is not guaranteed

Slide 45

Slide 45 text

Composition is the way of controlling complexity

Slide 46

Slide 46 text

FP problems when used outside functional languages

Slide 47

Slide 47 text

No Tail Call Elimination  FP langs transform tail-call (mutually-)recursive functions into while loops Performance penalty of using functions FP langs eliminate functions by inlining-them Performance penalty of boxed data types FP langs eliminate those boxes FP problems when used outside functional languages

Slide 48

Slide 48 text

No content

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

Greenspun’s Tenth Rule:     Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. Steele & Crockford’s Corollary:     Any sufficiently interesting JavaScript library contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Haskell.

Slide 53

Slide 53 text

Functional programming outside functional langs is just too expensive.

Slide 54

Slide 54 text

That’s the main selling point of Elm/ PureScript/Haskell

Slide 55

Slide 55 text

Why ELM?

Slide 56

Slide 56 text

Elm is a purely-functional static programming language for frontend web development, that forces the usage of total functions and thus is claimed as a zero- runtime errors language.

Slide 57

Slide 57 text

A total function length : List a -> Int

Slide 58

Slide 58 text

A partial function head : List a -> a

Slide 59

Slide 59 text

What happens if the list if empty? head : List a -> a

Slide 60

Slide 60 text

head : List a -> a If you invent a new value null and treat it as an ‘a’ you are augmenting the set ‘a’ with a new possibility (null) that has to be checked always. What happens if the list if empty?

Slide 61

Slide 61 text

Slide 62

Slide 62 text

a ⋃ null This looks like inheritance in OOP

Slide 63

Slide 63 text

A partial (useless) total function because null will never have the same properties as a head : List a -> a someOp = head [] + 3 Nonsense, null with a number has no well deﬁned meaning! This leads to null propagation. null

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

Elm has no null, instead you use the Maybe type to express possibility of a value that might not be there.

Slide 66

Slide 66 text

a Nothing The Maybe a type

Slide 67

Slide 67 text

A partial total function head : List a -> Maybe a someOp = withDefault 0 (head []) + 3 We are forced to contemplate the possibility of failure and act  accordingly Nothing Maybe

Slide 68

Slide 68 text

ELM 101

Slide 69

Slide 69 text

Introduction to types

Slide 70

Slide 70 text

What is a type?

Slide 71

Slide 71 text

A type is a name for a collection of values : Bool True False The Bool type Inhabitants

Slide 72

Slide 72 text

The singleton or unit type : () () The empty tuple  type 1 inhabitant

Slide 73

Slide 73 text

The empty or void type : Never The Never type No inhabitants

Slide 74

Slide 74 text

What are the most common types?

Slide 75

Slide 75 text

a -> b String Char Bool number The type of functions from a to b The type of all strings The type of all characters The type of all bool (True and False) The type of all   numbers

Slide 76

Slide 76 text

What is a constructor?

Slide 77

Slide 77 text

A constructor is the constant that represents or the function that constructs a value of a type : Bool True False I’m the constant representing the falsy value I’m the constant representing the truthy value

Slide 78

Slide 78 text

What is a data type declaration?

Slide 79

Slide 79 text

It is a way of deﬁning a new type or a shape that represents several types type Bool = True | False > True : Bool > False : Bool Bool type deﬁned Type can be constructed with either True or False constants (product)

Slide 80

Slide 80 text

These are the lego pieces (the primitive data types)

Slide 81

Slide 81 text

It is a way of deﬁning a new type or a shape that represents several types type Duple a b = Duple a b    > Duple True False  : Duple Bool Bool  > Duple “hello” ‘h’  : Duple String Char Shape of all the duple types deﬁned I’m the function that knows how to construct a value of type ‘Duple a b’ Need both: a and b (coproduct or sum)

Slide 82

Slide 82 text

The context provides the info you need: List: non-determinism Maybe: Failure Tuple: Alternation

Slide 83

Slide 83 text

What is a type alias declaration?

Slide 84

Slide 84 text

It is just another name for an existing type or type shape type alias Binary = Bool

Slide 85

Slide 85 text

What is a record type?

Slide 86

Slide 86 text

It is just like a named tuple > r = { x = “foo”, y = False } r : { x : String, y : Bool } > r.x “foo” : String > r.y False : Bool

Slide 87

Slide 87 text

What is pattern matching?

Slide 88

Slide 88 text

It is the way to know which constructor was used for creating a value of a given data type case boolValue of True -> “created by True” False -> “created by False” case stringValue of “hi” -> “created by “hi”” _ -> “dunno”

Slide 89

Slide 89 text

Static html example

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

No content

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

Dynamic html example

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

No content

Slide 97

Slide 97 text

No content

Slide 98

Slide 98 text

No content

Slide 99

Slide 99 text

No content

Slide 100

Slide 100 text

No content

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

No content

Slide 103

Slide 103 text

No content

Slide 104

Slide 104 text

No content

Slide 105

Slide 105 text

No content

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

No content

Slide 108

Slide 108 text

Wrapping Up

Slide 109

Slide 109 text

Functional programming combined with a good type system is a very good idea, maximises the advantages of each one (FP & type systems) and gives the developer more grip at controlling a project’s complexity because it makes explicit the side-effects in your application and brings them under control. 109

Slide 110

Slide 110 text

There’s no silver bullet

Slide 111

Slide 111 text

Programming languages are all about tradeoffs. In my case I’m more inclined to give up on a lot of things in exchange of fewer runtime errors.

Slide 112

Slide 112 text

website: elm-lang.org website: pragmaticstudio.com/courses/elm book: The little MLer book: Types and Programming Languages Resources

Slide 113

Slide 113 text

THANK YOU!