The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski | JuliaCon 2019 on HackerTube: recommended by 9 Hacker News commenters across 6 separate months, 2019–2025.
talk · intermediate · evergreen
Julia co-creator Stefan Karpinski explains why multiple dispatch makes Julia code and types reusable across packages with so little friction. He covers sharing basic types and sharing generic algorithms.
HN commenters recommend it as the definitive explanation, from a language designer, of why multiple dispatch makes Julia's composability work.
“a talk by a core developer at JuliaCon 2019 titled 'The unreasonable effectiveness of multiple dispatch'”
20 Hacker News comments link this video. Each one links back to its thread.
Did you mean "unreasonable effectiveness"? :P I just watched that talk the other day, and boy is it insightful. Julia has cracked a fairly magical combination of features. I fully expect it to replace Python over the next 10 years. Direct link to "Unreasonable Effectiveness": ▶ this video
in “JuliaCon 2020 Goes Online” · View on HN
Julia's model is based around multimethods, which enables pretty crazy levels of interoperability (imagine being able to use scipy and tensorflow together, with tensorflow's autograd just magically working on most of scipy's functions). More about it here ▶ this video
in “Julia 1.6: what has changed since Julia 1.0?” · View on HN
Indeed, Julia's abstract type system with multiple dispatch is its killer feature. It enables generic programming in a beautiful and concise fashion. Here [1] Stefan Karpinski gives some explanations of why multiple dispatch is so effective. [1] ▶ this video
in “Quick Overview of Julia language [pdf]” · View on HN
I like to watch talks by programming language designers. Some that readily come to mind are Rich Hickey, Joe Armstrong (RIP), and Stefan Karpinski. Some of my favorites are: - Simple Made Easy (Hickey): [link] - The Mess We're In (Armstrong): [link] - The Unreasonable Effectiveness of Multiple Dispatch (Karpinski): ▶ this video
in “Ask HN: What is your favorite YouTube channel to learn advanced programming?” · View on HN
The core problem with class-based object orientation is that methods go inside of the type instead of being added externally. That means everyone has to agree on what methods can be called on a class or they have to subtype it, which sounds harmless, but is actually a big problem when what you really wanted to do was just define a new method for an existing type. My best attempt at explaining: ▶ this video There's also the issue that one sometimes needs to specialize generic operations in generic algorithms on something other than the receiver—sometimes even on more than one of the arguments. Single dispatch forces you to use something slow and awkward like double dispatch in cases like this. And that's assuming the person who wrote the generic code anticipates the need for specialization! If they don't allow for it, then you're just stuck. With multiple dispatch, you can just define the method you need the specialization for and you're done.
in “The Accelerating Adoption of Julia” · View on HN
What? I used to write python, and to me, MD is first and foremost a conceptual improvement. Makes writing code so much sweeter, more expressive and sensical. It also heavily improves composability. It's LESS performant if not done carefully. Certainly FastAI, Matt rocklin etc didn't reimplement a subset in python just to get slower code See ▶ this video
in “The Accelerating Adoption of Julia” · View on HN
"The Unreasonable Effectiveness of X" is a reference to the well-known 'the unreasonable effectiveness of mathematics in the natural sciences'. It's turned into some sort of meme. Maybe you've seen 'the unreasonable effectiveness of recurrent neural networks' before. What you were referring to is a talk by a core developer at JuliaCon 2019 titled 'The unreasonable effectiveness of multiple dispatch' [1], which has less of a fanboy-vibe imho. Edit: Oh. I didn't notice the arstechnica article had this exact title. That's a bit cheap... [1] ▶ this video
in “Why Does Julia Work So Well?” · View on HN
You might also enjoy Stefan Karpinski’s talk at JuliaCon 2019 about how multiple dispatch helps make the language more expressive (than OOP, for Eg). The unreasonable effectiveness of multiple dispatch ▶ this video It seems like such an elegant idea, I’m somewhat surprised no one seems to have run with it earlier.
in “Multiple Dispatch in Julia” · View on HN
It's hard to say limited benefit when the entire Julia ecosystem evolved to so heavily rely on it, to allow for each package to work on it's own level of abstraction: For example, the Julia's standard library implements all of the basic math operators on the CPU, and libraries like Flux then define it's own methods to implement the higher level operators used in ML (such as convolutional layers and activation functions). And then someone writes those same basic math operators but instead of running on CPU they run on GPU, and for that they use a new type (CUArray). The original library knows nothing about CUArrays, it will call the same basic operators as always, but since they have a different type (received from the user) they'll dispatch to the GPU version. This kind of interaction can grow indefinitely, for example if you use a complex number type/library it will change the basic operators to deal with both real and imaginary parts, and if you use the GPU types within it, then it will do complex math in the GPU (and ML on complex math on GPU..., without any of the libraries being aware of the other). You can see a more detailed explanation on: ▶ this video
in “Julia library for fast machine learning” · View on HN
I remember the pitch for Julia early on being matlab-like syntax, C-like performance. When I've heard Julia mentioned more recently, the main feature that gets highlighted is multiple-dispatch. ▶ this video I think it seems pretty interesting.
in “In Defense of Matlab Code” · View on HN
Julia adds some pretty amazing stuff with multiple dispatch and run-time compilation. What this means is that you can glue code together in ways impossible for other languages. One example is a system that I built using three libraries. One was a C library from Postgres for geolocation, another was Uber's H3 library (also C) and a third was a Julia native library for geodesy. From Julia, I was able to extend the API of the H3 library and the Postgres library so that all three libraries would inter-operate transparently. This extension could be done without any mods to the packages I was important. Slightly similar, if you have a magic whizbang way of looking at your data as a strange form of matrix, you can simply implement a few optimized primitive matrix operations and the standard linear algebra libraries will now use your data structure. Normal languages can't really do that. More on that second case and the implications in the following video: ▶ this video
in “Julia and JuliaHub: Advancing Innovation and Growth” · View on HN
Yes. Its a side effect of multiple dispatch being the core paradigm of the language. See Stefan Karpinski's talk about it: ▶ this video
in “Correctness and composability bugs in the Julia ecosystem” · View on HN
Composability via dispatch-oriented programming, e.g. [1] It also pretty much solved my version of the two-language problem, but that means different things to different people so ymmv. [1] ▶ this video
in “Julia Computing raises $24M Series A” · View on HN
Looks like a decent basic summary. Section G.2.6 should probably be called "Multiple Dispatch" rather than "Function Overloading" though. Defining multiple methods of the same function in Julia is different to function overloading in a language like C++ [1]. [1] ▶ this video
in “Quick Overview of Julia language [pdf]” · View on HN
I like Julia's solution to it : Multiple dispatch. It's great for code reuse and generic algorithms, but it kind of need the magic of the Julia compiler to make it shine. JuliaCon 2019 | The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski ▶ this video
in “In Defense of a Switch” · View on HN
Regardless of what is a subset of what, I certainly agree with the OP that OOP feels "anemic" in comparison to the dispatch-based paradigm of Julia. I can't tell you how many times I've seen disparate packages written by different authors with no explicit effort towards interoperability "just work" together in Julia (e.g., [1]), something I have never seen to a comparable degree in any other language. [1] ▶ this video
in “Julia as a CLI Calculator” · View on HN
Object orientation is not really about making use of structs - many (most?) functional languages also use structs; it's just a grouping of related data. Object-orientation is about grouping together functionality and data. I.e., an object consists of both a struct, and the functions that act on that struct, known as methods. In OO, your type additionally refers to the functions called on the data, not just on the data. E.g. you might have a car and a boat and they both only have a position and velocity as data, but the boat has a "sink" method the car doesn't. There are also debates on what qualifies as "true" object orientation. [link] For games programming in particular, there is a paradigm known as ECS or Entity Component System. (Depending on your view you might call this a sub-paradigm of object orientation, but I think it's much more accurately described as an alternative.) As the Wikipedia article states: > An entity only consists of an ID and a container of components. The idea is to have no game methods embedded in the entity. [link] EDIT: There's also the very interesting paradigm that e.g. Julia uses known as "Multiple Dispatch". This is kind of like defining methods on objects, except that the method is defined on a collection of objects instead of a single one. E.g., in traditional OO, you might have a vehicle#crash method. And it might take another vehicle as argument, e.g. car.crash(truck). But in multiple dispatch you define a function crash that takes in two
in “Grid – A Lua Game Engine” · View on HN
Yes, Julia makes some impressive stunts - supercomputing [0], ml where code is very close to mathematical description [1], code reuse [2] etc. [0] [link] [1] [link] [2] ▶ this video
in “Taking ML to production with Rust” · View on HN
The nice thing, is that as a julia programmer get to choose how 'fortran-like' things get. You often start off writing naïve dynamic code that is more like Python or Lisp, and then identify performance bottlenecks and optimize those. This prescription is familiar to Python programmers except the 'optimize this bottleneck' step involves leaving CPython and using Cython or Numba or whatever. In julia, you optimize your code by just writing slightly uglier julia code, not leaving the language. This has huge implications for 1) People 'looking under the hood'. Instead of having to read C as well as Julia, they only need to read Julia (albeit, more advanced, ugly technical julia code). This tends to greatly lower the bar for a julia user to become a julia developer and actively encourages learning more about the language. 2) Programs 'looking under the hood'. Code modification, injection and re-use is really common in julia and is part of what makes writing it so magical. Part of that is multiple dispatch code: ▶ this video but another major thing this enables is prevalent language wide automatic differentiation tools. Julia users tend to take it for granted at this point that they can take just about any function which takes in a number and spits out a number and then take a derivative of that code at compile time, no matter if that function was ever written with auto-diff in mind or if it ever knew about tools like Zygote or Forward diff. This sort of stuff would not be nearly as pow
in “Writing Performant Code in Julia” · View on HN
Hello Julia - and it's unreasonably effective multiple dispatch system. ▶ this video f(x1,x2){} < x1.f(x2){x1} < f(x1,x2){x1,x2} But modules are useful for organising code and choosing what to bother the compiler with.
in “Why do we need modules at all? (2011)” · View on HN