Bridging the Divide: a noble quest of bootstraps, sugar, and spectral pyramids

A presentation at LambdaDays in February 2019 in Kraków, Poland by Brooklyn Zelenka

Slide 1

Slide 1

BRIDGING THE DIVIDE 💔 ❤ ✨⚔ A NOBLE QUEST OF BOOTSTRAPS, SUGAR, AND SPECTRAL PYRAMIDS 🐉⚡

Slide 2

Slide 2

BRIDGING THE DIVIDE 💔 ✨⚔ A NOBLE QUEST OF BOOTSTRAPS, SUGAR, AND SPECTRAL PYRAMIDS 🐉⚡

Slide 3

Slide 3

If you don’t like what you got Why don’t you change it If your programming language is all screwed up Rearrange it 🤘😈🔥 TROOPER, “RAISE A LIT TLE HELL” (SORT OF)

Slide 4

Slide 4

M E TA TA L K I N G A B O U T T H I S T A L K

Slide 5

Slide 5

M E TA TA L K I N G A B O U T T H I S T A L K

Slide 6

Slide 6

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E

Slide 7

Slide 7

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co

Slide 8

Slide 8

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🔹 Ethereum Core Dev

Slide 9

Slide 9

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🔹 Ethereum Core Dev 📜 Authored bunch of standards

Slide 10

Slide 10

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🔹 Ethereum Core Dev 📜 Authored bunch of standards ⚛ FISSION Framework

Slide 11

Slide 11

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🔹 Ethereum Core Dev 📜 Authored bunch of standards ⚛ FISSION Framework 💬 Clarity Language

Slide 12

Slide 12

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🔹 Ethereum Core Dev 📜 Authored bunch of standards ⚛ FISSION Framework 💬 Clarity Language 🧙 Open Sourceress

Slide 13

Slide 13

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🧙 Open Sourceress 🔹 Ethereum Core Dev 🤓 PLT Enthusiast 📜 Authored bunch of standards ⚛ FISSION Framework 💬 Clarity Language

Slide 14

Slide 14

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🧙 Open Sourceress 🔹 Ethereum Core Dev 🤓 PLT Enthusiast 📜 Authored bunch of standards λ Founded VanFP ⚛ FISSION Framework 💬 Clarity Language

Slide 15

Slide 15

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🧙 Open Sourceress 🔹 Ethereum Core Dev 🤓 PLT Enthusiast 📜 Authored bunch of standards λ Founded VanFP ⚛ FISSION Framework ⚗ Previously Elixir consultant & trainer 💬 Clarity Language

Slide 16

Slide 16

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🧙 Open Sourceress 🔹 Ethereum Core Dev 🤓 PLT Enthusiast 📜 Authored bunch of standards λ Founded VanFP ⚛ FISSION Framework ⚗ Previously Elixir consultant & trainer 💬 Clarity Language 📚 Witchcraft, Algae, Quark, Exceptional

Slide 17

Slide 17

M E TA B R O O K LY N Z E L E N K A — @ E X P E D E ♠ CEO & Chief Scientist @ SPADE Co 🧙 Open Sourceress 🔹 Ethereum Core Dev 🤓 PLT Enthusiast 📜 Authored bunch of standards λ Founded VanFP ⚛ FISSION Framework ⚗ Previously Elixir consultant & trainer 💬 Clarity Language 📚 Witchcraft, Algae, Quark, Exceptional T E G E M CO KERS! C I T S

Slide 18

Slide 18

M E TA FOLLOW UP TO LOVE POTION NUMBER 9

Slide 19

Slide 19

M E TA FOLLOW UP TO LOVE POTION NUMBER 9

Slide 20

Slide 20

M E TA STRUCTURE 🏛

Slide 21

Slide 21

M E TA STRUCTURE 🏛 • Philosophy

Slide 22

Slide 22

M E TA STRUCTURE 🏛 • Philosophy • Principles

Slide 23

Slide 23

M E TA STRUCTURE 🏛 • Philosophy • Principles • Toy Example

Slide 24

Slide 24

M E TA STRUCTURE 🏛 • Philosophy • Principles • Toy Example • (Partly also an experience report 🤫)

Slide 25

Slide 25

M E TA WHY FOCUS ON LIBRARIES? 📚

Slide 26

Slide 26

M E TA WHY FOCUS ON LIBRARIES? 📚 • Much material on language design • Language ergonomics are an active area of research

Slide 27

Slide 27

M E TA WHY FOCUS ON LIBRARIES? 📚 • Much material on language design • Language ergonomics are an active area of research • Different constraints when working inside an existing language

Slide 28

Slide 28

M E TA WHY FOCUS ON LIBRARIES? 📚 • Much material on language design • Language ergonomics are an active area of research • Different constraints when working inside an existing language • Blending languages and porting concepts

Slide 29

Slide 29

M E TA WHY FOCUS ON LIBRARIES? 📚 • Much material on language design • Language ergonomics are an active area of research • Different constraints when working inside an existing language • Blending languages and porting concepts • I agonized over how to make Haskell idioms fit into Elixir • Learn from my mistakes experiences!

Slide 30

Slide 30

M E TA C O D E I L L U S T R AT I O N S W I L L B E H I G H L E V E L

Slide 31

Slide 31

M E TA C O D E I L L U S T R AT I O N S W I L L B E H I G H L E V E L

Slide 32

Slide 32

M E TA C O D E I L L U S T R AT I O N S W I L L B E H I G H L E V E L

Slide 33

Slide 33

M E TA C O D E I L L U S T R AT I O N S W I L L B E H I G H L E V E L

Slide 34

Slide 34

TOOLS OF THOUGHT 🛠🧠 A P P L I C AT I O N S C O M E A N D G O , B U T C O N C E P T S S TAY T H E S A M E

Slide 35

Slide 35

To think is to forget a difference, to generalize, to abstract 🙂 JORGE LUIS BORGES

Slide 36

Slide 36

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀

Slide 37

Slide 37

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors

Slide 38

Slide 38

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥

Slide 39

Slide 39

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥 • Metric > Imperial

Slide 40

Slide 40

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥 • Metric > Imperial • Arabic numerals > Roman numerals

Slide 41

Slide 41

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥 • Metric > Imperial • Arabic numerals > Roman numerals • 24-hours and 360-degrees have nice divisors

Slide 42

Slide 42

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥 • Metric > Imperial • Arabic numerals > Roman numerals • 24-hours and 360-degrees have nice divisors

Slide 43

Slide 43

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥 • Metric > Imperial • Arabic numerals > Roman numerals • 24-hours and 360-degrees have nice divisors Flavours 🍨🍧

Slide 44

Slide 44

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥 • Metric > Imperial • Arabic numerals > Roman numerals • 24-hours and 360-degrees have nice divisors Flavours 🍨🍧 1. Algorithms (“how”) • ex. Long division

Slide 45

Slide 45

TOOLS OF THOUGHT 🛠🧠 TOOLS & ME THODS > BIOLOGY 🏕🔥🚀 • Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥 • Metric > Imperial • Arabic numerals > Roman numerals • 24-hours and 360-degrees have nice divisors Flavours 🍨🍧 1. Algorithms (“how”) • ex. Long division 2. Abstraction (“what”) • ex. Geometric metaphors

Slide 46

Slide 46

TOOLS OF THOUGHT 🛠🧠 N O T J U S T FA S T E R H O R S E S = 🏎

Slide 47

Slide 47

TOOLS OF THOUGHT 🛠🧠 N O T J U S T FA S T E R H O R S E S = 🏎 • Algorithms > hardware • Moore’s Law ending ☠ • Algorithms more beneficial to performance in many domains

Slide 48

Slide 48

TOOLS OF THOUGHT 🛠🧠 N O T J U S T FA S T E R H O R S E S = 🏎 • Algorithms > hardware • Moore’s Law ending ☠ • Algorithms more beneficial to performance in many domains • Abstraction very important to software quality • Because of the “human” part of HCI • (Of course a PLT person would say this 😜)

Slide 49

Slide 49

TOOLS OF THOUGHT 🛠🧠 N O T J U S T FA S T E R H O R S E S = 🏎 • Algorithms > hardware • Moore’s Law ending ☠ • Algorithms more beneficial to performance in many domains • Abstraction very important to software quality • Because of the “human” part of HCI • (Of course a PLT person would say this 😜) • Recent successes A • Machine learning • Zero knowledge proofs

Slide 50

Slide 50

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼

Slide 51

Slide 51

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼 🌌 Reality

Slide 52

Slide 52

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy

Slide 53

Slide 53

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy 🔺 Abstraction

Slide 54

Slide 54

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy 🔺 Abstraction 💭 Concepts & Practice

Slide 55

Slide 55

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy 🔺 Abstraction 💭 Concepts & Practice 🗣 Grammar & Vocabulary

Slide 56

Slide 56

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy 🔺 Abstraction 💭 Concepts & Practice 🗣 Grammar & Vocabulary 📝 Concrete Code

Slide 57

Slide 57

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy 🔺 Abstraction 💭 Concepts & Practice 🗣 Grammar & Vocabulary 📝 Concrete Code ⚙ Machine

Slide 58

Slide 58

TOOLS OF THOUGHT 🛠🧠 P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy 🔺 Abstraction 💭 Concepts & Practice 🗣 Grammar & Vocabulary 📝 Concrete Code ⚙ Machine 🎭 Real World Outcomes

Slide 59

Slide 59

TOOLS OF THOUGHT 🛠🧠 FORKING & BLENDING 🍰 🌌 🤔 🔺 💭 Context A 🗣 📝 ⚙ 🎭

Slide 60

Slide 60

TOOLS OF THOUGHT 🛠🧠 FORKING & BLENDING 🍰 🌌 🤔 🔺 💭 Context A 🗣 📝 ⚙ 🎭

Slide 61

Slide 61

TOOLS OF THOUGHT 🛠🧠 FORKING & BLENDING 🍰 🌌 🤔 🔺 💭 Context A 🗣 📝 ⚙ 🎭

Slide 62

Slide 62

TOOLS OF THOUGHT 🛠🧠 FORKING & BLENDING 🍰 🌌 🤔 🔺 💭 Context A 🗣 🗣 📝 📝 ⚙ 🎭 Context B

Slide 63

Slide 63

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭

Slide 64

Slide 64

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭 Generality • Low information • Few assumptions • Many use cases

Slide 65

Slide 65

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭 Generality Power • Low information • High information • Few assumptions • Can make many assumptions • Many use cases • Tailored to few use cases

Slide 66

Slide 66

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭 Generality Power • Low information • High information • Few assumptions • Can make many assumptions • Many use cases • Tailored to few use cases GENERALITY 🌏 ⚖ POWER 🚀

Slide 67

Slide 67

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭 Generality Power • Low information • High information • Few assumptions • Can make many assumptions • Many use cases • Tailored to few use cases GENERALITY 🌏 ⚖ POWER 🚀

Slide 68

Slide 68

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭 Generality Power • Low information • High information • Few assumptions • Can make many assumptions • Many use cases • Tailored to few use cases Enum GENERALITY 🌏 ⚖ POWER 🚀

Slide 69

Slide 69

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭 Generality Power • Low information • High information • Few assumptions • Can make many assumptions • Many use cases • Tailored to few use cases Enum GENERALITY 🌏 Ecto.Schema ⚖ POWER 🚀

Slide 70

Slide 70

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭 Generality Power • Low information • High information • Few assumptions • Can make many assumptions • Many use cases • Tailored to few use cases GenServer Enum GENERALITY 🌏 Ecto.Schema ⚖ POWER 🚀

Slide 71

Slide 71

TOOLS OF THOUGHT 🛠🧠 LIBRARY SWEE T SPOTS 🍭 Generality Power • Low information • High information • Few assumptions • Can make many assumptions • Many use cases • Tailored to few use cases GenServer Enum Libraries GENERALITY 🌏 Ecto.Schema ⚖ POWER 🚀 Applications

Slide 72

Slide 72

TOOLS OF THOUGHT 🛠🧠 A TA X O N O M Y O F L I B R A R I E S 📚

Slide 73

Slide 73

TOOLS OF THOUGHT 🛠🧠 A TA X O N O M Y O F L I B R A R I E S 📚 • Generality • ex. Witchcraft, Database Adapters

Slide 74

Slide 74

TOOLS OF THOUGHT 🛠🧠 A TA X O N O M Y O F L I B R A R I E S 📚 • Generality • ex. Witchcraft, Database Adapters • Framework • ex. Phoenix, Nerves

Slide 75

Slide 75

TOOLS OF THOUGHT 🛠🧠 A TA X O N O M Y O F L I B R A R I E S 📚 • Generality • ex. Witchcraft, Database Adapters • Framework • ex. Phoenix, Nerves • Feature Emulation • ex. TypeClass

Slide 76

Slide 76

TOOLS OF THOUGHT 🛠🧠 A TA X O N O M Y O F L I B R A R I E S 📚 • Generality • ex. Witchcraft, Database Adapters • Framework • ex. Phoenix, Nerves • Feature Emulation • ex. TypeClass • Representation & Interface • ex. Algae, Serialization

Slide 77

Slide 77

TOOLS OF THOUGHT 🛠🧠 A TA X O N O M Y O F L I B R A R I E S 📚 • Generality • ex. Witchcraft, Database Adapters • Framework • ex. Phoenix, Nerves • Feature Emulation • ex. TypeClass • Representation & Interface • ex. Algae, Serialization • Patterns • ex. Quark, Exceptional

Slide 78

Slide 78

PORTING PRINCIPLES STRE TCHING WITHOUT SNAPPING 💥

Slide 79

Slide 79

It’s dangerous to go alone! Take this [advice]!

Slide 80

Slide 80

PORTING PRINCIPLES M O T I VAT I O N 🥕

Slide 81

Slide 81

PORTING PRINCIPLES M O T I VAT I O N 🥕 • Two styles of Scala 1. Java without the braces 2. Haskell fan fiction

Slide 82

Slide 82

PORTING PRINCIPLES M O T I VAT I O N 🥕 • Two styles of Scala 1. Java without the braces 2. Haskell fan fiction • “I’d need to convert my entire project for this lib to make sense” 👎

Slide 83

Slide 83

PORTING PRINCIPLES M O T I VAT I O N 🥕 • Two styles of Scala 1. Java without the braces 2. Haskell fan fiction • “I’d need to convert my entire project for this lib to make sense” 👎 • Also have seen this antipattern in production with Ruby, Swift, and JS

Slide 84

Slide 84

PORTING PRINCIPLES M O T I VAT I O N 🥕 • Two styles of Scala 1. Java without the braces 2. Haskell fan fiction • “I’d need to convert my entire project for this lib to make sense” 👎 • Also have seen this antipattern in production with Ruby, Swift, and JS • It doesn’t have to be this way 🚀

Slide 85

Slide 85

PORTING PRINCIPLES I, LIBRARY 🤖

Slide 86

Slide 86

PORTING PRINCIPLES I, LIBRARY 🤖

  1. Context Independence Each unit of code must be able to be taken on its own. An extension may not break nor alter the runtime semantics of either enclosed or exterior code.

Slide 87

Slide 87

PORTING PRINCIPLES I, LIBRARY 🤖

  1. Context Independence Each unit of code must be able to be taken on its own. An extension may not break nor alter the runtime semantics of either enclosed or exterior code. 2. Ethos An extension must remain consistent with the character of the host language and broadest community standards, except where such consistency would conflict with the First Law.

Slide 88

Slide 88

PORTING PRINCIPLES I, LIBRARY 🤖

  1. Context Independence Each unit of code must be able to be taken on its own. An extension may not break nor alter the runtime semantics of either enclosed or exterior code. 2. Ethos An extension must remain consistent with the character of the host language and broadest community standards, except where such consistency would conflict with the First Law. 3. Completeness An extension must introduce or integrate its concept(s) as completely as possible, as long as such constructs do not conflict with the First or Second Laws.

Slide 89

Slide 89

PORTING PRINCIPLES

  1. Context Independence Each unit of code must be able to be taken on its own. An extension may not break nor alter the runtime semantics of either enclosed or exterior code. 2. Ethos An extension must remain consistent with the character of the host language and broadest community standards, except where such consistency would conflict with the First Law. 3. Completeness An extension must introduce or integrate its concept(s) as completely as possible, as long as such constructs do not conflict with the First or Second Laws.

Slide 90

Slide 90

PORTING PRINCIPLES HEY! LISTEN! 🧚 1. Courage ⚔ Each unit of code must be able to be taken on its own. An extension may not break nor alter the runtime semantics of either enclosed or exterior code. 2. Wisdom 📚 An extension must remain consistent with the character of the host language and broadest community standards, except where such consistency would conflict with the First Law. 3. Power 🚀 An extension must introduce or integrate its concept(s) as completely as possible, as long as such constructs do not conflict with the First or Second Laws.

Slide 91

Slide 91

CONTEXT INDEPENDENCE THE COURAGE TO VENTURE ALONE ⚔

Slide 92

Slide 92

CONTEXT INDEPENDENCE THE COURAGE TO VENTURE ALONE ⚔

Slide 93

Slide 93

The art of programming is the art of organizing complexity, of mastering multitude, and avoiding its bastard chaos as effectively as possible 🧘 EDSGER DIJKSTRA

Slide 94

Slide 94

Each unit of code must be able to be taken on its own. An extension must not break nor alter the runtime semantics of either enclosed or exterior code.

Slide 95

Slide 95

CONTEXT INDEPENDENCE I N D E P E N D E N C E D AY 🛸

Slide 96

Slide 96

CONTEXT INDEPENDENCE I N D E P E N D E N C E D AY 🛸 • Clarity, composability, and unambiguity • Same class of thing as referential transparency • Especially important with FP assumptions • Each chunk of code (horizontal or vertical) should be comprehensible on its own • Most common: behaviour depending on implicit or hidden state

Slide 97

Slide 97

CONTEXT INDEPENDENCE M A C R O S O K AY

Slide 98

Slide 98

CONTEXT INDEPENDENCE M A C R O S O K AY • Despite structural changes from macros • No macro mangle 🙅 • You have to try pretty hard to break this in Elixir

Slide 99

Slide 99

CONTEXT INDEPENDENCE CASE STUDY: Algae

Slide 100

Slide 100

CONTEXT INDEPENDENCE CASE STUDY: Algae • Concept: Bootstrap structs into ADTs

Slide 101

Slide 101

CONTEXT INDEPENDENCE CASE STUDY: Algae • Concept: Bootstrap structs into ADTs • Takeaway: Composition, orthogonality, structured abstraction

Slide 102

Slide 102

CONTEXT INDEPENDENCE CASE STUDY: Algae • Concept: Bootstrap structs into ADTs • Takeaway: Composition, orthogonality, structured abstraction • Removes nothing

Slide 103

Slide 103

CONTEXT INDEPENDENCE CASE STUDY: Algae • Concept: Bootstrap structs into ADTs • Takeaway: Composition, orthogonality, structured abstraction • Removes nothing • Adds • Structure DSL • Types with automatic default values • Manual default values • Constructor helpers (ex. Foo.new)

Slide 104

Slide 104

CONTEXT INDEPENDENCE CASE STUDY: Algae • Concept: Bootstrap structs into ADTs • Takeaway: Composition, orthogonality, structured abstraction • Removes nothing • Adds • Structure DSL • Types with automatic default values • Manual default values • Constructor helpers (ex. Foo.new) • Turns into vanilla Elixir

Slide 105

Slide 105

CONTEXT INDEPENDENCE CASE STUDY: Algae

Slide 106

Slide 106

CONTEXT INDEPENDENCE CASE STUDY: Algae All the features!

Slide 107

Slide 107

CONTEXT INDEPENDENCE CASE STUDY: Algae All the features!

Slide 108

Slide 108

CONTEXT INDEPENDENCE CASE STUDY: Algae All the features!

Slide 109

Slide 109

CONTEXT INDEPENDENCE CASE STUDY: Algae All the features!

Slide 110

Slide 110

CONTEXT INDEPENDENCE CASE STUDY: Algae All the features!

Slide 111

Slide 111

CONTEXT INDEPENDENCE CASE STUDY: Algae All the features!

Slide 112

Slide 112

CONTEXT INDEPENDENCE CASE STUDY: Algae All the features!

Slide 113

Slide 113

CONTEXT INDEPENDENCE CASE STUDY: Algae All the features!

Slide 114

Slide 114

CONTEXT INDEPENDENCE 42 CASE STUDY: Algae 77 All the features! 1234 98 32

Slide 115

Slide 115

CONTEXT INDEPENDENCE 42 CASE STUDY: Algae 77 All the features! 1234 98 32

Slide 116

Slide 116

CONTEXT INDEPENDENCE 42 CASE STUDY: Algae 77 All the features! 1234 98 32

Slide 117

Slide 117

ETHOS T H E W I S D O M TO B A L A N C E C O N S I ST E N CY, C H A N G E , A N D R E ST R A I N T 📚

Slide 118

Slide 118

ETHOS T H E W I S D O M TO B A L A N C E C O N S I ST E N CY, C H A N G E , A N D R E ST R A I N T 📚

Slide 119

Slide 119

The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind 🎛 KENNETH IVERSON

Slide 120

Slide 120

An extension must remain consistent with the character of the host language and broadest community standards, except where such consistency would conflict with the First Law.

Slide 121

Slide 121

ETHOS A M AT T E R O F C H A R A C T E R

Slide 122

Slide 122

ETHOS A M AT T E R O F C H A R A C T E R • Ethos — noun. (/ˈiːθɒs/ or US: /ˈiːθoʊs/) The fundamental character or spirit of a culture; the underlying sentiment that informs the beliefs, customs, or practices of a group or society; dominant assumptions of a people or period • Like all interesting things, it’s the fuzziest • Feel as close to the host language as possible • But also blending in features from a target

Slide 123

Slide 123

ETHOS A M AT T E R O F C H A R A C T E R 🌌 • Ethos — noun. (/ˈiːθɒs/ or US: /ˈiːθoʊs/) 🤔 The fundamental character or spirit of a culture; the underlying sentiment that informs the beliefs, customs, or practices of a group or society; dominant assumptions of a people or period • Like all interesting things, it’s the fuzziest • Feel as close to the host language as possible • But also blending in features from a target 🔺 💭 Host 🗣 📝 ⚙ 🎭

Slide 124

Slide 124

ETHOS A M AT T E R O F C H A R A C T E R 🌌 • Ethos — noun. (/ˈiːθɒs/ or US: /ˈiːθoʊs/) 🤔 The fundamental character or spirit of a culture; the underlying sentiment that informs the beliefs, customs, or practices of a group or society; dominant assumptions of a people or period • Like all interesting things, it’s the fuzziest • Feel as close to the host language as possible • But also blending in features from a target 🔺 💭 Host 🗣 🗣 🗣 📝 📝 📝 ⚙ 🎭 Target

Slide 125

Slide 125

ETHOS CASE STUDY: Exceptional’S PIPES

Slide 126

Slide 126

ETHOS CASE STUDY: Exceptional’S PIPES • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2

Slide 127

Slide 127

ETHOS CASE STUDY: Exceptional’S PIPES • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2

Slide 128

Slide 128

ETHOS CASE STUDY: Exceptional’S PIPES • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2

Slide 129

Slide 129

ETHOS CASE STUDY: Exceptional’S PIPES • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2

Slide 130

Slide 130

ETHOS CASE STUDY: Exceptional’S PIPES • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2

Slide 131

Slide 131

ETHOS CASE STUDY: Exceptional’S PIPES • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2

Slide 132

Slide 132

ETHOS CASE STUDY: TUPLES VS EXCEPTIONS

Slide 133

Slide 133

ETHOS CASE STUDY: TUPLES VS EXCEPTIONS • Even internal tradeoffs in Elixir’s Kernel design

Slide 134

Slide 134

ETHOS CASE STUDY: TUPLES VS EXCEPTIONS • Even internal tradeoffs in Elixir’s Kernel design • Fully adhering to the underlying Elixir’s ethos • I get the most positive feedback from Exceptional

Slide 135

Slide 135

ETHOS CASE STUDY: TUPLES VS EXCEPTIONS • Even internal tradeoffs in Elixir’s Kernel design • Fully adhering to the underlying Elixir’s ethos • I get the most positive feedback from Exceptional • Exception structs are totally antithetical to the Erlang ethos • Hard when you’re trying to be highly interoperable

Slide 136

Slide 136

ETHOS CASE STUDY: TUPLES VS EXCEPTIONS • Even internal tradeoffs in Elixir’s Kernel design • Fully adhering to the underlying Elixir’s ethos • I get the most positive feedback from Exceptional • Exception structs are totally antithetical to the Erlang ethos • Hard when you’re trying to be highly interoperable

Slide 137

Slide 137

ETHOS CASE STUDY: TUPLES VS EXCEPTIONS • Even internal tradeoffs in Elixir’s Kernel design • Fully adhering to the underlying Elixir’s ethos • I get the most positive feedback from Exceptional • Exception structs are totally antithetical to the Erlang ethos • Hard when you’re trying to be highly interoperable • Takeaway: Provide conversion functions if you go off script

Slide 138

Slide 138

ETHOS CASE STUDY: TUPLES VS EXCEPTIONS • Even internal tradeoffs in Elixir’s Kernel design • Fully adhering to the underlying Elixir’s ethos • I get the most positive feedback from Exceptional • Exception structs are totally antithetical to the Erlang ethos • Hard when you’re trying to be highly interoperable • Takeaway: Provide conversion functions if you go off script

Slide 139

Slide 139

ETHOS CASE STUDY: TUPLES VS EXCEPTIONS • Even internal tradeoffs in Elixir’s Kernel design • Fully adhering to the underlying Elixir’s ethos • I get the most positive feedback from Exceptional • Exception structs are totally antithetical to the Erlang ethos • Hard when you’re trying to be highly interoperable • Takeaway: Provide conversion functions if you go off script

Slide 140

Slide 140

ETHOS STRONG CHARACTER

Slide 141

Slide 141

ETHOS STRONG CHARACTER • Languages like C, Haskell, Rust, Elm, and Golang stand for something

Slide 142

Slide 142

ETHOS STRONG CHARACTER • Languages like C, Haskell, Rust, Elm, and Golang stand for something • Erlang designed for a practical application: telecom switches • Erlang happened to land on FP

Slide 143

Slide 143

ETHOS STRONG CHARACTER • Languages like C, Haskell, Rust, Elm, and Golang stand for something • Erlang designed for a practical application: telecom switches • Erlang happened to land on FP • Elixir doesn’t have a clear language-level raison d’être • Like tofu: very easy to port in other flavours

Slide 144

Slide 144

INTERLUDE WHEREFORE ART THOU FUNCTIONAL PROGRAMMING? 🌹

Slide 145

Slide 145

INTERLUDE W H AT ’ S S O G R E AT A B O U T F P A N Y W AY ? 🥳

Slide 146

Slide 146

INTERLUDE W H AT ’ S S O G R E AT A B O U T F P A N Y W AY ? 🥳 • Modularity • Composition • Can describe general solutions via abstraction! • Make the large feel like the small & fewer patterns to memorize Z • Maleable code • HOFs transform your programs on the fly ⚗ • ex. Enum.map/2 can be seen as adapting every item in a structure (operational), or as transforming the functor

Slide 147

Slide 147

INTERLUDE O P E R AT I O N A L V S D E N O TAT I O N A L T H I N K I N G

Slide 148

Slide 148

INTERLUDE O P E R AT I O N A L V S D E N O TAT I O N A L T H I N K I N G • Enum.map/2 can be seen through the lens of… • Data • A cleaner for loop (operational) • Run a function on every item in a structure • Programs • Transforms the input program into a new program

Slide 149

Slide 149

INTERLUDE FUNCTIONAL ALCHEMY ⚗ @spec long_form(integer()) :: String.t()

Slide 150

Slide 150

INTERLUDE FUNCTIONAL ALCHEMY ⚗ @spec long_form(integer()) :: String.t() @spec long_forms([integer()]) :: [String.t()]

Slide 151

Slide 151

INTERLUDE FUNCTIONAL ALCHEMY ⚗ @spec long_form(integer()) :: String.t() Enum.map/2 @spec long_forms([integer()]) :: [String.t()]

Slide 152

Slide 152

INTERLUDE FUNCTIONAL ALCHEMY ⚗ integer() String.t() Enum.map/2 [integer()] [String.t()]

Slide 153

Slide 153

INTERLUDE W H AT ’ S S O T E R R I B L E A B O U T F P A N Y W AY ? 😱

Slide 154

Slide 154

INTERLUDE W H AT ’ S S O T E R R I B L E A B O U T F P A N Y W AY ? 😱 • The Church Chasm • If you have a hammer, everything looks like a nail • “Use anonymous functions for everything! Aren’t closures amazing?!” • Can focus on mechanics rather than concepts • Explicit state = lots of explicit handling, “pass the world”, &c • A tendency towards the darkest of magics

Slide 155

Slide 155

INTERLUDE {:tarpit, “tradeoffs”}

Slide 156

Slide 156

INTERLUDE {:tarpit, “tradeoffs”} • Surface simplicity has a cost • Complex in the large • Restricted domain in the small

Slide 157

Slide 157

INTERLUDE {:tarpit, “tradeoffs”} • Surface simplicity has a cost • Takeaway: strive for • Complex in the large • Orthogonality • Restricted domain in the small • Generality • Extensibility

Slide 158

Slide 158

INTERLUDE ACTOR ABYSS

Slide 159

Slide 159

INTERLUDE ACTOR ABYSS • Each step is very simple

Slide 160

Slide 160

INTERLUDE ACTOR ABYSS • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to store your data for crash recovery • Called collaborator may not be there

Slide 161

Slide 161

INTERLUDE ACTOR ABYSS • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to store your data for crash recovery • Called collaborator may not be there

Slide 162

Slide 162

INTERLUDE ACTOR ABYSS • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to store your data for crash recovery • Called collaborator may not be there • Exactly why GenStage is great! • Abstract this all away for many use cases • More concrete than arrows & better matches the Elixir ethos

Slide 163

Slide 163

INTERLUDE ACTOR ABYSS • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to store your data for crash recovery • Called collaborator may not be there • Exactly why GenStage is great! • Abstract this all away for many use cases • More concrete than arrows & better matches the Elixir ethos • Complexity grows faster than linear

Slide 164

Slide 164

INTERLUDE ACTOR ABYSS • Each step is very simple • Reasoning about dynamic organisms is hard • Remember to store your data for crash recovery • Called collaborator may not be there • Exactly why GenStage is great! • Abstract this all away for many use cases • More concrete than arrows & better matches the Elixir ethos • Complexity grows faster than linear • Takeaway: provide structured abstractions

Slide 165

Slide 165

INTERLUDE LANGUAGE SPECTRUM

Slide 166

Slide 166

INTERLUDE LANGUAGE SPECTRUM Imperative Declarative

Slide 167

Slide 167

INTERLUDE LANGUAGE SPECTRUM Imperative Declarative

Slide 168

Slide 168

INTERLUDE LANGUAGE SPECTRUM Imperative Declarative

Slide 169

Slide 169

INTERLUDE LANGUAGE PYRAMID Dynamic Operational Mechanistic 🚂 •→• Universal ↓ ↓ Denotational •→• Mathematics ] Contextual Semiotic Linguistic

Slide 170

Slide 170

INTERLUDE LANGUAGE PYRAMID Dynamic Operational Mechanistic 🚂 •→• Universal ↓ ↓ Denotational •→• Mathematics Overall historical trend ] Contextual Semiotic Linguistic

Slide 171

Slide 171

INTERLUDE LANGUAGE PYRAMID Dynamic Operational Mechanistic 🚂 •→• Universal ↓ ↓ Denotational •→• Mathematics Overall historical trend ] Contextual Semiotic Linguistic

Slide 172

Slide 172

INTERLUDE LANGUAGE PYRAMID Dynamic Operational Mechanistic 🚂 •→• Universal ↓ ↓ Denotational •→• Mathematics Overall historical trend ] Contextual Semiotic Linguistic

Slide 173

Slide 173

INTERLUDE LANGUAGE PYRAMID •→• Universal ↓ ↓ Denotational •→• Mathematics 🌌 🤔 🔺 💭 🗣 📝 ⚙ 🎭 Dynamic Operational Mechanistic 🚂 Overall historical trend ] Contextual Semiotic Linguistic

Slide 174

Slide 174

INTERLUDE LANGUAGE PYRAMID •→• Universal ↓ ↓ Denotational •→• Mathematics 🔺 💭 📝 ⚙ Dynamic Operational Mechanistic 🚂 🤔 🗣 Overall historical trend ] Contextual Semiotic Linguistic

Slide 175

Slide 175

ETHOS T H E P I P E S S T R AT E G Y

Slide 176

Slide 176

ETHOS T H E P I P E S S T R AT E G Y • A break in ethos from Erlang

Slide 177

Slide 177

ETHOS T H E P I P E S S T R AT E G Y • A break in ethos from Erlang • Fits Elixir’s strategy • Clean • Easy to follow • Similar to OO’s fluent interfaces

Slide 178

Slide 178

ETHOS T H E P I P E S S T R AT E G Y • A break in ethos from Erlang • Fits Elixir’s strategy • Clean • Easy to follow • Similar to OO’s fluent interfaces • Helps to read like English

Slide 179

Slide 179

ETHOS T H E P I P E S S T R AT E G Y • A break in ethos from Erlang • Fits Elixir’s strategy • Tradeoffs • Operational/mechanistic mode of thought • Clean • Cleans up a lot of code • Easy to follow • Focus or “zoom” effect 🔭 • Similar to OO’s fluent interfaces • Zooming doesn’t really apply to actors • Helps to read like English

Slide 180

Slide 180

ETHOS T H E P I P E S S T R AT E G Y • A break in ethos from Erlang • Fits Elixir’s strategy • Tradeoffs • Operational/mechanistic mode of thought • Clean • Cleans up a lot of code • Easy to follow • Focus or “zoom” effect 🔭 • Similar to OO’s fluent interfaces • Zooming doesn’t really apply to actors • Helps to read like English • Takeaway: consider you metaphors

Slide 181

Slide 181

ETHOS G U E S T L A N G U A G E S Y N TA X E S

Slide 182

Slide 182

ETHOS G U E S T L A N G U A G E S Y N TA X E S

Slide 183

Slide 183

ETHOS G U E S T L A N G U A G E S Y N TA X E S • Which language is this?

Slide 184

Slide 184

ETHOS G U E S T L A N G U A G E S Y N TA X E S • Which language is this?

Slide 185

Slide 185

ETHOS G U E S T L A N G U A G E S Y N TA X E S • Which language is this?

Slide 186

Slide 186

ETHOS G U E S T L A N G U A G E S Y N TA X E S • Which language is this? • Does it matter?

Slide 187

Slide 187

ETHOS G U E S T L A N G U A G E S Y N TA X E S • Which language is this? • Does it matter? • Is this appropriate?

Slide 188

Slide 188

ETHOS G U E S T L A N G U A G E S Y N TA X E S 🌌 🤔 🔺 • Which language is this? • Does it matter? • Is this appropriate? 💭 🗣 🗣 📝 📝 ⚙ 🎭

Slide 189

Slide 189

COMPLETENESS THE POWER OF THE DARK SIDE 💪

Slide 190

Slide 190

COMPLETENESS THE POWER OF THE DARK SIDE 💪

Slide 191

Slide 191

COMPLETENESS THE POWER OF HARMONIOUS TOOLS 💪

Slide 192

Slide 192

The limits of my language mean the limits of my world 🙊 LUDWIG WIT TGENSTEIN

Slide 193

Slide 193

An extension must introduce or integrate its concept(s) as completely as possible, as long as such constructs do not conflict with the First or Second Laws.

Slide 194

Slide 194

COMPLETENESS SWEE T SPOTS NEED NOT BE SUGARY a🍭

Slide 195

Slide 195

COMPLETENESS SWEE T SPOTS NEED NOT BE SUGARY a🍭 • Synergistic combinators

Slide 196

Slide 196

COMPLETENESS SWEE T SPOTS NEED NOT BE SUGARY a🍭 • Synergistic combinators • ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵

Slide 197

Slide 197

COMPLETENESS SWEE T SPOTS NEED NOT BE SUGARY a🍭 • Synergistic combinators • ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵

Slide 198

Slide 198

COMPLETENESS SWEE T SPOTS NEED NOT BE SUGARY a🍭 • Synergistic combinators • ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ • ~60 symbols, depending

Slide 199

Slide 199

COMPLETENESS SWEE T SPOTS NEED NOT BE SUGARY a🍭 • Synergistic combinators • ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ • ~60 symbols, depending • “Idioms over libraries”

Slide 200

Slide 200

COMPLETENESS SWEE T SPOTS NEED NOT BE SUGARY a🍭 • Synergistic combinators • ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ • ~60 symbols, depending • “Idioms over libraries” • More than the sum of their parts

Slide 201

Slide 201

COMPLETENESS SWEE T SPOTS NEED NOT BE SUGARY a🍭 • Synergistic combinators • ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ • ~60 symbols, depending • “Idioms over libraries” • More than the sum of their parts Attribution: wikipedia user LucasVB • What a tragedy if we only had a few of these combinators!

Slide 202

Slide 202

COMPLETENESS INCOMPLETENESS 😡

Slide 203

Slide 203

COMPLETENESS INCOMPLETENESS 😡 • Often see attempts to add “just the parts I care about”

Slide 204

Slide 204

COMPLETENESS INCOMPLETENESS 😡 • Often see attempts to add “just the parts I care about” • ex. Only %Maybe{} and bind/2 in a library

Slide 205

Slide 205

COMPLETENESS INCOMPLETENESS 😡 • Often see attempts to add “just the parts I care about” • ex. Only %Maybe{} and bind/2 in a library • Could have exponentially more utility!

Slide 206

Slide 206

COMPLETENESS INCOMPLETENESS 😡 • Often see attempts to add “just the parts I care about” • ex. Only %Maybe{} and bind/2 in a library • Could have exponentially more utility! • If we see FP as a modular, adaptable system of transformations, we should have identity/1 and constant/2 combinators to stub out Enum.map/2

Slide 207

Slide 207

COMPLETENSS CASE STUDY: Witchcraft

Slide 208

Slide 208

COMPLETENSS CASE STUDY: Witchcraft • You can go pretty far with extension if you have a macros • ex. TypeClass

Slide 209

Slide 209

COMPLETENSS CASE STUDY: Witchcraft • You can go pretty far with extension if you have a macros • ex. TypeClass • Update, clean, and power up Kernel functions • Curried, async, flipped variants

Slide 210

Slide 210

CASE STUDY: Witchcraft SOURCES ⛲

Slide 211

Slide 211

CASE STUDY: Witchcraft SOURCES ⛲ • Cat Theory → Haskell & PureScript & Elm &c → Witchcraft

Slide 212

Slide 212

CASE STUDY: Witchcraft SOURCES ⛲ • Cat Theory → Haskell & PureScript & Elm &c → Witchcraft • Clean up the type class hierarchy • Haskell • Purescript • Fantasy Land Specification • and others

Slide 213

Slide 213

CASE STUDY: Witchcraft SOURCES ⛲ • Cat Theory → Haskell & PureScript & Elm &c → Witchcraft • Clean up the type class hierarchy • Haskell • Purescript • Fantasy Land Specification • and others • Some pipings and naming • Elm

Slide 214

Slide 214

CASE STUDY: Witchcraft SOURCES ⛲ • Cat Theory → Haskell & PureScript & Elm &c → Witchcraft 🌌 • Clean up the type class hierarchy 🤔 • Haskell 🔺 • Purescript 💭 • Fantasy Land Specification • and others • Some pipings and naming • Elm Elixir 🗣 📝 ⚙ 🎭

Slide 215

Slide 215

CASE STUDY: Witchcraft SOURCES ⛲ • Cat Theory → Haskell & PureScript & Elm &c → Witchcraft 🌌 • Clean up the type class hierarchy 🤔 • Haskell 🔺 • Purescript 💭 • Fantasy Land Specification • and others • Some pipings and naming • Elm Elixir 🗣 🗣 💭 🗣 🗣 🗣 📝 📝 📝 📝 📝 ⚙ 🎭

Slide 216

Slide 216

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d

Slide 217

Slide 217

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy

Slide 218

Slide 218

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies

Slide 219

Slide 219

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity

Slide 220

Slide 220

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity ✅

Slide 221

Slide 221

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity • Sometimes very hard! ✅

Slide 222

Slide 222

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity • Sometimes very hard! • Had to resort to bad puns in one instance ✅

Slide 223

Slide 223

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity • Sometimes very hard! • Had to resort to bad puns in one instance • Cute puns are an antipattern! ✅

Slide 224

Slide 224

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity • Sometimes very hard! • Had to resort to bad puns in one instance • Cute puns are an antipattern!

Slide 225

Slide 225

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity • Sometimes very hard! • Had to resort to bad puns in one instance • Cute puns are an antipattern!

Slide 226

Slide 226

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity • Sometimes very hard! • Had to resort to bad puns in one instance • Cute puns are an antipattern! • Operator >>> aliases

Slide 227

Slide 227

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity • Sometimes very hard! • Had to resort to bad puns in one instance • Cute puns are an antipattern! • Operator >>> aliases • Changed lots of argument orders

Slide 228

Slide 228

CASE STUDY: Witchcraft KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity • Sometimes very hard! • Had to resort to bad puns in one instance • Cute puns are an antipattern! • Operator >>> aliases • Changed lots of argument orders • Pipable |> everything is

Slide 229

Slide 229

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/*

Slide 230

Slide 230

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/* • Arity came in handy in a few places 🙌 • Collaborator functions renamed for metaphors so pipes make sense 😭 • Sometime have to think nonlinearly

Slide 231

Slide 231

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/* • Arity came in handy in a few places 🙌 • Collaborator functions renamed for metaphors so pipes make sense 😭 • Sometime have to think nonlinearly

Slide 232

Slide 232

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/* • Arity came in handy in a few places 🙌 • Collaborator functions renamed for metaphors so pipes make sense 😭 • Sometime have to think nonlinearly provide = (<**>)

Slide 233

Slide 233

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/* • Arity came in handy in a few places 🙌 • Collaborator functions renamed for metaphors so pipes make sense 😭 • Sometime have to think nonlinearly provide = (<**>)

Slide 234

Slide 234

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/* • Arity came in handy in a few places 🙌 • Collaborator functions renamed for metaphors so pipes make sense 😭 • Sometime have to think nonlinearly provide = (<**>)

Slide 235

Slide 235

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/* • Arity came in handy in a few places 🙌 • Collaborator functions renamed for metaphors so pipes make sense 😭 • Sometime have to think nonlinearly provide = (<**>)

Slide 236

Slide 236

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/* • Arity came in handy in a few places 🙌 • Collaborator functions renamed for metaphors so pipes make sense 😭 • Sometime have to think nonlinearly provide = (<**>)

Slide 237

Slide 237

CASE STUDY: Witchcraft liftM/liftM2/liftM3/liftM4 → lift/* • Arity came in handy in a few places 🙌 • Collaborator functions renamed for metaphors so pipes make sense 😭 • Sometime have to think nonlinearly provide = (<**>)

Slide 238

Slide 238

CASE STUDY: Witchcraft TypeClass

Slide 239

Slide 239

CASE STUDY: Witchcraft TypeClass

Slide 240

Slide 240

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols

Slide 241

Slide 241

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols

Slide 242

Slide 242

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar

Slide 243

Slide 243

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code

Slide 244

Slide 244

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 245

Slide 245

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 246

Slide 246

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 247

Slide 247

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 248

Slide 248

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 249

Slide 249

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 250

Slide 250

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 251

Slide 251

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 252

Slide 252

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 253

Slide 253

CASE STUDY: Witchcraft TypeClass • Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code • A completeness pattern • Functions for free!

Slide 254

Slide 254

CASE STUDY: Witchcraft COMPLETENESS COROLLARY: MODULARITY

Slide 255

Slide 255

CASE STUDY: Witchcraft COMPLETENESS COROLLARY: MODULARITY • Breaking up Witchcraft libs was a very good idea • Balance how much each lib should do • Marketed as more reusable 😉

Slide 256

Slide 256

CASE STUDY: Witchcraft TA K E A W AY S

Slide 257

Slide 257

CASE STUDY: Witchcraft TA K E A W AY S • Specs > Libraries • Think about how languages flow, and other physical metaphors • Naming is very important, especially with directionality • Balance between source and target language audiences • ie: folks coming from Haskell to Elixir, and from Elixir to these concepts

Slide 258

Slide 258

A N T I PA T T E R N S GETTING IT WRONG i

Slide 259

Slide 259

Experience is the name everyone gives to their mistakes 💔 O S C A R W I L D E , “L A DY W I N D E R M E R E ’ S FA N “

Slide 260

Slide 260

A N T I PAT T E R N S TORCHES AND PITCHFORKS

Slide 261

Slide 261

A N T I PAT T E R N S TORCHES AND PITCHFORKS If you feel like this you’ve probably created a monster

Slide 262

Slide 262

A N T I PAT T E R N S MIND TRAPS 🕳🧠

Slide 263

Slide 263

A N T I PAT T E R N S MIND TRAPS 🕳🧠 • Identify the way you tend to fail

Slide 264

Slide 264

A N T I PAT T E R N S MIND TRAPS 🕳🧠 • Identify the way you tend to fail • My failure mode is to enforce correctness

Slide 265

Slide 265

A N T I PAT T E R N S MIND TRAPS 🕳🧠 • Identify the way you tend to fail • My failure mode is to enforce correctness • Harder in libraries than in application code, since you have such control • Great definitional power comes with great responsibility to your users!

Slide 266

Slide 266

A N T I PAT T E R N S MIND TRAPS 🕳🧠 • Identify the way you tend to fail • My failure mode is to enforce correctness • Harder in libraries than in application code, since you have such control • Great definitional power comes with great responsibility to your users! • KISS principle 😘 • Common trap: getting too cute with names and metaphors • Names should be descriptive of what they do, not a brand exercise

Slide 267

Slide 267

A N T I PAT T E R N S FORCE PRACTICES ON USERS

Slide 268

Slide 268

A N T I PAT T E R N S FORCE PRACTICES ON USERS • Overall very happy with TypeClass • Contains my biggest regret 😖

Slide 269

Slide 269

A N T I PAT T E R N S FORCE PRACTICES ON USERS • Overall very happy with TypeClass • Contains my biggest regret 😖

Slide 270

Slide 270

A N T I PAT T E R N S FORCE PRACTICES ON USERS • Overall very happy with TypeClass • Contains my biggest regret 😖 ✅

Slide 271

Slide 271

A N T I PAT T E R N S FORCE PRACTICES ON USERS • Overall very happy with TypeClass • Contains my biggest regret 😖 • Enforced prop testing at compile time • Slow • Detracts people from using the lib ✅

Slide 272

Slide 272

A N T I PAT T E R N S FORCE PRACTICES ON USERS • Overall very happy with TypeClass • Contains my biggest regret 😖 • Enforced prop testing at compile time • Slow • Detracts people from using the lib • Wanted to encourage good practice ✅

Slide 273

Slide 273

A N T I PAT T E R N S FORCE PRACTICES ON USERS • Overall very happy with TypeClass • Contains my biggest regret 😖 • Enforced prop testing at compile time • Slow • Detracts people from using the lib • Wanted to encourage good practice • Please give user choice ✅

Slide 274

Slide 274

A N T I PAT T E R N S FORCE PRACTICES ON USERS • Overall very happy with TypeClass • Contains my biggest regret 😖 • Enforced prop testing at compile time • Slow • Detracts people from using the lib • Wanted to encourage good practice • Please give user choice • Generate test helpers ✅

Slide 275

Slide 275

A N T I PAT T E R N S REDEFINE / OVERWRITE Kernel

Slide 276

Slide 276

A N T I PAT T E R N S REDEFINE / OVERWRITE Kernel

Slide 277

Slide 277

A N T I PAT T E R N S REDEFINE / OVERWRITE Kernel

Slide 278

Slide 278

A N T I PAT T E R N S REDEFINE / OVERWRITE Kernel

Slide 279

Slide 279

A N T I PAT T E R N S REDEFINE / OVERWRITE Kernel a

Slide 280

Slide 280

A N T I PAT T E R N S A L L T H E O P E R AT O R S

Slide 281

Slide 281

A N T I PAT T E R N S A L L T H E O P E R AT O R S • Super duper handy to have 🎉

Slide 282

Slide 282

A N T I PAT T E R N S A L L T H E O P E R AT O R S • Super duper handy to have 🎉 • Limited number of operators in Elixir

Slide 283

Slide 283

A N T I PAT T E R N S A L L T H E O P E R AT O R S • Super duper handy to have 🎉 • Limited number of operators in Elixir • Operator-space collisions 💥

Slide 284

Slide 284

A N T I PAT T E R N S A L L T H E O P E R AT O R S • Super duper handy to have 🎉 • Limited number of operators in Elixir • Operator-space collisions 💥 • Handy if you’re user has one lib per application, but you don’t know

Slide 285

Slide 285

A N T I PAT T E R N S A L L T H E O P E R AT O R S • Super duper handy to have 🎉 • Limited number of operators in Elixir • Operator-space collisions 💥 • Handy if you’re user has one lib per application, but you don’t know • Always provide a named variant • Operator 😉

Slide 286

Slide 286

A N T I PAT T E R N S A L L T H E O P E R AT O R S • Super duper handy to have 🎉 • Limited number of operators in Elixir • Operator-space collisions 💥 • Handy if you’re user has one lib per application, but you don’t know • Always provide a named variant • Operator 😉

Slide 287

Slide 287

A N T I PAT T E R N S T H E O P T I O N T O D I S A M B I G U AT E

Slide 288

Slide 288

A N T I PAT T E R N S T H E O P T I O N T O D I S A M B I G U AT E What does this do?

Slide 289

Slide 289

A N T I PAT T E R N S T H E O P T I O N T O D I S A M B I G U AT E What does this do?

Slide 290

Slide 290

A N T I PAT T E R N S T H E O P T I O N T O D I S A M B I G U AT E What does this do?

Slide 291

Slide 291

PUT TING IT ALL TOGE THER 🏗

Slide 292

Slide 292

PUT TING IT ALL TOGE THER 🏗 LET’S PORT A THING 🛳

Slide 293

Slide 293

PUT TING IT ALL TOGE THER 🏗 TOY EXAMPLE 🧸

Slide 294

Slide 294

PUT TING IT ALL TOGE THER 🏗 TOY EXAMPLE 🧸 • What to port? 🤔

Slide 295

Slide 295

PUT TING IT ALL TOGE THER 🏗 TOY EXAMPLE 🧸 • What to port? 🤔 Imperative Declarative

Slide 296

Slide 296

PUT TING IT ALL TOGE THER 🏗 TOY EXAMPLE 🧸 • What to port? 🤔 • Witchcraft already exists Imperative Declarative

Slide 297

Slide 297

PUT TING IT ALL TOGE THER 🏗 TOY EXAMPLE 🧸 • What to port? 🤔 • Witchcraft already exists • Let’s go the opposite direction Imperative Declarative

Slide 298

Slide 298

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S

Slide 299

Slide 299

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S • Classes • Mutable instance variables • Constructor • Methods (static and non-static) • Dot notation & chaining • Duck typing 🦆

Slide 300

Slide 300

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S • Classes • Mutable instance variables • Constructor • Methods (static and non-static) • Dot notation & chaining • Duck typing 🦆 • Turns out that this is

Slide 301

Slide 301

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S • Classes • Mutable instance variables • Constructor • Methods (static and non-static) • Dot notation & chaining • Duck typing 🦆 • Turns out that this is 1. Totally possible

Slide 302

Slide 302

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S • Classes • Mutable instance variables • Constructor • Methods (static and non-static) • Dot notation & chaining • Duck typing 🦆 • Turns out that this is 1. Totally possible 2. A terrible idea 🤣

Slide 303

Slide 303

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S • Classes • Mutable instance variables • Constructor • Methods (static and non-static) • Dot notation & chaining • Duck typing 🦆 • Turns out that this is 1. Totally possible 2. A terrible idea 🤣 • Don’t try this at home

Slide 304

Slide 304

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S • Classes • Mutable instance variables • Constructor • Methods (static and non-static) • Dot notation & chaining • Duck typing 🦆 • Turns out that this is 1. Totally possible 2. A terrible idea 🤣 • Don’t try this at home • Trained professionals s

Slide 305

Slide 305

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S • Classes • Mutable instance variables • Constructor • Methods (static and non-static) • Dot notation & chaining • Duck typing 🦆 • Turns out that this is 1. Totally possible 2. A terrible idea 🤣 • Don’t try this at home • Trained professionals s • Just a toy example 🧸

Slide 306

Slide 306

PUT TING IT ALL TOGE THER 🏗 F E AT U R E S • Classes • Mutable instance variables • Constructor • Methods (static and non-static) • Dot notation & chaining • Duck typing 🦆 • Turns out that this is 1. Totally possible 2. A terrible idea 🤣 • Don’t try this at home • Trained professionals s • Just a toy example 🧸 • Garnet ♦

Slide 307

Slide 307

PUT TING IT ALL TOGE THER 🏗 GOING WHOLE-HOG 🐖

Slide 308

Slide 308

PUT TING IT ALL TOGE THER 🏗 GOING WHOLE-HOG 🐖 • Data hiding • All functionality behind a single interface • Essentially a struct • Instance variables persist between calls • Not going to handle inheritance, but totally possible • TypeClass does something similar

Slide 309

Slide 309

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 310

Slide 310

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 311

Slide 311

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 312

Slide 312

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 313

Slide 313

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 314

Slide 314

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 315

Slide 315

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 316

Slide 316

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 317

Slide 317

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 318

Slide 318

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 319

Slide 319

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 320

Slide 320

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 321

Slide 321

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 322

Slide 322

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 323

Slide 323

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 324

Slide 324

PUT TING IT ALL TOGE THER 🏗 GARNET V1 ♦

Slide 325

Slide 325

Slide 326

Slide 326

Slide 327

Slide 327

Slide 328

Slide 328

Slide 329

Slide 329

Slide 330

Slide 330

Slide 331

Slide 331

Slide 332

Slide 332

Slide 333

Slide 333

Slide 334

Slide 334

Slide 335

Slide 335

Slide 336

Slide 336

Slide 337

Slide 337

PUT TING IT ALL TOGE THER 🏗 STEPPING BACK FROM THE BRINK v

Slide 338

Slide 338

PUT TING IT ALL TOGE THER 🏗 STEPPING BACK FROM THE BRINK v • Too far! Revert! Revert! • 🤔 This pattern isn’t that uncommon • Aside from the dot chaining 😱 • Typically use GenServer or Agent • What can we step back?

Slide 339

Slide 339

PUT TING IT ALL TOGE THER 🏗 STEPPING BACK FROM THE BRINK v • Too far! Revert! Revert! • 🤔 This pattern isn’t that uncommon • Aside from the dot chaining 😱 • Typically use GenServer or Agent • What can we step back? • Analysis • Getter/setter sugar is fine • Zero linking control • Static methods are just regular functions • Data hiding can just be a process • Map-like interface with chaining 🙅 • Operators are cute, but names are clearer • Implicit variables: not ideal IMO, but sure • Vive les pipes 💪

Slide 340

Slide 340

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 341

Slide 341

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 342

Slide 342

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 343

Slide 343

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 344

Slide 344

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 345

Slide 345

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 346

Slide 346

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 347

Slide 347

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 348

Slide 348

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 349

Slide 349

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦

Slide 350

Slide 350

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦ ❌ struct or builder

Slide 351

Slide 351

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦ ❌ struct or builder ❌ anonymous functions

Slide 352

Slide 352

PUT TING IT ALL TOGE THER 🏗 GARNET V2 ♦ ❌ struct or builder ❌ anonymous functions (Much simpler to implement)

Slide 353

Slide 353

F I N A L TA K E A W AY S 📦

Slide 354

Slide 354

F I N A L TA K E A W AY S 📦 THE HIGH LEVEL REVIEW 👀

Slide 355

Slide 355

F I N A L TA K E A W AY S 📦 BIG THEMES

Slide 356

Slide 356

F I N A L TA K E A W AY S 📦 BIG THEMES • Standard libs are not sacred • But all lib code should feel like it belongs in there! • Just because you can doesn’t mean you should

Slide 357

Slide 357

F I N A L TA K E A W AY S 📦 BIG THEMES • Standard libs are not sacred • But all lib code should feel like it belongs in there! • Just because you can doesn’t mean you should • Library-as-language-extension (think “version x.1”)

Slide 358

Slide 358

F I N A L TA K E A W AY S 📦 BIG THEMES • Standard libs are not sacred • But all lib code should feel like it belongs in there! • Just because you can doesn’t mean you should • Library-as-language-extension (think “version x.1”) • Languages are more than keywords; they’re philosophies and practices

Slide 359

Slide 359

F I N A L TA K E A W AY S 📦 BIG THEMES • Standard libs are not sacred • But all lib code should feel like it belongs in there! • Just because you can doesn’t mean you should • Library-as-language-extension (think “version x.1”) • Languages are more than keywords; they’re philosophies and practices • Language matters less than concepts

Slide 360

Slide 360

F I N A L TA K E A W AY S 📦 BIG THEMES • Standard libs are not sacred • But all lib code should feel like it belongs in there! • Just because you can doesn’t mean you should • Library-as-language-extension (think “version x.1”) • Languages are more than keywords; they’re philosophies and practices • Language matters less than concepts • Focus on cohesion when extending or blending

Slide 361

Slide 361

F I N A L TA K E A W AY S 📦 BIG THEMES • Standard libs are not sacred • But all lib code should feel like it belongs in there! • Just because you can doesn’t mean you should • Library-as-language-extension (think “version x.1”) • Languages are more than keywords; they’re philosophies and practices • Language matters less than concepts • Focus on cohesion when extending or blending • Love your code ❤

Slide 362

Slide 362

Like punning, programming is a play on words 📚 AL AN J. PERLIS

Slide 363

Slide 363

THANK YOU, KRAKÓW z🎉 @EXPEDE GITHUB.COM/EXPEDE H E L L O @ B R O O K LY N Z E L E N K A . C O M