Dispatch:

Hey peeps, that's me!

Dispatch:

And if you have a dispatcher, which is what I do, then you call what you need at the right time. There's no need for extra fussing about! Sometimes you need to call a cab, sometimes its a delivery driver, sometimes its a helicopter. Just dispatch on what you need.

Dispatch:

Yup, there's a lot of fancy words. It can be hard to describe where you are standing to other people because the Kingdoms of Nouns monopolized the programming language map-making business decades ago.

Now it sucks to get directions anywhere.

But it's cool – just take a deep breath, and, like a well oiled StepMaster, we'll do this one step at a time.

On namespaces as well, those debates are just not going to be as big a problem in Julia Land – we're not too far from them in the theory, but the language doesn't actively prevent you from doing what you already know. In fact, if you know addition, you already have a natural notion of what multiple dispatch is about.

Dispatch:

Of course! What's more natural than addition? You just haven't used the name multiple dispatch for it, which is fine. Bear with me for some simple arithmetic: Can you describe the procedure you know for adding integers? Say you want to add 123 + 890. (This is a good moment to install and open julia from julialang.org if you haven't already done so.)

Dispatch:

Yup. What about trying to add 1//2 + 1//3. Those "fractions" are what we call Rationals in Julia. What procedure do you follow then?

Dispatch:

Swell. And .25 + 5.2? You're still "adding" things right?

Dispatch:

Excelente, ignore the decimals for now. Did you ever face matrices? Can you try to add 2x2 matrix of 1s and a 2x2 matrix of 3s?

Dispatch:

Alright – thanks for following along. Now here's the tickler question – Who does the + belong to?

Dispatch:

Exactly. If you know you're adding 2 Natural numbers, you just use, (or when coding, call) the right procedure. If you + 2 decimal numbers, you call the right thing. It's the addition you've always known! There's this notion of what + should do in different cases, and we wrap them all up under the same + umbrella – even though addition of matrices, decimals and natural numbers mean different procedures. You can check all the ones that come out of the box if you try this:

Dispatch:

Nothing – that's the point! At least not in Julia. It doesn't make sense to say that the + belongs to the 1 or the 2 in the statement 1 + 2, and that's where the headaches come from: when you bind identity to objects, you're gonna have a bad time, as 80s lisp hackers and philosophers alike have struggled with that question for a long, long time – it's just devilishly hard to reason about identity when objects change. Avoid worrying about that if you can. Just worry about calling the right procedure in the right case. In other words, "just dispatch and carry on."

Dispatch:

Great! You're on your way to learn the Zen of Julia!. It usually looks like

1. Setup an abstract type like Things.

2. Make some structs that are subtypes of Things with <:

3. Define functions f that act on specific subtypes of Things – aka dispatching.

4. Create your structs/objects with constructors like x = Foo() and then call f(x) to handle different behaviors.

That's it!

Small nitpick – You actually can dispatch in Python, but it requires a bit of boilerplate, but that's a secondary concern. Since it wasn't a foundational design of the language, people didn't build a vocabulary or an ecosystem around it. In the words of Turing award winner Barbara Liskov,

The quality of software depends primarily on the programming methodology in use. […] A methodology can be easy or difficult to apply in a given language, depending on how well the language constructs match the structures that the methodology deems desirable. […] – Barbara Liskov, Abstractions Mechanisms in CLU (1977)

(Shoutout to Quinn Wilton and her great Gleam presentation were I took this quote from). Basically, not all tools can fit nicely into a particular niche, and insisting otherwise is a recipe for frustration, but I guess some companies just have billions in cash for R+D to burn. It's not only honest, but necessary, to know the limitations of your own tools.

Dispatch:

🎉 Correct! 🎉 Julia has benefitted immensely from the efforts of others. We gain nothing from being smug about recent successes – there's still lots of problems to solve and it's in our best interests that we nurture a diverse community of people that we can cross-pollinate ideas with. Maybe someone implements multiple dispatch with some different tradeoffs in Python (like the Plum library!), or type class resolution in Lean or whatever they're building with F* that shows us a new way of thinking. We lose nothing by encouraging people to experiment, far and wide.

Dispatch:

Hmmm, hard to say, I think we'd need to reach out to a legit PL historian for that. However, looking at some of the other key components that coalesce together helps suss some of it out:

1. Common Lisp had an easy opt-in multiple dispatch system, but it was slow. People didn't buy in because it cost performance. There's a social factor to this – if your paradigm takes more effort to use, it's less likely to be grow.

2. Performance was not an afterthought. Look at the graveyard of attempts to speed up Python, all mutually incompatible. The Julia devs designed the abstractions to match LLVM semantics to optimize for performance. At some point, you have to ask if you're standing in the right place to begin with, like the London cabby:

Excuse me, what's the best way to get to Manchester?

Ah, Manchester? I wouldn't start from here…

I don't think Python for performance has failed, but wouldn't start with a language that takes 28 bytes to store an integer:

Python 3.9.3 (default, Apr  8 2021, 23:35:02)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sys import getsizeof
>>> getsizeof(1)
28

whereas

julia> sizeof(1) # This is in bytes, so an Int on my system is 64 bits
8

3. Speaking of LLVM – JIT compilers are a recent invention, and if LLVM didn't have an open source implementation, who knows if Julia would have picked up. Caching the computation really helps to overcome the beaurocratic overhead of the dispatching system, and it's not at all trivial to see those two things and put them together. But don't take my word for it, hear them say why it wasn't practical then:

4. That video tells precisely the pain-point that Stefan talked about for functional languages in his talk: In Functional Land, it's easy to add new procedures to old types, but unwieldy to add new types to old functions.

Concretely, the code that stumps object oriented PLs is

f(x::Foo) = "Just Foo"
f(x::Bar) = "Just Bar"

and the one that stumps functional language oriented PLs without multiple dispatch is

struct Qux <: Things end
t = Qux()
f(t)

Dispatch:

Yeesh.

Remember the starting claim for this discussion? It felt so long ago… but the gist was that for all the bells and whistles that Julia has, they needed time and effort to figure out some hard problems that other people had come up against (and whose expertise they drew from!). Julia is the place to park a decision until it gets done right, with oodles of discussions from experts back and forth. That's not a linear process, but I can't complain, we're still increasing the SmileFactor of all the things that feel like they should work, and do. Like the REPL.