Opening Keynote: The Tyranny of Structurelessness

A presentation at Code BEAM Lite Amsterdam 2019 in November 2019 in Amsterdam, Netherlands by Brooklyn Zelenka

Slide 1

Slide 1

TS T RYU CRT UAR E LNE S SNN E SYS THE H H O W M O R E M E A N I N G F U L C O D E C A N M A K E Y O U R P R O J E C T M O R E R E S I L I E N T & M A I N TA I N A B L E H OF

Slide 2

Slide 2

THE TYRANNY OF STRUCTURELESSNESS For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce 🎤💧 EDSGER DIJKSTRA

Slide 3

Slide 3

THE TYRANNY OF STRUCTURELESSNESS For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce 🎤💧 EDSGER DIJKSTRA

Slide 4

Slide 4

THE TYRANNY OF STRUCTURELESSNESS What’s she on about? Elixir doesn’t have GOTOs… 🤔 THIS AUDIENCE

Slide 5

Slide 5

THE TYRANNY OF STRUCTURELESSNESS B R O O K LY N Z E L E N K A , @ e x p e d e

Slide 6

Slide 6

THE TYRANNY OF STRUCTURELESSNESS B R O O K LY N Z E L E N K A , @ e x p e d e • Cofounder/CTO at Fission • https://fission.codes • Make DevOps & Backend obsolete 😈 • Spending a lot of time with IPFS & DIDs • PLT & VM enthusiast • Ethereum Core Developer • Primary author of Witchcraft Suite & Exceptional

Slide 7

Slide 7

THE TYRANNY OF STRUCTURELESSNESS B R O O K LY N Z E L E N K A , @ e x p e d e • Cofounder/CTO at Fission • https://fission.codes • Make DevOps & Backend obsolete 😈 • Spending a lot of time with IPFS & DIDs • PLT & VM enthusiast • Ethereum Core Developer • Primary author of Witchcraft Suite & Exceptional

Slide 8

Slide 8

THE BIG IDEA

Slide 9

Slide 9

THE BIG IDEA 💭⚙🚀

Slide 10

Slide 10

THE BIG IDEA ONE-LINER

Slide 11

Slide 11

THE BIG IDEA ONE-LINER ✈ Work at a higher level 🛸

Slide 12

Slide 12

THE BIG IDEA LANGUAGE DESIGN REFLECTS INTENDED USE 🌐

Slide 13

Slide 13

THE BIG IDEA W H O ’S O RG LO O KS L I K E T H I S ?

Slide 14

Slide 14

THE BIG IDEA W H O ’S O RG LO O KS L I K E T H I S ? 🧠 ,

, ⚙

,

Slide 15

Slide 15

THE BIG IDEA W H O ’S O RG LO O KS L I K E T H I S ? 🧠 ,

, ⚙

,

Slide 16

Slide 16

THE BIG IDEA HOW ABOUT THIS? -

, ⚙ ,

,

Slide 17

Slide 17

THE BIG IDEA HOW ABOUT THIS? -

, ⚙ ,

,

Slide 18

Slide 18

THE BIG IDEA QUESTIONS

Slide 19

Slide 19

THE BIG IDEA QUESTIONS We want more type of features over time. As a result, complexity grows at an exponential rate.

Slide 20

Slide 20

THE BIG IDEA QUESTIONS We want more type of features over time. As a result, complexity grows at an exponential rate. How do you make Elixir code more flexible and easier to reason about at scale?

Slide 21

Slide 21

THE BIG IDEA QUESTIONS We want more type of features over time. As a result, complexity grows at an exponential rate. How do you make Elixir code more flexible and easier to reason about at scale? Do you think that the patterns we use today are the best possible patterns for software?

Slide 22

Slide 22

THE BIG IDEA QUESTIONS We want more type of features over time. As a result, complexity grows at an exponential rate. How do you make Elixir code more flexible and easier to reason about at scale? Do you think that the patterns we use today are the best possible patterns for software? How will you write code in 2020, 2025, and 2050?

Slide 23

Slide 23

THE BIG IDEA CORE We need to evolve our approach: focus on domain and structure!

Slide 24

Slide 24

THE BIG IDEA CORE We need to evolve our approach: focus on domain and structure! ✨ 🦄 🚀

Slide 25

Slide 25

IN THE LARGE

Slide 26

Slide 26

IN THE LARGE 🌟

Slide 27

Slide 27

IN THE LARGE C O D E Y O U U S E D TO W R I T E Imperative

Slide 28

Slide 28

IN THE LARGE C O D E Y O U U S E D TO W R I T E Imperative

Slide 29

Slide 29

IN THE LARGE “GOOD” ELIXIR Imperative

  • Functional core, imperative shell

Slide 30

Slide 30

IN THE LARGE “GOOD” ELIXIR Imperative λ

  • Functional core, imperative shell

Slide 31

Slide 31

IN THE LARGE Imperative 3LA FUTURE 🚀 λ

  • Generalization of hexagonal/12-factor

Slide 32

Slide 32

IN THE LARGE Imperative 3LA FUTURE 🚀 Semantic DSL / OO λ

  • Generalization of hexagonal/12-factor

Slide 33

Slide 33

IN THE LARGE PROP + MODEL TEST

Slide 34

Slide 34

GOTOS CONSIDERED HARMFUL

Slide 35

Slide 35

GOTOS CONSIDERED HARMFUL W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦶 🔫

Slide 36

Slide 36

GOTOS CONSIDERED HARMFUL W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦶 🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible • Highly concrete • Huge number of implicit states

Slide 37

Slide 37

GOTOS CONSIDERED HARMFUL W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦶 🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible • Highly concrete • Huge number of implicit states Line 1 Line 2 Line 3 Line 4 Line 5 — GOTO Line 6

Slide 38

Slide 38

GOTOS CONSIDERED HARMFUL W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦶 🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible • Highly concrete • Huge number of implicit states Line 1 Line 2 Line 3 Line 4 Line 5 — GOTO Line 6

Slide 39

Slide 39

GOTOS CONSIDERED HARMFUL W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦶 🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible • Highly concrete • Huge number of implicit states Line 1 Line 2 Line 3 Line 4 Line 5 — GOTO Line 6

Slide 40

Slide 40

GOTOS CONSIDERED HARMFUL W H AT ’ S S O B A D A B O U T H AV I N G C O N T R O L? 🦶 🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible • Highly concrete • Huge number of implicit states Line 1 Line 2 Line 3 Line 4 Line 5 — GOTO Line 6 💥

Slide 41

Slide 41

GOTOS CONSIDERED HARMFUL STRUCTURED PROGRAMMING while

Slide 42

Slide 42

GOTOS CONSIDERED HARMFUL STRUCTURED PROGRAMMING • Subroutines • Loops • Switch/branching • Named routines while

Slide 43

Slide 43

GOTOS CONSIDERED HARMFUL T H E N E X T G E N E R AT I O N 🚀

Slide 44

Slide 44

GOTOS CONSIDERED HARMFUL T H E N E X T G E N E R AT I O N 🚀 • Functions • Map • Reduce • Filter • Constraint solvers

Slide 45

Slide 45

GOTOS CONSIDERED HARMFUL TRADEOFFS

Slide 46

Slide 46

GOTOS CONSIDERED HARMFUL TRADEOFFS • Exchange granular control for structure • Meaning over mechanics • More human than machine • Safer! • Spectrum • Turing Tarpit • Church Chasm • Haskell Fan Fiction

Slide 47

Slide 47

250 GOTOS CONSIDERED HARMFUL PAY O F F Structured Unstructured

Slide 48

Slide 48

250 GOTOS CONSIDERED HARMFUL COMPLEXITY PAY O F F Structured Unstructured TIME

Slide 49

Slide 49

GOTOS CONSIDERED HARMFUL PAY O F F 1000 COMPLEXITY 750 500 Unstructured 250 TIME Structured

Slide 50

Slide 50

GOTOS CONSIDERED HARMFUL PAY O F F 1000 COMPLEXITY 750 500 Unstructured 250 TIME Structured

Slide 51

Slide 51

GOTOS CONSIDERED HARMFUL PAY O F F 1000 COMPLEXITY 750 500 Unstructured 250 TIME Structured

Slide 52

Slide 52

ON COMPLEXITY

Slide 53

Slide 53

ON COMPLEXITY

Slide 54

Slide 54

COMPLEXITY

Slide 55

Slide 55

COMPLEXITY

Slide 56

Slide 56

COMPLEXITY THE BAD KIND ☠

Slide 57

Slide 57

COMPLEXITY THE BAD KIND ☠ • Probably pretty familiar with this • Euphemism for • Complicated • Inconsistent • No plan • “Unstructured mess”

Slide 58

Slide 58

COMPLEXITY GOOD COMPLEXITY = DEEP What do these have in common? (a+b)/a ~ a / b

Slide 59

Slide 59

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 60

Slide 60

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 61

Slide 61

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 62

Slide 62

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 63

Slide 63

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 64

Slide 64

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 65

Slide 65

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 66

Slide 66

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 67

Slide 67

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 68

Slide 68

COMPLEXITY ORTHOGONAL COMPLECTING

Slide 69

Slide 69

COMPLEXITY ORTHOGONAL COMPLECTING 🕐

Slide 70

Slide 70

COMPLEXITY ORTHOGONAL COMPLECTING 🕐 Structures: 4

Slide 71

Slide 71

COMPLEXITY ORTHOGONAL COMPLECTING 🕐 Structures: 4 Results: effectively limitless

Slide 72

Slide 72

COMPLEXITY C O M P L E X ! = C O M P L I C AT E D

Slide 73

Slide 73

COMPLEXITY C O M P L E X ! = C O M P L I C AT E D • Complex: interconnected parts • Complicated: difficult to understand

Slide 74

Slide 74

COMPLEXITY ACTO R A BYS S 🕳

Slide 75

Slide 75

COMPLEXITY ACTO R A BYS S 🕳 1. Each step is very simple 2. Reasoning about dynamic organisms is hard 1. Remember to store your data for crash recovery 2. Called collaborator may not be there 3. Complexity grows faster than linear 4. Find common factors — your abstraction

Slide 76

Slide 76

COMPLEXITY ACTO R A BYS S 🕳 1. Each step is very simple 2. Reasoning about dynamic organisms is hard 1. Remember to store your data for crash recovery 2. Called collaborator may not be there 3. Complexity grows faster than linear 4. Find common factors — your abstraction

Slide 77

Slide 77

FIGHTING GenSoup

Slide 78

Slide 78

FIGHTING GenSoup 🚫🍲⚔

Slide 79

Slide 79

FIGHTING GenSoup G O O D I N T E R FA C E S ! = G O O D A B S T R A C T I O N S

Slide 80

Slide 80

FIGHTING GenSoup G O O D I N T E R FA C E S ! = G O O D A B S T R A C T I O N S • GenServer & co are actually pretty low level • Please add some semantics! • Don’t reinvent the wheel every time 🎡 • Let’s look at a very common example

Slide 81

Slide 81

FIGHTING GenSoup ABSTRACTION

Slide 82

Slide 82

FIGHTING GenSoup ABSTRACTION

Slide 83

Slide 83

FIGHTING GenSoup SIMPLE CASE

Slide 84

Slide 84

FIGHTING GenSoup A S Y N C C A S E — B A S E L AY E R

Slide 85

Slide 85

FIGHTING GenSoup A S Y N C C A S E — I M P L E M E N TAT I O N

Slide 86

Slide 86

FIGHTING GenSoup W H AT D I D W E G E T ?

Slide 87

Slide 87

FIGHTING GenSoup W H AT D I D W E G E T ? • Common interface • Encapsulate the detail • Don’t have to think about mechanics anymore

Slide 88

Slide 88

FIGHTING GenSoup ABSTRACTION = FOCUS/ESSENCE

Slide 89

Slide 89

FIGHTING GenSoup ABSTRACTION = FOCUS/ESSENCE

Slide 90

Slide 90

FIGHTING GenSoup ABSTRACTION = FOCUS/ESSENCE 🙈

Slide 91

Slide 91

ON ABSTRACTION & DSLS

Slide 92

Slide 92

ON ABSTRACTION & DSLS N O T G E T T I N G T R A P P E D I N T H E D E TA I L S

Slide 93

Slide 93

ABSTRACTION & DSLS COMMONALITIES

Slide 94

Slide 94

ABSTRACTION & DSLS COMMONALITIES

Slide 95

Slide 95

ABSTRACTION & DSLS COMMONALITIES • They clearly have a similar structure • NOT equally expressive • Enumerable • Always converted to List • Witchcraft.Functor

Slide 96

Slide 96

ABSTRACTION & DSLS COMMONALITIES

Slide 97

Slide 97

ABSTRACTION & DSLS COMMONALITIES

Slide 98

Slide 98

ABSTRACTION & DSLS COMMONALITIES

Slide 99

Slide 99

ABSTRACTION & DSLS COMMONALITIES • Different, but also have similar structure • Not very pipeable because 2 paths • …lots of duplicate code

Slide 100

Slide 100

ABSTRACTION & DSLS COMMONALITIES • Different, but also have similar structure • Not very pipeable because 2 paths • …lots of duplicate code • Why limit to only to two ways?

Slide 101

Slide 101

ABSTRACTION & DSLS S TA R T F R O M R U L E S

Slide 102

Slide 102

ABSTRACTION & DSLS S TA R T F R O M R U L E S • Describe what the overall solution looks like

Slide 103

Slide 103

ABSTRACTION & DSLS S TA R T F R O M R U L E S • Describe what the overall solution looks like • Choose how it gets run contextually

Slide 104

Slide 104

ABSTRACTION & DSLS TWO-PHASE

Slide 105

Slide 105

ABSTRACTION & DSLS TWO-PHASE • Always a two-phase process • Abstract, then concrete • Do concretion at application boundary

Slide 106

Slide 106

ABSTRACTION & DSLS TWO-PHASE • Always a two-phase process • Abstract, then concrete • Do concretion at application boundary

Slide 107

Slide 107

ABSTRACTION & DSLS TWO-PHASE • Always a two-phase process • Abstract, then concrete • Do concretion at application boundary

Slide 108

Slide 108

ABSTRACTION & DSLS IMPROVING Kernel

Slide 109

Slide 109

ABSTRACTION & DSLS IMPROVING Kernel • Fallback keys • Bang-functions

Slide 110

Slide 110

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S

Slide 111

Slide 111

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity

Slide 112

Slide 112

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition

Slide 113

Slide 113

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition

Slide 114

Slide 114

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition

Slide 115

Slide 115

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values!

Slide 116

Slide 116

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values!

Slide 117

Slide 117

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values!

Slide 118

Slide 118

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values!

Slide 119

Slide 119

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! 🔁

Slide 120

Slide 120

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) 🔁

Slide 121

Slide 121

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) • More general (works everywhere) 🔁

Slide 122

Slide 122

ABSTRACTION & DSLS I M P R O V I N G K e r n e l — FA L L B A C K K E Y S • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) • More general (works everywhere) • Ad hoc function extension 🔁

Slide 123

Slide 123

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS

Slide 124

Slide 124

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS

Slide 125

Slide 125

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS

Slide 126

Slide 126

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS 💣

Slide 127

Slide 127

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS 💣

Slide 128

Slide 128

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS 💣 Abstracted out 💣 foo!/* from foo/*

Slide 129

Slide 129

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS 💣 Abstracted out 💣 foo!/* from foo/*

Slide 130

Slide 130

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS 💣 Abstracted out 💣 foo!/* from foo/* 🆗 ⏩

Slide 131

Slide 131

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS 💣 Abstracted out 💣 foo!/* from foo/* 🆗 ⏩ 💣

Slide 132

Slide 132

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS 💣 Works everywhere Any data Any error struct Abstracted out 💣 foo!/* from foo/* 🆗 ⏩ 💣 Any flow (esp. pipes) Super easy to test

Slide 133

Slide 133

ABSTRACTION & DSLS IMPROVING Kernel — BANG FUNCTIONS 💣 Works everywhere Any data Any error struct Abstracted out 💣 foo!/* from foo/* 🆗 ⏩ 💣 Any flow (esp. pipes) Super easy to test BONUS Disambiguate between nil value and actual errors

Slide 134

Slide 134

ABSTRACTION & DSLS N O T E : M E TA P H O R

Slide 135

Slide 135

ABSTRACTION & DSLS N O T E : M E TA P H O R Because it’s easier now

Slide 136

Slide 136

ABSTRACTION & DSLS N O T E : M E TA P H O R • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 Because it’s easier now

Slide 137

Slide 137

ABSTRACTION & DSLS N O T E : M E TA P H O R • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Slide 138

Slide 138

ABSTRACTION & DSLS N O T E : M E TA P H O R • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Slide 139

Slide 139

ABSTRACTION & DSLS N O T E : M E TA P H O R • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Slide 140

Slide 140

ABSTRACTION & DSLS N O T E : M E TA P H O R • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Slide 141

Slide 141

ABSTRACTION & DSLS N O T E : M E TA P H O R • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Slide 142

Slide 142

ABSTRACTION & DSLS W H AT ’ S G A I N E D ?

Slide 143

Slide 143

ABSTRACTION & DSLS W H AT ’ S G A I N E D ? • Clear • Composable • Greater reuse ♻ • User choice • Increased testability • Simple example: is_exception?/1 • Could still add protocol to get even more power

Slide 144

Slide 144

ABSTRACTION STO RY T E L L I N G 📚

Slide 145

Slide 145

ABSTRACTION STO RY T E L L I N G 📚

  1. Your code read like a story 2. We even see this in high-level goals of (e.g.) Phoenix 3. Go make some DSLs!

Slide 146

Slide 146

ABSTRACTION STO RY T E L L I N G 📚

  1. Your code read like a story 2. We even see this in high-level goals of (e.g.) Phoenix 3. Go make some DSLs!

Slide 147

Slide 147

ABSTRACTION & DSLS H O W T O E AT T H E E L E P H A N T

Slide 148

Slide 148

ABSTRACTION & DSLS H O W T O E AT T H E E L E P H A N T

Slide 149

Slide 149

ABSTRACTION & DSLS H O W T O E AT T H E E L E P H A N T • By feature?

Slide 150

Slide 150

ABSTRACTION & DSLS H O W T O E AT T H E E L E P H A N T • By feature? • By behaviour?

Slide 151

Slide 151

ABSTRACTION & DSLS H O W T O E AT T H E E L E P H A N T • By feature? • By behaviour? • By structure / properties!

Slide 152

Slide 152

ON STRUCTURE

Slide 153

Slide 153

ON STRUCTURE 🔺▫🔵

Slide 154

Slide 154

STRUCTURE T H E O N LY T H R E E R I G H T A N S W E R S

Slide 155

Slide 155

STRUCTURE T H E O N LY T H R E E R I G H T A N S W E R S 1

Slide 156

Slide 156

STRUCTURE T H E O N LY T H R E E R I G H T A N S W E R S 1 2

Slide 157

Slide 157

STRUCTURE T H E O N LY T H R E E R I G H T A N S W E R S 1 2 3

Slide 158

Slide 158

STRUCTURE T H E O N LY T H R E E R I G H T A N S W E R S 1 2 3

Slide 159

Slide 159

STRUCTURE A S S O C I AT I V I T Y

Slide 160

Slide 160

STRUCTURE A S S O C I AT I V I T Y • Not a data structure

Slide 161

Slide 161

STRUCTURE A S S O C I AT I V I T Y • Not a data structure • Not a function

Slide 162

Slide 162

STRUCTURE A S S O C I AT I V I T Y • Not a data structure • Not a function • An interface & rules!

Slide 163

Slide 163

STRUCTURE A S S O C I AT I V I T Y • Not a data structure • Not a function • An interface & rules!

Slide 164

Slide 164

STRUCTURE A S S O C I AT I V I T Y • Not a data structure • Not a function • An interface & rules! p a t e m w o l f e h t e t o (N ) r ho

Slide 165

Slide 165

STRUCTURE A SEMIGROUP ON…

Slide 166

Slide 166

STRUCTURE A SEMIGROUP ON…

Slide 167

Slide 167

STRUCTURE UNLAWFUL COUNTEREXAMPLE 🚨

Slide 168

Slide 168

STRUCTURE H OW TO C O M P O S E P RO P E RT I E S

Slide 169

Slide 169

STRUCTURE H OW TO C O M P O S E P RO P E RT I E S • A structure of structures • Keep it in your brain • Enforce with TypeClass

Slide 170

Slide 170

LE T ’S DO SOME THING WILD

Slide 171

Slide 171

LE T ’S DO SOME THING WILD ⚡🔥 POWER UP 🌪🌊

Slide 172

Slide 172

POWER UP EXPLICIT ASSUMPTIONS

Slide 173

Slide 173

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes

Slide 174

Slide 174

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes • Concurrency = partial order

Slide 175

Slide 175

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes • Concurrency = partial order t

Slide 176

Slide 176

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes • Concurrency = partial order t

Slide 177

Slide 177

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes • Concurrency = partial order t

Slide 178

Slide 178

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes • Concurrency = partial order t

Slide 179

Slide 179

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes • Concurrency = partial order t

Slide 180

Slide 180

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes • Concurrency = partial order • Monotonic • All loops must be linearized t

Slide 181

Slide 181

POWER UP EXPLICIT ASSUMPTIONS • Parallel pipes • Concurrency = partial order • Monotonic • All loops must be linearized • Properties • Serial composition • Parallel composition • Explicit evaluation strategy t

Slide 182

Slide 182

POWER UP PIPES++

Slide 183

Slide 183

POWER UP PIPES++

Slide 184

Slide 184

POWER UP PIPES++

Slide 185

Slide 185

POWER UP PIPES++

Slide 186

Slide 186

POWER UP CLEANUP

Slide 187

Slide 187

POWER UP CLEANUP

Slide 188

Slide 188

POWER UP C A R R I E R D ATA

Slide 189

Slide 189

POWER UP C A R R I E R D ATA

Slide 190

Slide 190

POWER UP C A R R I E R D ATA

Slide 191

Slide 191

POWER UP C A R R I E R D ATA

Slide 192

Slide 192

POWER UP C A R R I E R D ATA

Slide 193

Slide 193

POWER UP P ROTO C O L

Slide 194

Slide 194

POWER UP SIMPLE CASE

Slide 195

Slide 195

POWER UP SIMPLE CASE

Slide 196

Slide 196

POWER UP SIMPLE CASE

Slide 197

Slide 197

POWER UP ASYNC

Slide 198

Slide 198

POWER UP ASYNC

Slide 199

Slide 199

POWER UP ASYNC

Slide 200

Slide 200

POWER UP ASYNC

Slide 201

Slide 201

POWER UP U P S H OT

Slide 202

Slide 202

POWER UP U P S H OT • Higher semantic density (focused on meaning not mechanics)

Slide 203

Slide 203

POWER UP U P S H OT • Higher semantic density (focused on meaning not mechanics) • Declarative, configurable data flow 🤯

Slide 204

Slide 204

POWER UP U P S H OT • Higher semantic density (focused on meaning not mechanics) • Declarative, configurable data flow 🤯 • Extremely extensible • defimpl Dataflow, for: %Stream{} • defimpl Dataflow, for: %Distributed{} • defimpl Dataflow, for: %Broadway{}

Slide 205

Slide 205

POWER UP U P S H OT • Higher semantic density (focused on meaning not mechanics) • Declarative, configurable data flow 🤯 • Extremely extensible • defimpl Dataflow, for: %Stream{} • defimpl Dataflow, for: %Distributed{} • defimpl Dataflow, for: %Broadway{} • Model-testable

Slide 206

Slide 206

POWER UP U P S H OT • Higher semantic density (focused on meaning not mechanics) • Declarative, configurable data flow 🤯 • Extremely extensible • defimpl Dataflow, for: %Stream{} • defimpl Dataflow, for: %Distributed{} • defimpl Dataflow, for: %Broadway{} • Model-testable • Composable with other pipes and change evaluation strategies

Slide 207

Slide 207

A CALL FOR LIBRARIES

Slide 208

Slide 208

A CALL FOR LIBRARIES 📣

Slide 209

Slide 209

A CALL FOR LIBRARIES SUMMARY

Slide 210

Slide 210

A CALL FOR LIBRARIES SUMMARY • Can plug into / extend

Slide 211

Slide 211

A CALL FOR LIBRARIES SUMMARY • Can plug into / extend • Single-threaded context

Slide 212

Slide 212

A CALL FOR LIBRARIES SUMMARY • Can plug into / extend • Single-threaded context • Distributed context

Slide 213

Slide 213

A CALL FOR LIBRARIES SUMMARY • Can plug into / extend • Single-threaded context • Distributed context • Dynamic hybrid contexts

Slide 214

Slide 214

A CALL FOR LIBRARIES EXTEND RAILROAD PROGRAMMING

Slide 215

Slide 215

A CALL FOR LIBRARIES EXTEND RAILROAD PROGRAMMING Happy Path (Continue) Error Case (Skip) No Effect (Afterwards)

Slide 216

Slide 216

A CALL FOR LIBRARIES EXTEND RAILROAD PROGRAMMING Happy Path (Continue) Error Case (Skip) No Effect (Afterwards)

Slide 217

Slide 217

A CALL FOR LIBRARIES EXTEND RAILROAD PROGRAMMING Happy Path (Continue) Error Case (Skip) No Effect (Afterwards)

Slide 218

Slide 218

A CALL FOR LIBRARIES S U R P R I S I N G N U M B E R O F FA C T O R S

Slide 219

Slide 219

A CALL FOR LIBRARIES S U R P R I S I N G N U M B E R O F FA C T O R S Log Program

Slide 220

Slide 220

A CALL FOR LIBRARIES S U R P R I S I N G N U M B E R O F FA C T O R S Log Program

Slide 221

Slide 221

SUMMARY

Slide 222

Slide 222

SUMMARY KEEP IN MIND

Slide 223

Slide 223

SUMMARY KEEP IN MIND 1. Protocols-for-DDD (P4D3) 2. Add a semantic layer 3. How do you locally test your distributed system? Look at the properties! 4. Under which conditions does your code work? What are your assumptions? 5. Prop testing is useful for structured abstractions 6. You should be able to code half-asleep

Slide 224

Slide 224

https://fission.codes https://talk .fission.codes https://tools.fission.codes L B E D A N K T, A M ST E R D A M 🎉 brooklyn@fission.codes g i t h u b . c o m /e x p e d e @expede

Slide 225

Slide 225

REWRITING A PHOENIX APP

Slide 226

Slide 226

REWRITING A PHOENIX APP 🕚 A N T I - PAT T E R N S & B U Y I N G T I M E 🔥

Slide 227

Slide 227

REWRITING A PHOENIX APP THE PROBLEM

Slide 228

Slide 228

REWRITING A PHOENIX APP THE PROBLEM • Inherited project • First go at Phoenix • “We don’t believe in tests”

Slide 229

Slide 229

REWRITING A PHOENIX APP THE PROBLEM • Inherited project • First go at Phoenix • “We don’t believe in tests” • Very brittle, many bugs 😱

Slide 230

Slide 230

REWRITING A PHOENIX APP THE PROBLEM • Inherited project • First go at Phoenix • “We don’t believe in tests” • Very brittle, many bugs 😱 • Now tight deadline — no time to do a total rewrite • …or was there? 😏

Slide 231

Slide 231

REWRITING A PHOENIX APP S T R AT E G Y : G E N E R A L I Z AT I O N !

Slide 232

Slide 232

REWRITING A PHOENIX APP S T R AT E G Y : G E N E R A L I Z AT I O N ! • Deescalate • Running code • Get to “net new” features • Two things that people don’t generally associate with abstraction!

Slide 233

Slide 233

REWRITING A PHOENIX APP ⚠ A WORD OF WARNING ⚠

Slide 234

Slide 234

REWRITING A PHOENIX APP ⚠ A WORD OF WARNING ⚠

Slide 235

Slide 235

REWRITING A PHOENIX APP ⚠ A WORD OF WARNING ⚠ How you see yourself

Slide 236

Slide 236

REWRITING A PHOENIX APP ⚠ A WORD OF WARNING ⚠ How you see yourself How others see you

Slide 237

Slide 237

REWRITING A PHOENIX APP THE (TEMPORARY) SOLUTION

Slide 238

Slide 238

REWRITING A PHOENIX APP THE (TEMPORARY) SOLUTION

Slide 239

Slide 239

REWRITING A PHOENIX APP THE (TEMPORARY) SOLUTION

Slide 240

Slide 240

REWRITING A PHOENIX APP THE (TEMPORARY) SOLUTION

Slide 241

Slide 241

REWRITING A PHOENIX APP THE (TEMPORARY) SOLUTION •Generate all of MVVC •Compile-time functions •Incl. validation •Spend 90% time on macro •Write •Test!

Slide 242

Slide 242

REWRITING A PHOENIX APP TRADEOFFS

Slide 243

Slide 243

REWRITING A PHOENIX APP TRADEOFFS • Implement very fast • Flexible • Makes a lot of assumptions • Macro magic • Difficult to read, extend, &c • Low-level implementation • The macro swamp

Slide 244

Slide 244

REWRITING A PHOENIX APP TRADEOFFS

Slide 245

Slide 245

REWRITING A PHOENIX APP TRADEOFFS • Straightforward: MVVC! • Encode patterns directly in code 🎉

Slide 246

Slide 246

C R DT CAS E ST U DY

Slide 247

Slide 247

C R DT CAS E ST U DY ⏲ ELEGANT AND USEFUL ☮

Slide 248

Slide 248

C R DT CAS E ST U DY SCENARIO

Slide 249

Slide 249

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology

Slide 250

Slide 250

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 💻 💻 💻 💻 💻

Slide 251

Slide 251

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 • Eventual consistency 💻 💻 💻 💻 💻

Slide 252

Slide 252

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 • Eventual consistency 💻 💻 🚦 💻 💻 💻

Slide 253

Slide 253

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 • Eventual consistency 💻 💻 🚦 💻 💻 💻

Slide 254

Slide 254

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 • Eventual consistency 💻 💻 🚦 💻 💻 💻

Slide 255

Slide 255

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 • Eventual consistency 💻 • High resilience • Infinite(ish) time tolerance • Decentralized (e.g. via gossip) 💻 🚦 💻 • Self-healing 💻 💻

Slide 256

Slide 256

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 • Eventual consistency 💻 • High resilience • Infinite(ish) time tolerance • Decentralized (e.g. via gossip) 💻 💻 • Self-healing 💻 💻

Slide 257

Slide 257

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 • Eventual consistency 💻 • High resilience • Infinite(ish) time tolerance • Decentralized (e.g. via gossip) 💻 💻 • Self-healing 💻 💻

Slide 258

Slide 258

C R DT CAS E ST U DY SCENARIO • Distributed / uncontrolled topology 💻 • Eventual consistency 💻 • High resilience • Infinite(ish) time tolerance • Decentralized (e.g. via gossip) 💻 💻 • Self-healing • Two variants • State-based • Operation-based ✅ 💻 💻

Slide 259

Slide 259

C R DT CAS E ST U DY B A S I C : P O S I T I V E / N E G AT I V E C O U N T E R

Slide 260

Slide 260

C R DT CAS E ST U DY B A S I C : P O S I T I V E / N E G AT I V E C O U N T E R • Two sets • Increments • Decrements • Operations • Internal • Increment • Decrement • Compare • External • Merge • Query

Slide 261

Slide 261

C R DT CAS E ST U DY B A S I C : P O S I T I V E / N E G AT I V E C O U N T E R • Two sets • Increments • Decrements • Operations • Internal • Increment • Decrement • Compare • External • Merge • Query • Challenges • Negative counts • Double deletes • Solutions • Only delete existing items • Commutativity

Slide 262

Slide 262

C R DT CAS E ST U DY OBSERVE/REMOVE SE T

Slide 263

Slide 263

C R DT CAS E ST U DY OBSERVE/REMOVE SE T • Two sub-sets • Add • Remove • Operations • Internal • Add • Remove • Compare • Tag • External • Merge — semigroup • Query

Slide 264

Slide 264

C R DT CAS E ST U DY OBSERVE/REMOVE SE T • Two sub-sets • Add • Remove • Operations • Internal • Add • Remove • Compare • Tag • External • Merge — semigroup • Query • Challenges • Add-after-remove • Unique tags vs re-add • Can only delete what you know about • But deleting an unknown element is the same as a noop, so great! • Remove has priority over add • Wall clock timestamps are unreliable • Need monotonically increasing structure • Solutions • Only delete existing items • Commutativity • Protocols • Collectable • Enumerable • Semigroup (merge) -> Commutative (CRDT) • “Meet semilattice”

Slide 265

Slide 265

W H AT E V E N I S E L I X I R ?

Slide 266

Slide 266

W H AT E V E N I S E L I X I R ? ⚗

Slide 267

Slide 267

W H AT E V E N I S E L I X I R ? SHOW OF HANDS ✋ Is Elixir a functional language?

Slide 268

Slide 268

W H AT E V E N I S E L I X I R ? STRUCTURAL INTEGRIT Y

Slide 269

Slide 269

W H AT E V E N I S E L I X I R ? STRUCTURAL INTEGRIT Y ☝ Production Elixir can actually be pretty unstructured

Slide 270

Slide 270

W H AT E V E N I S E L I X I R ? STRUCTURAL INTEGRIT Y ☝ Production Elixir can actually be pretty unstructured • Imperative • Lots of ambient state • Spread across processes • Ordering & timing bugs

Slide 271

Slide 271

W H AT E V E N I S E L I X I R ? STRUCTURAL INTEGRIT Y ☝ Production Elixir can actually be pretty unstructured • Imperative • Lots of ambient state • Spread across processes • Ordering & timing bugs • Functional • Well-defined structured functions (map, filter, reduce) • Immutable references

Slide 272

Slide 272

W H AT E V E N I S E L I X I R ? W H Y N O T F U L LY S T R U C T U R E D ?

Slide 273

Slide 273

W H AT E V E N I S E L I X I R ? W H Y N O T F U L LY S T R U C T U R E D ? • Naive structure can be rigid! • Composition • Orthogonality

Slide 274

Slide 274

W H AT E V E N I S E L I X I R ? W H Y N O T F U L LY S T R U C T U R E D ? • Naive structure can be rigid! • Composition • Orthogonality Credit: psihedelisto

Slide 275

Slide 275

W H AT E V E N I S E L I X I R ? H O W T O E AT T H E S T R U C T U R A L E L E P H A N T

Slide 276

Slide 276

POWER UP

Slide 277

Slide 277

POWER UP Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be selfevident. Data structures, not algorithms, are central to programming. ⚙ ~ROB PIKE, 5 RULES OF PROGRAMMING

Slide 278

Slide 278

ABSTRACTION & DSLS DEFINITIONS

Slide 279

Slide 279

ABSTRACTION & DSLS DEFINITIONS Abstract 📈 Concrete 🚚

Slide 280

Slide 280

ABSTRACTION & DSLS DEFINITIONS Abstract 📈 \ Specific General ]👪_ Concrete 🚚

Slide 281

Slide 281

ABSTRACTION & DSLS DEFINITIONS Abstract 📈 42 \ Specific “Community” General ]👪_ Conference speakers L Concrete 🚚

Slide 282

Slide 282

ABSTRACTION & DSLS DEFINITIONS Abstract 📈 42 \ Specific “Community” General ]👪_ Conference speakers L Concrete 🚚

Slide 283

Slide 283

ABSTRACTION & DSLS DEFINITIONS Abstract 📈 42 \ Specific “Community” General ]👪_ Conference speakers L Concrete 🚚