Julia adoption: Method confusion

I have been in the ‘Programming Languages Development’ Discord (fun place) for a couple of weeks now, so many times when I bring up multiple dispatch, someone says:

“That’s messy, you quickly drown in methods, and loose sight over what signature calls what body.”

I feel like in order to help adoption, it would be nice to have some kind of reference (in the documentation) that collects all the tools and techniques, that help around that.

Currently, it seems that is still the number one concerning the people, who know at least that its different from function overloading.

I like to put together a few ideas, how you guys deal with that, and collect them on a doc page.

What do you think about it?

For me multiple dispatch is a great thing, it allow an unique way to do OOP, plus it makes abstraction and interfacing easier while avoiding the inheritance.
For example


abstract type CustomArray <: AbstractArray end

struct CArray <: CustomArray
data
end

# Then you create dispatch for size, IndexStyle, length, getindex, setindex! and you are pretty much done, you can use the different Arrays methods like broadcasting or iteration

In some ways, they are correct. It is messy and does create challenges. While Julia’s implementation is quite efficient, multiple dispatch makes us prone to inadvertent invalidations.

In practice, it is not as messy as some would imagine if we obey certain social practices such as avoiding type piracy or punning.

In many ways, I find Julia’s dispatch much more intuitive than dispatch in object oriented schemes in Java.

4 Likes

With an active runtime, we can figure out what method a call signature (which/@which) or statically dispatched call (Cthulhu.jl, would be nice if there was a @code_XX to do a non-recursive version of that). Runtime dispatch goes to multiple methods depending on the inputs, which is the point and isn’t too different from other languages. But if we’re just looking right at source code, it’s true that a call won’t usually have its input types specified (dynamic typing after all) and we can’t just search text to the method it would call even if it were statically dispatched. Static typing with little inference or avoiding multiple methods for a function (including function overloading) does have its perks, and we do have to deal with the tradeoffs.