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

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

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

Brooklyn Zelenka @expede

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

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

PING ME AND WE’LL MAIL SOME Stickers!

This Talk is About…

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

This is the Big Idea 💭💡🚀

Big Idea One Liner 🛸 Work at a higher level 🔭

Big Idea Language Design Reflects Intended Use 🌐

Big Idea Who’s Org Looks Like This?

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

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

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

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

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

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

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

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

In the Large 🌎

In the Large Code You Used to Write Imperative

In the Large Code You Used to Write Imperative

In the Large “Good” Elixir Imperative

  • Functional core, imperative shell

In the Large “Good” Elixir Imperative λ

  • Functional core, imperative shell

In the Large Imperative 3LA Future Imperative λ

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

In the Large Prop & Model Test Imperative

GOTO Considered Harmful 🤖😵

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

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

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

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

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

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

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

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

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

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

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

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

GOTO Considered Harmful Structured Programming while

GOTO Considered Harmful Structured Programming • Subroutines while

GOTO Considered Harmful Structured Programming • Subroutines • Loops while

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

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

GOTO Considered Harmful The Next Generation 🚀

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

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

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

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

GOTO Considered Harmful Tradeoffs

GOTO Considered Harmful Tradeoffs • Exchange granular control for structure

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

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

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

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

250 GOTO Considered Harmful Payoff Structured Unstructured

250 GOTO Considered Harmful COMPLEXITY Payoff Structured Unstructured TIME

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

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

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

On Complexity 🌱🌸🌾

On Complexity Overused

On Complexity Overused

On Complexity The Bad Kind ☠

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

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

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

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting

On Complexity Orthogonal Complecting 🕐

On Complexity Orthogonal Complecting 🕐 Structures: 4

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

On Complexity Complex != Complicated

On Complexity Complex != Complicated • Complex — interconnected parts

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

Abstraction & DSLs The Power of Words

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

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

On Complexity The Actor Abyss

On Complexity The Actor Abyss • Each step is very simple

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

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

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

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

Fighting GenSoup 🚫🍲⚔

Fighting GenSoup Good Interfaces != Good Abstractions

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

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

Fighting GenSoup Good Interfaces != Good Abstractions • GenServer & co are actually pretty low level • Please add some semantics 🙏 • Don’t reinvent the wheel every time 🎡 • Let’s look at a very common example

Fighting GenSoup Abstraction

Fighting GenSoup Simple Case: Map

Fighting GenSoup Async Case: Part I (defstruct)

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

Fighting GenSoup What Did We Get?

Fighting GenSoup What Did We Get? • Common interface

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

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

Fighting GenSoup Abstraction = Focus & Essence

Fighting GenSoup Abstraction = Focus & Essence

Fighting GenSoup Abstraction = Focus & Essence 🙈

Abstraction & DSLs Not Getting Trapped in the Details

Abstraction & DSLs Commonalities

Abstraction & DSLs Commonalities • They clearly have a similar structure

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

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

Abstraction & DSLs Commonalities

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

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

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

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

Abstraction & DSLs Start From Rules 📋

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

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

Abstraction & DSLs 2-Phase

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

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

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

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

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

Abstraction & DSLs Improving Kernel

Abstraction & DSLs Improving Kernel • Fallback keys

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

Abstraction & DSLs Improving Kernel with Fallback Keys

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

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) • More general (works everywhere) • Ad hoc function extension

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) • More general (works everywhere) • Ad hoc function extension

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) • More general (works everywhere) • Ad hoc function extension

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) • More general (works everywhere) • Ad hoc function extension

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) • More general (works everywhere) • Ad hoc function extension

Abstraction & DSLs Improving Kernel with Fallback Keys • Insight: • Composition is at the heart of modularity • Orthogonality is at the heart of composition • Let’s abstract default values! • More focused (does one thing) • More general (works everywhere) • Ad hoc function extension

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Abstraction & DSLs A Note on Metaphor

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

Abstraction & DSLs A Note on Metaphor • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Abstraction & DSLs A Note on Metaphor • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Abstraction & DSLs A Note on Metaphor • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Abstraction & DSLs A Note on Metaphor • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Abstraction & DSLs A Note on Metaphor • Concept: Flow-ability is very core to Elixir’s ethos • Kernel.|>/2 • Consistent flow metaphor / punning on existing metaphor • Exceptional: ~>/2 and >>>/2 Because it’s easier now

Abstraction & DSLs What’s Gained

Abstraction & DSLs What’s Gained • Clear

Abstraction & DSLs What’s Gained • Clear • Composable

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

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

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

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

Abstraction & DSLs Storytelling 📖

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

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

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

Abstraction & DSLs How to Eat the Elephant 🍴

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

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

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

Intermission Puzzle 🧩

Intermission Puzzle What Do The Following Have In Common?

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

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

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

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

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

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

Structure One of these things is like all the others

Structure There Are Only Three Right Answers 1 2 3

Structure There Are Only Three Right Answers 1 2 3

Structure Associativity

Structure Associativity • Not a data structure

Structure Associativity • Not a data structure • Not a function

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

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

Structure A Semigroup On…

Structure A Semigroup On…

Structure An Unlawful Counterexample 🚨

Structure How to Enforce Properties

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

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

Power Up Explicit Assumptions

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

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

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

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

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

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

Power Up Pipes++

Power Up Pipes++

Power Up Pipes++

Power Up Pipes++

Power Up How?!

Power Up How?!

Power Up Cleanup

Power Up Cleanup

Power Up Carrier Data

Power Up Carrier Data

Power Up Carrier Data

Power Up Carrier Data

Power Up Carrier Data

Power Up Carrier Data

Power Up Base Case

Power Up Base Case

Power Up Base Case

Power Up Async

Power Up Async

Power Up Async

Power Up Async

Power Up Upshot

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

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

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

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

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

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

A Call for Libraries

A Call for Libraries Summary

A Call for Libraries Summary • Can plug into / extend

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

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

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

A Call for Libraries Extend Railroad Programming

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

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

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

A Call for Libraries Surprising Number of Factors

A Call for Libraries Surprising Number of Factors Log Program

A Call for Libraries Surprising Number of Factors Log Program

Summary

Summary Keep In Mind…

Summary Keep In Mind… • Protocols-for-DDD

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

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

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

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

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

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

LIBRARY PRINCIPLES 📚 GENERALITY SWEET SPOTS 🍭

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

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

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

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

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

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

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

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