It was rather confusing and I consider myself well-informed about the expression problem.
But to give you some constructive feedback, your understanding, or your writing, of the expression problem lacks two fundamental concepts:
First of all, in functional languages it is as simple as in object-oriented languages to add new data types. It hard to add a variant of an existing datatype. In object-oriented languages it is also trivial to add new functions, but it is hard to add a new function for all derivates of a class. So it would be more like having a table for perfectly cooking all variants of fish.
And secondly, the solution offered by Julia is also incomplete. Both functional and object-oriented languages give you completeness guarantees. So the compiler will warn you when you miss a variant of fish (functional) for a method or a method for a particular fish (object-oriented) At least to my understanding the completeness of methods (that's the right term, no?) in Julia is unchecked. You can extend, but you can easily miss a case.
The same (unchecked extensions) can be done in functional languages with open algebraic datatypes and in object-oriented languages with default methods that throw exceptions.
Thanks for this detailed criticism, it’s quite useful.
My understanding is that for functions with more than a few arguments, it is expected in Julia that only a small subset of the possibly thousands of combinations will be covered. Thousands, because with multiple dispatch you dispatch on the types of all the arguments. The binary operator “*” in Julia has 364 methods, and that just takes two arguments. So you define the ones that are useful.
Sure, that is an absolutely sensible design decision. But for other cases completeness is vital. Consider for instance the trivial case of the map function over lists (constructed by :: and []), often abbreviated as * :
f * [ ] = [ ]
f * a::as = (f a)::(f * as)
Even if that is a nearly trivial case, it is easy to see that one could forget the first case, as all the interesting bits happen elsewhere. Now imagine, I would want to have a lazy reversal of lists, that I store as an alternative until I need to deconstruct it. I write that x~xs, meaning "x added to the end of xs".
Now I have to expand my map function as follows (because map does not care about ordering):
f * a~as = (f a) ~ (f * as)
If I miss that case (or method on Julia's case) my extension of the datatype is plain wrong.
As someone who would probably understand an explanation in real words, my eyes glazed over and I stopped parsing after about the third mention of fish. But I'm not the target audience.
In popular science articles, I much prefer paragraphs laid out with a sentence of technical description followed by a layperson's explanation and/or example. That way, if I understand the first sentence, I can skip to the next paragraph. It's been a while, but I recall this being a popular format for textbooks as well.
For a more technical description, I don't think there's a better source than Stefan Karpinski's 2019 JuliaCon talk "The Unreasonable Effectiveness of Multiple Dispatch".
I started your section about the fish and didn't finish it. I expect ArsTechnica articles to be technical; in this case I think actual code examples would be good. I think Stefan K's video referenced elsewhere in this thread used examples that are both accessible and educational.
While the explanation was a little wordy, it really helped me visualize what was happening — particular the image with cross-links, and the two different kinds of table of contents.
Now I see that the essence of the concept relates to the semantics of “categories” (mutually exclusive, collectively exhaustive) -vs- “tags”, especially when there might be multiple ways to split the domain into categories (especially when they fill out an incomplete/sparse subset of the full Cartesian product). Conventional dispatch (presumably implementation in the language?) is based on one of either functions/types as categories, while multiple dispatch uses all of these inputs as tags to specialize on the appropriate implementation.
If this perspective is correct, I would like to understand why/how the implementation conventional languages forced them into category-based single dispatch.
Many older languages don’t, Common Lisp, Erlang, and even C++ templates have multiple dispatch or similar.
Object oriented languages however largely use single dispatch due to being focused on objects and the implementation usage of vtables which work on a single object, as in C++/Java/Python.
Interesting perspective. Reminds me of how trying to index the web using categories and hierarchies gave way to search using keywords. Similar with email interfaces.
I keep reading about up and coming Julia programming language a did a quick read through of the article. Coming from a programming background I was interested in what ways Julia was different from python and more mainstream Java.
One thing that would've made things easier to understand would've been comparing Julia's multiple dispatch to Java's dynamic dispatch(they're more or less the same from what I gather). Great article over-all, easy to understand for the layman.
I think the recipe metaphor section was far too long (should have been 10% of the size maybe) and I would have preferred the actual numeric examples to be filled out instead.
More worked examples with perhaps some of the recipe metaphor mixed in would be better.
