Tryranny of Structurelessness

A presentation at Elixir Brasil 2020 in November 2020 in by Brooklyn Zelenka

Slide 1

Slide 1

The Tyranny of Structurelessness How more meaningful code can make your project more resilient & maintainable

Slide 2

Slide 2

I have regarded it as the highest goal of programming language design to enable good ideas to be elegantly expressed Tony Hoare, Turing Award Lecture 1980

Slide 3

Slide 3

Give me the right word and the right accent and I will move the world Joseph Conrad on Archimedes Lever

Slide 4

Slide 4

Brooklyn Zelenka @expede

Slide 5

Slide 5

Brooklyn Zelenka @expede • CTO at Fission — https://fission.codes • WebNative • Making backends obsolete 🤭 • PLT, VMs, Distributed Systems, ETH Core • Founder of the Vancouver FP meetup • Witchcraft, Quark, Algae, Exceptional, and others • Exceptional (Elixir)

< • Witchcraft (Elixir) Rescue (Haskell) Prelude (Haskell)

Slide 6

Slide 6

Slide 7

Slide 7

PING ME AND WE’LL MAIL SOME Stickers!

Slide 8

Slide 8

This Talk is About…

Slide 9

Slide 9

This Talk is About… • An approach to programming (broadly) • Some observations about Elixir specifically • A vision for the future of the ecosystem • If you were at CodeBEAM BR, this talk generalizes some of the same ideas

Slide 10

Slide 10

This is the Big Idea 💭💡🚀

Slide 11

Slide 11

Big Idea One Liner 🛸 Work at a higher level 🔭

Slide 12

Slide 12

Big Idea Language Design Reflects Intended Use 🌐

Slide 13

Slide 13

Big Idea Who’s Org Looks Like This?

Slide 14

Slide 14

Big Idea Who’s Org Looks Like This? 🧠 👨💻 👩💻 👩💻 👨💻 ⚙ 👩💻 👨💻

Slide 15

Slide 15

Big Idea Who’s Org Looks Like This? 🧠 👨💻 👩💻 👩💻 👨💻 ⚙ 👩💻 👨💻

Slide 16

Slide 16

Big Idea Who’s Org Looks Like This? 👩💻 👩💻 👨💻 ⚙ 👨💻 👩💻 👨💻

Slide 17

Slide 17

Big Idea Who’s Org Looks Like This? 👩💻 👩💻 👨💻 ⚙ 👨💻 👩💻 👨💻

Slide 18

Slide 18

Big Idea Forward Thinking 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 2025, 2030, and 2050?

Slide 19

Slide 19

Big Idea Core Evolution We need to evolve our approach: focus on domain and structure!

Slide 20

Slide 20

Big Idea Core Evolution We need to evolve our approach: focus on domain and structure! ✨ 🦄 🚀

Slide 21

Slide 21

Structural Example: Schema Lenses w .inkandswitch.com/cambria.html w w Big Idea

Slide 22

Slide 22

In the Large 🌎

Slide 23

Slide 23

In the Large Code You Used to Write Imperative

Slide 24

Slide 24

In the Large Code You Used to Write Imperative

Slide 25

Slide 25

In the Large “Good” Elixir Imperative

  • Functional core, imperative shell

Slide 26

Slide 26

In the Large “Good” Elixir Imperative λ

  • Functional core, imperative shell

Slide 27

Slide 27

In the Large Imperative 3LA Future Imperative λ

Slide 28

Slide 28

In the Large 3LA Future Imperative Semantic DSL / OO Imperative λ

Slide 29

Slide 29

In the Large Prop & Model Test Imperative

Slide 30

Slide 30

GOTO Considered Harmful 🤖😵

Slide 31

Slide 31

The quality of programmers is a decreasing function of the density of GOTO statements in the programs they produce Edsger Dijkstra

Slide 32

Slide 32

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫

Slide 33

Slide 33

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • GOTOs

Slide 34

Slide 34

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • GOTOs • Low level instruction

Slide 35

Slide 35

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it

Slide 36

Slide 36

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible

Slide 37

Slide 37

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible • Highly concrete

Slide 38

Slide 38

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible • Highly concrete • Huge number of implicit states

Slide 39

Slide 39

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • 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

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • 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

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • 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 42

Slide 42

GOTO Considered Harmful What’s So Bad About Having Control? 🦶🔫 • GOTOs • Low level instruction • Literally how the machine is going to see it • Extremely flexible • Highly concrete Line 1 Line 2 Line 3 Line 4 Line 5 — GOTO Line 6 • Huge number of implicit states 💥

Slide 43

Slide 43

GOTO Considered Harmful Structured Programming while

Slide 44

Slide 44

GOTO Considered Harmful Structured Programming • Subroutines while

Slide 45

Slide 45

GOTO Considered Harmful Structured Programming • Subroutines • Loops while

Slide 46

Slide 46

GOTO Considered Harmful Structured Programming • Subroutines • Loops • Switch/branching while

Slide 47

Slide 47

GOTO Considered Harmful Structured Programming • Subroutines • Loops • Switch/branching • Named routines while

Slide 48

Slide 48

GOTO Considered Harmful The Next Generation 🚀

Slide 49

Slide 49

GOTO Considered Harmful The Next Generation 🚀 • Objects, Actors, Protocols

Slide 50

Slide 50

GOTO Considered Harmful The Next Generation 🚀 • Objects, Actors, Protocols • Map, Reduce, Filter

Slide 51

Slide 51

GOTO Considered Harmful The Next Generation 🚀 • Objects, Actors, Protocols • Map, Reduce, Filter • Functor, Applicative, Monad

Slide 52

Slide 52

GOTO Considered Harmful The Next Generation 🚀 • Objects, Actors, Protocols • Map, Reduce, Filter • Functor, Applicative, Monad • Constraint Solvers

Slide 53

Slide 53

GOTO Considered Harmful Tradeoffs

Slide 54

Slide 54

GOTO Considered Harmful Tradeoffs • Exchange granular control for structure

Slide 55

Slide 55

GOTO Considered Harmful Tradeoffs • Exchange granular control for structure • Meaning over mechanics

Slide 56

Slide 56

GOTO Considered Harmful Tradeoffs • Exchange granular control for structure • Meaning over mechanics • More human than machine

Slide 57

Slide 57

GOTO Considered Harmful Tradeoffs • Exchange granular control for structure • Meaning over mechanics • More human than machine • Safer!

Slide 58

Slide 58

GOTO Considered Harmful Tradeoffs • Exchange granular control for structure • Spectrum • Meaning over mechanics • Turing Tarpit • More human than machine • Church Chasm • Safer! • Haskell Fan Fiction

Slide 59

Slide 59

250 GOTO Considered Harmful Payoff Structured Unstructured

Slide 60

Slide 60

250 GOTO Considered Harmful COMPLEXITY Payoff Structured Unstructured TIME

Slide 61

Slide 61

GOTO Considered Harmful Payoff 1000 COMPLEXITY 750 500 Unstructured Structured 250 TIME

Slide 62

Slide 62

GOTO Considered Harmful Payoff 1000 COMPLEXITY 750 500 Unstructured Structured 250 TIME

Slide 63

Slide 63

GOTO Considered Harmful Payoff 1000 COMPLEXITY 750 500 Unstructured Structured 250 TIME

Slide 64

Slide 64

On Complexity 🌱🌸🌾

Slide 65

Slide 65

On Complexity Overused

Slide 66

Slide 66

On Complexity Overused

Slide 67

Slide 67

On Complexity The Bad Kind ☠

Slide 68

Slide 68

On Complexity The Bad Kind ☠ • Probably pretty familiar with this

Slide 69

Slide 69

On Complexity The Bad Kind ☠ • Probably pretty familiar with this • Euphemism for: • Complicated • Inconsistent • No plan • “Unstructured mess”

Slide 70

Slide 70

On Complexity The Good Kind: Deep What do these have in common? (a+b)/a ~ a / b

Slide 71

Slide 71

On Complexity Orthogonal Complecting

Slide 72

Slide 72

On Complexity Orthogonal Complecting

Slide 73

Slide 73

On Complexity Orthogonal Complecting

Slide 74

Slide 74

On Complexity Orthogonal Complecting

Slide 75

Slide 75

On Complexity Orthogonal Complecting

Slide 76

Slide 76

On Complexity Orthogonal Complecting

Slide 77

Slide 77

On Complexity Orthogonal Complecting

Slide 78

Slide 78

On Complexity Orthogonal Complecting

Slide 79

Slide 79

On Complexity Orthogonal Complecting

Slide 80

Slide 80

On Complexity Orthogonal Complecting

Slide 81

Slide 81

On Complexity Orthogonal Complecting 🕐

Slide 82

Slide 82

On Complexity Orthogonal Complecting 🕐 Structures: 4

Slide 83

Slide 83

On Complexity Orthogonal Complecting 🕐 ff Structures: 4 Results: e ectively limitless

Slide 84

Slide 84

On Complexity Complex != Complicated

Slide 85

Slide 85

On Complexity Complex != Complicated • Complex — interconnected parts

Slide 86

Slide 86

On Complexity Complex != Complicated • Complex — interconnected parts ffi • Complicated — di cult to understand

Slide 87

Slide 87

Abstraction & DSLs The Power of Words

Slide 88

Slide 88

Abstraction & DSLs The Power of Words • Restrict your vocabulary to your domain • …the hard part is deciding on that vocabulary

Slide 89

Slide 89

Abstraction & DSLs The Power of Words • Restrict your vocabulary to your domain • …the hard part is deciding on that vocabulary • Technical debt is lack of understanding • https://daverupert.com/2020/11/technical-debt-as-a-lack-of-understanding/

Slide 90

Slide 90

On Complexity The Actor Abyss

Slide 91

Slide 91

On Complexity The Actor Abyss • Each step is very simple

Slide 92

Slide 92

On Complexity The Actor Abyss • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to (re)store your data • e.g. crash recovery • Called collaborator may not be there

Slide 93

Slide 93

On Complexity The Actor Abyss • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to (re)store your data • e.g. crash recovery • Called collaborator may not be there • Complexity grows faster than linear

Slide 94

Slide 94

On Complexity The Actor Abyss • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to (re)store your data • e.g. crash recovery • Called collaborator may not be there • Complexity grows faster than linear • Find common factors — your abstraction

Slide 95

Slide 95

On Complexity The Actor Abyss • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to (re)store your data • e.g. crash recovery • Called collaborator may not be there • Complexity grows faster than linear • Find common factors — your abstraction

Slide 96

Slide 96

Fighting GenSoup 🚫🍲⚔

Slide 97

Slide 97

Fighting GenSoup Good Interfaces != Good Abstractions

Slide 98

Slide 98

Fighting GenSoup Good Interfaces != Good Abstractions • GenServer & co are actually pretty low level • Please add some semantics 🙏

Slide 99

Slide 99

Fighting GenSoup Good Interfaces != Good Abstractions • GenServer & co are actually pretty low level • Please add some semantics 🙏 • Don’t reinvent the wheel every time 🎡

Slide 100

Slide 100

Fighting GenSoup Good Interfaces != Good Abstractions • 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 101

Slide 101

Fighting GenSoup Abstraction

Slide 102

Slide 102

Fighting GenSoup Simple Case: Map

Slide 103

Slide 103

Fighting GenSoup Async Case: Part I (defstruct)

Slide 104

Slide 104

Fighting GenSoup i Async Case: Part II (def mpl)

Slide 105

Slide 105

Fighting GenSoup What Did We Get?

Slide 106

Slide 106

Fighting GenSoup What Did We Get? • Common interface

Slide 107

Slide 107

Fighting GenSoup What Did We Get? • Common interface • Encapsulate the detail

Slide 108

Slide 108

Fighting GenSoup What Did We Get? • Common interface • Encapsulate the detail • Don’t have to think about mechanics anymore 🙅🔧

Slide 109

Slide 109

Fighting GenSoup Abstraction = Focus & Essence

Slide 110

Slide 110

Fighting GenSoup Abstraction = Focus & Essence

Slide 111

Slide 111

Fighting GenSoup Abstraction = Focus & Essence 🙈

Slide 112

Slide 112

Abstraction & DSLs Not Getting Trapped in the Details

Slide 113

Slide 113

Abstraction & DSLs Commonalities

Slide 114

Slide 114

Abstraction & DSLs Commonalities • They clearly have a similar structure

Slide 115

Slide 115

Abstraction & DSLs Commonalities • They clearly have a similar structure • NOT equally expressive • Enumerable

Slide 116

Slide 116

Abstraction & DSLs Commonalities • They clearly have a similar structure • NOT equally expressive • Enumerable • Always converted to List • Witchcraft.Functor

Slide 117

Slide 117

Abstraction & DSLs Commonalities

Slide 118

Slide 118

Abstraction & DSLs Commonalities • Di erent, but also have similar structure • Not very pipeable because 2 paths ff • …lots of duplicate code

Slide 119

Slide 119

Abstraction & DSLs Commonalities • Di erent, but also have similar structure • Not very pipeable because 2 paths • …lots of duplicate code ff • Why limit to only to two ways?

Slide 120

Slide 120

Abstraction & DSLs Commonalities • Di erent, but also have similar structure • Not very pipeable because 2 paths • …lots of duplicate code ff • Why limit to only to two ways?

Slide 121

Slide 121

Abstraction & DSLs Commonalities • Di erent, but also have similar structure • Not very pipeable because 2 paths • …lots of duplicate code ff • Why limit to only to two ways?

Slide 122

Slide 122

Abstraction & DSLs Start From Rules 📋

Slide 123

Slide 123

Abstraction & DSLs Start From Rules 📋 • Describe what the overall solution looks like

Slide 124

Slide 124

Abstraction & DSLs Start From Rules 📋 • Describe what the overall solution looks like • Choose how it gets run contextually

Slide 125

Slide 125

Abstraction & DSLs 2-Phase

Slide 126

Slide 126

Abstraction & DSLs 2-Phase • Always a two-phase process

Slide 127

Slide 127

Abstraction & DSLs 2-Phase • Always a two-phase process • Abstract, then concrete

Slide 128

Slide 128

Abstraction & DSLs 2-Phase • Always a two-phase process • Abstract, then concrete • Do concretion at application boundary

Slide 129

Slide 129

Abstraction & DSLs 2-Phase • Always a two-phase process • Abstract, then concrete • Do concretion at application boundary

Slide 130

Slide 130

Abstraction & DSLs 2-Phase • Always a two-phase process • Abstract, then concrete • Do concretion at application boundary

Slide 131

Slide 131

Abstraction & DSLs Improving Kernel

Slide 132

Slide 132

Abstraction & DSLs Improving Kernel • Fallback keys

Slide 133

Slide 133

Abstraction & DSLs Improving Kernel • Fallback keys • Bang-functions

Slide 134

Slide 134

Abstraction & DSLs Improving Kernel with Fallback Keys

Slide 135

Slide 135

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • Composition is at the heart of modularity • Orthogonality is at the heart of composition

Slide 136

Slide 136

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • 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 137

Slide 137

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • 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 138

Slide 138

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • 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 139

Slide 139

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • 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 140

Slide 140

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • 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 141

Slide 141

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • 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 142

Slide 142

Abstraction & DSLs Improving Kernel with(out?) Bang Functions

Slide 143

Slide 143

Abstraction & DSLs Improving Kernel with(out?) Bang Functions * from foo / * / Get foo!

Slide 144

Slide 144

Abstraction & DSLs Improving Kernel with(out?) Bang Functions * from foo / * / Get foo!

Slide 145

Slide 145

Abstraction & DSLs Improving Kernel with(out?) Bang Functions * from foo / * / Get foo!

Slide 146

Slide 146

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 * from foo / * / Get foo!

Slide 147

Slide 147

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 * from foo / * / Get foo!

Slide 148

Slide 148

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 * from foo / * / Get foo! 💣

Slide 149

Slide 149

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 * from foo / * / Get foo! 💣

Slide 150

Slide 150

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Get foo! from foo 💣 🆗 * / * / ⏩

Slide 151

Slide 151

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Get foo! from foo 💣 🆗 ⏩ * / * / 💣

Slide 152

Slide 152

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Get foo! from foo 💣 🆗 ⏩ * / * / 💣 Works everywhere

Slide 153

Slide 153

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Works everywhere Any data Get foo! from foo 💣 🆗 ⏩ * / * / 💣

Slide 154

Slide 154

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Works everywhere Any data Any exception struct Get foo! from foo 💣 🆗 ⏩ * / * / 💣

Slide 155

Slide 155

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Works everywhere Any data Any exception struct Get foo! from foo 💣 🆗 ⏩ * / * / 💣 Your choice o flow (e.g. pipes!)

Slide 156

Slide 156

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Works everywhere Any data Any exception struct Get foo! from foo 💣 🆗 ⏩ * / * / 💣 Your choice o flow (e.g. pipes!) Super easy to test

Slide 157

Slide 157

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Works everywhere Any data Any exception struct Get foo! from foo 💣 🆗 ⏩ * / * / 💣 Your choice o flow (e.g. pipes!) Super easy to test

Slide 158

Slide 158

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Works everywhere Any data Any exception struct Get foo! from foo 💣 Your choice o flow (e.g. pipes!) Super easy to test 🆗 ⏩ * / * / 💣 BONUS

Slide 159

Slide 159

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Works everywhere Any data Any exception struct Get foo! from foo 💣 Your choice o flow (e.g. pipes!) Super easy to test 🆗 ⏩ * / * / 💣 BONUS Fix nil blindness,

Slide 160

Slide 160

Abstraction & DSLs Improving Kernel with(out?) Bang Functions 💣 Works everywhere Any data Any exception struct Get foo! from foo 💣 Your choice o flow (e.g. pipes!) Super easy to test 🆗 ⏩ * / * / 💣 BONUS Fix nil blindness, the “billion dollar mistake”

Slide 161

Slide 161

Abstraction & DSLs A Note on Metaphor

Slide 162

Slide 162

Abstraction & DSLs A Note on Metaphor • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2

Slide 163

Slide 163

Abstraction & DSLs A Note on Metaphor • 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 164

Slide 164

Abstraction & DSLs A Note on Metaphor • 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 165

Slide 165

Abstraction & DSLs A Note on Metaphor • 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 166

Slide 166

Abstraction & DSLs A Note on Metaphor • 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 167

Slide 167

Abstraction & DSLs A Note on Metaphor • 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 168

Slide 168

Abstraction & DSLs What’s Gained

Slide 169

Slide 169

Abstraction & DSLs What’s Gained • Clear

Slide 170

Slide 170

Abstraction & DSLs What’s Gained • Clear • Composable

Slide 171

Slide 171

Abstraction & DSLs What’s Gained • Clear • Composable • Greater reuse ♻

Slide 172

Slide 172

Abstraction & DSLs What’s Gained • Clear • Composable • Greater reuse ♻ • User choice

Slide 173

Slide 173

Abstraction & DSLs What’s Gained • Clear • Composable • Greater reuse ♻ • User choice • Increased testability • Simple example: is_exception?/1

Slide 174

Slide 174

Abstraction & DSLs What’s Gained • Clear • Composable • Greater reuse ♻ • User choice • Increased testability • Simple example: is_exception?/1 • Could still add protocol to get even more power

Slide 175

Slide 175

Abstraction & DSLs Storytelling 📖

Slide 176

Slide 176

Abstraction & DSLs Storytelling 📖 • Your code read like a story

Slide 177

Slide 177

Abstraction & DSLs Storytelling 📖 • Your code read like a story • We even see this in high-level goals of (e.g.) Phoenix

Slide 178

Slide 178

Abstraction & DSLs Storytelling 📖 • Your code read like a story • We even see this in high-level goals of (e.g.) Phoenix • Go make some DSLs!

Slide 179

Slide 179

Abstraction & DSLs How to Eat the Elephant 🍴

Slide 180

Slide 180

Abstraction & DSLs How to Eat the Elephant 🍴 • By feature?

Slide 181

Slide 181

Abstraction & DSLs How to Eat the Elephant 🍴 • By feature? • By behaviour?

Slide 182

Slide 182

Abstraction & DSLs How to Eat the Elephant 🍴 • By feature? • By behaviour? • By structure / properties!

Slide 183

Slide 183

Intermission Puzzle 🧩

Slide 184

Slide 184

Intermission Puzzle What Do The Following Have In Common?

Slide 185

Slide 185

Intermission Puzzle What Do The Following Have In Common? • Async/await (or Task, if you prefer)

Slide 186

Slide 186

Intermission Puzzle What Do The Following Have In Common? • Async/await (or Task, if you prefer) • throw/catch

Slide 187

Slide 187

Intermission Puzzle What Do The Following Have In Common? • Async/await (or Task, if you prefer) • throw/catch • with blocks

Slide 188

Slide 188

Intermission Puzzle What Do The Following Have In Common? • Async/await (or Task, if you prefer) • throw/catch • with blocks • SQL queries — LINQ

Slide 189

Slide 189

Intermission Puzzle What Do The Following Have In Common? • Async/await (or Task, if you prefer) • throw/catch • with blocks • SQL queries — LINQ • JSON parsing

Slide 190

Slide 190

Intermission Puzzle What Do The Following Have In Common? • Async/await (or Task, if you prefer) • throw/catch • with blocks • SQL queries — LINQ • JSON parsing • “Warm fuzzy thing”

Slide 191

Slide 191

Structure One of these things is like all the others

Slide 192

Slide 192

Structure There Are Only Three Right Answers 1 2 3

Slide 193

Slide 193

Structure There Are Only Three Right Answers 1 2 3

Slide 194

Slide 194

Structure Associativity

Slide 195

Slide 195

Structure Associativity • Not a data structure

Slide 196

Slide 196

Structure Associativity • Not a data structure • Not a function

Slide 197

Slide 197

Structure Associativity • Not a data structure • Not a function • An interface & rules!

Slide 198

Slide 198

Structure Associativity • Not a data structure • Not a function • An interface & rules! (No w o l f e h t te a t e m ) r o ph

Slide 199

Slide 199

Structure A Semigroup On…

Slide 200

Slide 200

Structure A Semigroup On…

Slide 201

Slide 201

Structure An Unlawful Counterexample 🚨

Slide 202

Slide 202

Structure How to Enforce Properties

Slide 203

Slide 203

Structure How to Enforce Properties • A structure of structures • Keep it in your brain • Manually prop test • Enforce with TypeClass

Slide 204

Slide 204

Let’s Do Something Wild 🦁 (Power Up Pipes)

Slide 205

Slide 205

Power Up Explicit Assumptions

Slide 206

Slide 206

Power Up Explicit Assumptions • Parallel pipes! • Concurrency = partial order • Monotonic • All loops must be linearized

Slide 207

Slide 207

Power Up Explicit Assumptions • Parallel pipes! • Concurrency = partial order • Monotonic • All loops must be linearized • Properties • Serial composition • Parallel composition • Explicit evaluation strategy

Slide 208

Slide 208

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 209

Slide 209

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 210

Slide 210

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 211

Slide 211

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 212

Slide 212

Power Up Pipes++

Slide 213

Slide 213

Power Up Pipes++

Slide 214

Slide 214

Power Up Pipes++

Slide 215

Slide 215

Power Up Pipes++

Slide 216

Slide 216

Power Up How?!

Slide 217

Slide 217

Power Up How?!

Slide 218

Slide 218

Power Up Cleanup

Slide 219

Slide 219

Power Up Cleanup

Slide 220

Slide 220

Power Up Carrier Data

Slide 221

Slide 221

Power Up Carrier Data

Slide 222

Slide 222

Power Up Carrier Data

Slide 223

Slide 223

Power Up Carrier Data

Slide 224

Slide 224

Power Up Carrier Data

Slide 225

Slide 225

Power Up Carrier Data

Slide 226

Slide 226

Power Up Base Case

Slide 227

Slide 227

Power Up Base Case

Slide 228

Slide 228

Power Up Base Case

Slide 229

Slide 229

Power Up Async

Slide 230

Slide 230

Power Up Async

Slide 231

Slide 231

Power Up Async

Slide 232

Slide 232

Power Up Async

Slide 233

Slide 233

Power Up Upshot

Slide 234

Slide 234

Power Up Upshot • Higher semantic density (meaning > mechanics)

Slide 235

Slide 235

Power Up Upshot • Higher semantic density (meaning > mechanics) • Declarative, configurable data flow 🤯

Slide 236

Slide 236

Power Up Upshot • Higher semantic density (meaning > mechanics) • Declarative, configurable data flow 🤯 • Extremely extensible • def mpl Dataflow, for: %Stream{} • def mpl Dataflow, for: %Distributed{} i i i • def mpl Dataflow, for: %Broadway{}

Slide 237

Slide 237

Power Up Upshot • Higher semantic density (meaning > mechanics) • Declarative, configurable data flow 🤯 • Extremely extensible • def mpl Dataflow, for: %Stream{} • def mpl Dataflow, for: %Distributed{} • def mpl Dataflow, for: %Broadway{} i i i • Model-testable

Slide 238

Slide 238

Power Up Upshot • Higher semantic density (meaning > mechanics) • Declarative, configurable data flow 🤯 • Extremely extensible • def mpl Dataflow, for: %Stream{} • def mpl Dataflow, for: %Distributed{} • def mpl Dataflow, for: %Broadway{} • Model-testable i i i • Composable with other pipes and change evaluation strategies

Slide 239

Slide 239

Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. Rob Pike, 5 Rules of Programming

Slide 240

Slide 240

A Call for Libraries

Slide 241

Slide 241

A Call for Libraries Summary

Slide 242

Slide 242

A Call for Libraries Summary • Can plug into / extend

Slide 243

Slide 243

A Call for Libraries Summary • Can plug into / extend • Single-threaded context

Slide 244

Slide 244

A Call for Libraries Summary • Can plug into / extend • Single-threaded context • Distributed context

Slide 245

Slide 245

A Call for Libraries Summary • Can plug into / extend • Single-threaded context • Distributed context • Dynamic hybrid contexts

Slide 246

Slide 246

A Call for Libraries Extend Railroad Programming

Slide 247

Slide 247

A Call for Libraries Extend Railroad Programming Happy Path (Continue) Error Case (Skip) ff No E ect (Afterwards)

Slide 248

Slide 248

A Call for Libraries Extend Railroad Programming Happy Path (Continue) Error Case (Skip) ff No E ect (Afterwards)

Slide 249

Slide 249

A Call for Libraries Extend Railroad Programming Happy Path (Continue) Error Case (Skip) ff No E ect (Afterwards)

Slide 250

Slide 250

A Call for Libraries Surprising Number of Factors

Slide 251

Slide 251

A Call for Libraries Surprising Number of Factors Log Program

Slide 252

Slide 252

A Call for Libraries Surprising Number of Factors Log Program

Slide 253

Slide 253

Summary

Slide 254

Slide 254

Summary Keep In Mind…

Slide 255

Slide 255

Summary Keep In Mind… • Protocols-for-DDD

Slide 256

Slide 256

Summary Keep In Mind… • Protocols-for-DDD • Add a semantic layer

Slide 257

Slide 257

Summary Keep In Mind… • Protocols-for-DDD • Add a semantic layer • How do you locally test your distributed system? Look at the properties!

Slide 258

Slide 258

Summary Keep In Mind… • Protocols-for-DDD • Add a semantic layer • How do you locally test your distributed system? Look at the properties! • Under which conditions does your code work? What are your assumptions?

Slide 259

Slide 259

Summary Keep In Mind… • Protocols-for-DDD • Add a semantic layer • How do you locally test your distributed system? Look at the properties! • Under which conditions does your code work? What are your assumptions? • Prop testing is useful for structured abstractions

Slide 260

Slide 260

Summary Keep In Mind… • Protocols-for-DDD • Add a semantic layer • How do you locally test your distributed system? Look at the properties! • Under which conditions does your code work? What are your assumptions? • Prop testing is useful for structured abstractions • You should be able to code half-asleep

Slide 261

Slide 261

https://fission.codes https://talk.fission.codes https://tools.fission.codes 🇧🇷 Thank You, Elixir Brasil 🎉 brooklyn@fission.codes g i t h u b . c o m /e x p e d e @expede

Slide 262

Slide 262

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭

Slide 263

Slide 263

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭 Generalit Few assumption • Many use cases s • n Low informatio y •

Slide 264

Slide 264

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭 Generalit Powe • Can make many assumption • Many use cases • Tailored to few use cases s Few assumption s • n High informatio n • y Low informatio r •

Slide 265

Slide 265

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭 Generalit Powe • Low informatio • High informatio • Few assumption • Can make many assumption • Many use cases • Tailored to few use cases s s n n y r GENERALITY 🌏 ⚖ POWER 🚀

Slide 266

Slide 266

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭 Generalit Powe • Low informatio • High informatio • Few assumption • Can make many assumption • Many use cases • Tailored to few use cases s s n n y r GENERALITY 🌏 ⚖ POWER 🚀

Slide 267

Slide 267

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭 Generalit Powe • Low informatio • High informatio • Few assumption • Can make many assumption • Many use cases • Tailored to few use cases Enum s s n n y r GENERALITY 🌏 ⚖ POWER 🚀

Slide 268

Slide 268

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭 Generalit Powe • Low informatio • High informatio • Few assumption • Can make many assumption • Many use cases • Tailored to few use cases Enum s s n n y r GENERALITY 🌏 Ecto.Schema ⚖ POWER 🚀

Slide 269

Slide 269

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭 Generalit Powe • Low informatio • High informatio • Few assumption • Can make many assumption • Many use cases • Tailored to few use cases GenServer Enum s s n n y r GENERALITY 🌏 Ecto.Schema ⚖ POWER 🚀

Slide 270

Slide 270

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭 Generalit Powe • Low informatio • High informatio • Few assumption • Can make many assumption • Many use cases • Tailored to few use cases GenServer Enum GENERALITY 🌏 s s n n y r Libraries Ecto.Schema ⚖ POWER 🚀 Applications