BRIDGING THE DIVIDE 💔 ❤ ✨⚔ A NOBLE QUEST OF BOOTSTRAPS, SUGAR, AND SPECTRAL PYRAMIDS 🐉⚡
Slide 2
BRIDGING THE DIVIDE 💔 ✨⚔ A NOBLE QUEST OF BOOTSTRAPS, SUGAR, AND SPECTRAL PYRAMIDS 🐉⚡
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
M E TA
TA L K I N G A B O U T T H I S T A L K
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
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
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
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
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
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
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
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
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
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
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
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
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
M E TA
FOLLOW UP TO LOVE POTION NUMBER 9
Slide 19
M E TA
FOLLOW UP TO LOVE POTION NUMBER 9
Slide 20
M E TA
STRUCTURE 🏛
Slide 21
M E TA
STRUCTURE 🏛
• Philosophy
Slide 22
M E TA
STRUCTURE 🏛
• Philosophy • Principles
Slide 23
M E TA
STRUCTURE 🏛
• Philosophy • Principles • Toy Example
Slide 24
M E TA
STRUCTURE 🏛
• Philosophy • Principles • Toy Example • (Partly also an experience report 🤫)
Slide 25
M E TA
WHY FOCUS ON LIBRARIES? 📚
Slide 26
M E TA
WHY FOCUS ON LIBRARIES? 📚
• Much material on language design • Language ergonomics are an active area of research
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
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
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
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
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
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
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
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
To think is to forget a difference, to generalize, to abstract
🙂 JORGE LUIS BORGES
Slide 36
TOOLS OF THOUGHT 🛠🧠
TOOLS & ME THODS > BIOLOGY 🏕🔥🚀
Slide 37
TOOLS OF THOUGHT 🛠🧠
TOOLS & ME THODS > BIOLOGY 🏕🔥🚀
• Possibly use our minds less than our ancestors
Slide 38
TOOLS OF THOUGHT 🛠🧠
TOOLS & ME THODS > BIOLOGY 🏕🔥🚀
• Possibly use our minds less than our ancestors • We have better mental tools 🏹🔥
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
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
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
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
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
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
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
TOOLS OF THOUGHT 🛠🧠
N O T J U S T FA S T E R H O R S E S = 🏎
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
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
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
TOOLS OF THOUGHT 🛠🧠
P L AT O N I C I D E A L 👼
Slide 51
TOOLS OF THOUGHT 🛠🧠
P L AT O N I C I D E A L 👼 🌌 Reality
Slide 52
TOOLS OF THOUGHT 🛠🧠
P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy
Slide 53
TOOLS OF THOUGHT 🛠🧠
P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy 🔺 Abstraction
Slide 54
TOOLS OF THOUGHT 🛠🧠
P L AT O N I C I D E A L 👼 🌌 Reality 🤔 Philosophy 🔺 Abstraction 💭 Concepts & Practice
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
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
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
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
TOOLS OF THOUGHT 🛠🧠
FORKING & BLENDING 🍰 🌌 🤔 🔺 💭 Context A
🗣 📝 ⚙ 🎭
Slide 60
TOOLS OF THOUGHT 🛠🧠
FORKING & BLENDING 🍰 🌌 🤔 🔺 💭 Context A
🗣 📝 ⚙ 🎭
Slide 61
TOOLS OF THOUGHT 🛠🧠
FORKING & BLENDING 🍰 🌌 🤔 🔺 💭 Context A
🗣 📝 ⚙ 🎭
Slide 62
TOOLS OF THOUGHT 🛠🧠
FORKING & BLENDING 🍰 🌌 🤔 🔺 💭 Context A
🗣
🗣
📝
📝 ⚙ 🎭
Context B
Slide 63
TOOLS OF THOUGHT 🛠🧠
LIBRARY SWEE T SPOTS 🍭
Slide 64
TOOLS OF THOUGHT 🛠🧠
LIBRARY SWEE T SPOTS 🍭 Generality
• Low information • Few assumptions • Many use cases
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
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
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
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
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
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
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
TOOLS OF THOUGHT 🛠🧠
A TA X O N O M Y O F L I B R A R I E S 📚
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
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
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
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
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
PORTING PRINCIPLES STRE TCHING WITHOUT SNAPPING 💥
Slide 79
It’s dangerous to go alone! Take this [advice]!
Slide 80
PORTING PRINCIPLES
M O T I VAT I O N 🥕
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
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
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
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
PORTING PRINCIPLES
I, LIBRARY 🤖
Slide 86
PORTING PRINCIPLES
I, LIBRARY 🤖
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
PORTING PRINCIPLES
I, LIBRARY 🤖
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
PORTING PRINCIPLES
I, LIBRARY 🤖
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
PORTING PRINCIPLES
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
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
CONTEXT INDEPENDENCE THE COURAGE TO VENTURE ALONE ⚔
Slide 92
CONTEXT INDEPENDENCE THE COURAGE TO VENTURE ALONE ⚔
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
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
CONTEXT INDEPENDENCE
I N D E P E N D E N C E D AY 🛸
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
CONTEXT INDEPENDENCE
M A C R O S O K AY
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
CONTEXT INDEPENDENCE
CASE STUDY: Algae
Slide 100
CONTEXT INDEPENDENCE
CASE STUDY: Algae • Concept: Bootstrap structs into ADTs
Slide 101
CONTEXT INDEPENDENCE
CASE STUDY: Algae • Concept: Bootstrap structs into ADTs • Takeaway: Composition, orthogonality, structured abstraction
Slide 102
CONTEXT INDEPENDENCE
CASE STUDY: Algae • Concept: Bootstrap structs into ADTs • Takeaway: Composition, orthogonality, structured abstraction • Removes nothing
CONTEXT INDEPENDENCE
CASE STUDY: Algae All the features!
Slide 107
CONTEXT INDEPENDENCE
CASE STUDY: Algae All the features!
Slide 108
CONTEXT INDEPENDENCE
CASE STUDY: Algae All the features!
Slide 109
CONTEXT INDEPENDENCE
CASE STUDY: Algae All the features!
Slide 110
CONTEXT INDEPENDENCE
CASE STUDY: Algae All the features!
Slide 111
CONTEXT INDEPENDENCE
CASE STUDY: Algae All the features!
Slide 112
CONTEXT INDEPENDENCE
CASE STUDY: Algae All the features!
Slide 113
CONTEXT INDEPENDENCE
CASE STUDY: Algae All the features!
Slide 114
CONTEXT INDEPENDENCE
42
CASE STUDY: Algae 77 All the features!
1234 98
32
Slide 115
CONTEXT INDEPENDENCE
42
CASE STUDY: Algae 77 All the features!
1234 98
32
Slide 116
CONTEXT INDEPENDENCE
42
CASE STUDY: Algae 77 All the features!
1234 98
32
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
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
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
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
ETHOS
A M AT T E R O F C H A R A C T E R
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
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
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
ETHOS
CASE STUDY: Exceptional’S PIPES
Slide 126
ETHOS
CASE STUDY: Exceptional’S PIPES
• Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2
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
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
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
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
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
ETHOS
CASE STUDY: TUPLES VS EXCEPTIONS
Slide 133
ETHOS
CASE STUDY: TUPLES VS EXCEPTIONS
• Even internal tradeoffs in Elixir’s Kernel design
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
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
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
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
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
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
ETHOS
STRONG CHARACTER
Slide 141
ETHOS
STRONG CHARACTER
• Languages like C, Haskell, Rust, Elm, and Golang stand for something
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
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
INTERLUDE
WHEREFORE ART THOU FUNCTIONAL PROGRAMMING? 🌹
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
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
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
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
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
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
INTERLUDE
{:tarpit, “tradeoffs”}
Slide 156
INTERLUDE
{:tarpit, “tradeoffs”}
• Surface simplicity has a cost • Complex in the large • Restricted domain in the small
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
INTERLUDE
ACTOR ABYSS
Slide 159
INTERLUDE
ACTOR ABYSS • Each step is very simple
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
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
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
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
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
INTERLUDE
LANGUAGE SPECTRUM
Slide 166
INTERLUDE
LANGUAGE SPECTRUM
Imperative
Declarative
Slide 167
INTERLUDE
LANGUAGE SPECTRUM
Imperative
Declarative
Slide 168
INTERLUDE
LANGUAGE SPECTRUM
Imperative
Declarative
Slide 169
INTERLUDE
LANGUAGE PYRAMID
Dynamic Operational Mechanistic
🚂
•→• Universal ↓ ↓ Denotational •→• Mathematics
]
Contextual Semiotic Linguistic
ETHOS
T H E P I P E S S T R AT E G Y
• A break in ethos from Erlang
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
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
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
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
ETHOS
G U E S T L A N G U A G E S Y N TA X E S
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
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
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
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
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
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
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
COMPLETENESS THE POWER OF THE DARK SIDE 💪
Slide 190
COMPLETENESS THE POWER OF THE DARK SIDE 💪
Slide 191
COMPLETENESS
THE POWER OF HARMONIOUS TOOLS 💪
Slide 192
The limits of my language mean the limits of my world
🙊 LUDWIG WIT TGENSTEIN
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
COMPLETENESS
SWEE T SPOTS NEED NOT BE SUGARY a🍭
Slide 195
COMPLETENESS
SWEE T SPOTS NEED NOT BE SUGARY a🍭
• Synergistic combinators
Slide 196
COMPLETENESS
SWEE T SPOTS NEED NOT BE SUGARY a🍭
• Synergistic combinators •
↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵
Slide 197
COMPLETENESS
SWEE T SPOTS NEED NOT BE SUGARY a🍭
• Synergistic combinators •
↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵
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
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
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
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
COMPLETENESS
INCOMPLETENESS 😡
Slide 203
COMPLETENESS
INCOMPLETENESS 😡
• Often see attempts to add “just the parts I care about”
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
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
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
COMPLETENSS
CASE STUDY: Witchcraft
Slide 208
COMPLETENSS
CASE STUDY: Witchcraft
• You can go pretty far with extension if you have a macros • ex. TypeClass
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
CASE STUDY: Witchcraft
SOURCES ⛲
Slide 211
CASE STUDY: Witchcraft
SOURCES ⛲
• Cat Theory → Haskell & PureScript & Elm &c → Witchcraft
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
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
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
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
CASE STUDY: Witchcraft
KEEPIN’ IT WITCHY d
Slide 217
CASE STUDY: Witchcraft
KEEPIN’ IT WITCHY d • Imported things with immediate synergy
Slide 218
CASE STUDY: Witchcraft
KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies
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
CASE STUDY: Witchcraft
KEEPIN’ IT WITCHY d • Imported things with immediate synergy • Easy with type class hierarchies • Renamed many functions for clarity ✅
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
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
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
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
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
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
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
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
CASE STUDY: Witchcraft
liftM/liftM2/liftM3/liftM4 → lift/*
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
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
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
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
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
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
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
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
CASE STUDY: Witchcraft
TypeClass
Slide 239
CASE STUDY: Witchcraft
TypeClass
Slide 240
CASE STUDY: Witchcraft
TypeClass
• Fully desugars into • Modules • Protocols
Slide 241
CASE STUDY: Witchcraft
TypeClass
• Fully desugars into • Modules • Protocols
Slide 242
CASE STUDY: Witchcraft
TypeClass
• Fully desugars into • Modules • Protocols • Tons of sugar
Slide 243
CASE STUDY: Witchcraft
TypeClass
• Fully desugars into • Modules • Protocols • Tons of sugar • Generates a bunch of code
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
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
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
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
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
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
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
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
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
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
CASE STUDY: Witchcraft
COMPLETENESS COROLLARY: MODULARITY
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
CASE STUDY: Witchcraft
TA K E A W AY S
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
A N T I PA T T E R N S GETTING IT WRONG i
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
A N T I PAT T E R N S
TORCHES AND PITCHFORKS
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
A N T I PAT T E R N S
MIND TRAPS 🕳🧠
Slide 263
A N T I PAT T E R N S
MIND TRAPS 🕳🧠
• Identify the way you tend to fail
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
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
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
A N T I PAT T E R N S
FORCE PRACTICES ON USERS
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
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
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
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
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
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
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
A N T I PAT T E R N S
REDEFINE / OVERWRITE Kernel
Slide 276
A N T I PAT T E R N S
REDEFINE / OVERWRITE Kernel
Slide 277
A N T I PAT T E R N S
REDEFINE / OVERWRITE Kernel
Slide 278
A N T I PAT T E R N S
REDEFINE / OVERWRITE Kernel
Slide 279
A N T I PAT T E R N S
REDEFINE / OVERWRITE Kernel
a
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
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
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
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
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
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
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
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
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
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
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
PUT TING IT ALL TOGE THER 🏗
Slide 292
PUT TING IT ALL TOGE THER 🏗 LET’S PORT A THING 🛳
Slide 293
PUT TING IT ALL TOGE THER 🏗
TOY EXAMPLE 🧸
Slide 294
PUT TING IT ALL TOGE THER 🏗
TOY EXAMPLE 🧸
• What to port? 🤔
Slide 295
PUT TING IT ALL TOGE THER 🏗
TOY EXAMPLE 🧸
• What to port? 🤔
Imperative
Declarative
Slide 296
PUT TING IT ALL TOGE THER 🏗
TOY EXAMPLE 🧸
• What to port? 🤔 • Witchcraft already exists
Imperative
Declarative
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
PUT TING IT ALL TOGE THER 🏗
F E AT U R E S
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
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
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
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
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
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
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
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
PUT TING IT ALL TOGE THER 🏗
GOING WHOLE-HOG 🐖
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
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 310
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 311
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 312
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 313
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 314
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 315
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 316
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 317
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 318
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 319
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 320
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 321
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 322
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 323
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 324
PUT TING IT ALL TOGE THER 🏗
GARNET V1 ♦
Slide 325
Slide 326
Slide 327
Slide 328
Slide 329
Slide 330
Slide 331
Slide 332
Slide 333
Slide 334
Slide 335
Slide 336
Slide 337
PUT TING IT ALL TOGE THER 🏗
STEPPING BACK FROM THE BRINK v
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
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
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 341
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 342
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 343
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 344
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 345
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 346
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 347
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 348
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 349
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
Slide 350
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
❌ struct or builder
Slide 351
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
❌ struct or builder
❌ anonymous functions
Slide 352
PUT TING IT ALL TOGE THER 🏗
GARNET V2 ♦
❌ struct or builder
❌ anonymous functions
(Much simpler to implement)
Slide 353
F I N A L TA K E A W AY S 📦
Slide 354
F I N A L TA K E A W AY S 📦 THE HIGH LEVEL REVIEW 👀
Slide 355
F I N A L TA K E A W AY S 📦
BIG THEMES
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
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
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
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
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
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
Like punning, programming is a play on words
📚 AL AN J. PERLIS
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