The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski | JuliaCon 2019

If you're familiar with Julia and its ecosystem, you may have noticed something lovely but a bit puzzling: there seems to be an unusually large amount of code reuse between packages compared to other seemingly similar languages. This sharing of code comes in two forms:

1. Sharing basic types among a wide variety of packages providing disparate functionality;
2. Sharing generic algorithms that work on various implementations of common abstractions.

Why does generic code in Julia "just work"? Why do Julia packages seem to share types with so little friction? Both kinds of reuse are supposed to be natural benefits of class-based object-oriented languages. After all, inheritance and encapsulation are two of the four pillars of OOP. Even more puzzling is that Julia has no encapsulation and doesn't allow inheriting from concrete types at all. Yet both kinds of code reuse are rampant. What is going on? In this talk, I make the case that both of kinds sharing stem directly from Julia's multiple dispatch programming paradigm.

[HungNguyen-lzxb]

I lost count of how many time I watch this videos. It just gets better the more I dig into Julia

[Slab]

Good job. In addition, you could have compared the complete version of the c++ code (which have the same dynamic behavior using virtual methods). This would have been even more highlighted the simplicity of Julia.

[jaxjax]

I had no idea what multiple dispatch was and its just a mere 35 minutes and now I know. Brilliant.

[weiyuanwu]

I think one problem with multipledispatch comparing to a trait system is that the developer needs to know and fully understand the detail of a function in order to let that function use some optimized operation for calculation. E.g. in the "inner" example, one needs to read the code of the function "inner" then can he know the function "inner" uses "*" (multiplication). After that, he can write a specialized "*" for the "OneHotVector". This may be obvious for "inner" but sooner it becomes not obvious for other complicated functions.

[hankigoe]

Not trying to be a wet blanket, but wouldn't it be more apt to say that the expressive power is polynomial rather than exponential? Which is still good, just sayin

[siquod]

Type classes also solve this problem, but statically (and optionally dynamically, with existential types). How do the solutions compare?

[matiasgrioni]

There's serious complexity with implementing multiple dispatch and it increases the overhead of function calls. Already function inlining is huge for performance, but if every function has to be looked up dynamically that may take serious overhead. Either something like JIT or language runtime needs to be exist or it needs to be opt in like C++ virtual. MD is absurdly useful for sure, but it's not trivial to implement or fit into exisiting languages.

[daveola]

Looks fascinating and I'm curious look back at my code and see if there are places where I could have really used multiple dispatch, or if I would have written my code differently if I'd had multiple dispatch which I think is the more important question.

Having said that, I do think that as far as the common types single dispatch goes for what you call CBOO, you give only two solutions. I'd be curious what you think about the third solution implemented by languages like Ruby that allow packages to modify and add methods to already closed classes. It trades off one namespace problem for another, as you mentioned, in Ruby you have to be careful with naming menu when you insert methods in a previously defined class. It has the benefits of using the same namespace, with the obvious trade off of possibly having collisions.

[grenouilloux]

Just to mention that in c++ you can make the encouter function a template function and it solves the problem for any type you'll give (even future type like Lion or even Sloth, as long as you overload the meet function with the corresponding behavior, as you did in the julia's snippet).
And it comes with a 0 overhead efficiency, compiler will generate the right functions according to the type you gave.
Plus with such template function you don't need the pet class at all.

[nivo]

Please cut the silent parts using youtube editor

[TheDBPhantom]

"It just works" - a great man

[DayB]

Is there a way to have "name" be part of Pet and not having to re-define it for every subtype?
Edit: I found it mentioned in the video and also that it's a long discussed controversial feature, but still I didn't find anything regarding programming. If the fields are in the abstract type there are tons of checks that can be done in compilation time and save you future heart attacks.

[DanloBC]

This video does have a lot of incredibly interesting moments. Like in 7:15. Dog and Cat are both pets but they have to have "name" declared explicitly. What if I have 28 types of pets, would I have to declare all structs with names (and ages, for example) to them?

Also, "meets" shows how we can have "a" and "b" being Dog, Cat or Cat, Dog respectively. That's a cool feature, but what if both methods returned "fights". Is there a way to write it so that I only need 1 Dog and 1 Cat (in any position), or do I really need to duplicate this specific line of code?

[tommy]

Could we download the presentation slides?

[qmster]

How is this different from trait objects (dyn) in Rust?

[slawomirgontarek]

Wery good lesson. What best books according to can you offer you Julia for learning?

[richardbenes]

To slide at 27:40 - I think that this Expression problem is nicely solved by Interfaces, hugely used not by in OO langs. They make it possible to define new types for existing operations by implementing them on existing types, and also define new operations for existing types - again by implementing new interfaces for those already existing types. I like this concept for being runtime-costless. However, I don't know Julia at all, even though it looks really nice for that "numeric" stuff. And the use of Unicode - that's amazing :D

[gert-janvanderkamp]

People laud multiple dispatch, but you really should say multiple dispatch with a type hierarchy. MD would not fly without it.

[MCRuCr]

I struggle with the question of how to *properly* assemble new types in a sensible way. Like there are few concrete guildelines .. i

[cmdrwhiskeygalore]

Reflection will be added to C++ next. Why not multiple dispatch? What if?