3 ms·

Curious bystander here. Is there a cult follower on HN who can speak to the benefits of multiple dispatch, practically and compared to other languages? I know t

by klabb3 4y ago

Curious bystander here. Is there a cult follower on HN who can speak to the benefits of multiple dispatch, practically and compared to other languages? I know the sales pitch but I’m curious in particular about which practical coding problems and abstractions become obsolete with MD. It looks really promising, like “the way things were always supposed to be”, but I haven’t yet developed a full and intuitive understanding of what it means.

cmcaine 4y ago
I like it a lot even though almost all of my functions have no dispatch (only one implementation) or single dispatch (implementation differs based on the type of just one of the arguments). Firstly I like the aesthetic and implications of f(x, y, z) over x.f(y, z). I like that f is its own thing and not a property of x. Secondly, it's really nice to be able to reach however far down the callstack you need to go to patch some function "owned" by someone else to act correctly or more efficiently with whatever your type is. You can get correct code most of the time with single dispatch and well-thought-out interfaces, but getting interfaces right in advance is really tricky and requires coordination with other users of the interface whereas multiple dispatch can often work well without much coordination and can also handle cases where you want the implementation to vary dramatically based on the type (the OneHotVector in Karpinski's "Unreasonable effectiveness of multiple dispatch" talk is an example of this).
Polygator 4y ago
Have you seen the Unreasonable Effectiveness of Multiple Dispatch talk on YouTube? It's pretty good if you have the time
- klabb3 4y ago
  Yes, but I should probably watch it again. Unfortunately it seems most people come from a mathematical angle, so most examples and references are not intuitive to grok for me. I am mostly curious about the implications for general purpose software development.
socialdemocrat 4y ago
For me it solved many reoccurring problems. One issue that popping up for me was the need for a clunky visitor pattern. Say you do collision detection between multiple shapes of different type, or you want to transform a serialized representation of a GUI into GUI elements. In my mind it also removes a lot of cases where I need major restructuring and and refactoring in typical OOP languages. Getting type hierarchies and code organization wrong is so much easier with OOP and much harder to de-tangle. Not always easy to explain with examples. Once you used MD for a while and try SD again you really start noticing how clunky SD makes code writing.
GlenTheMachine 4y ago
Wrote a fairly complex optimization-based translational trajectory generator for a robot arm. Needed orientation as well. Implemented a simple quaternion type, implemented multiplication and addition for it, and fed it to the translational code. Worked off the bat. If I wanted to use eg Euler angles or modified Rodriguez vectors or some other representation of rotation, the identical code pattern would work.
- gpderetta 4y ago
  But why do you need multiple dispatch? why do you need dynamic dispatch at all in fact? Any language with semi-decent support for generic programming (via traits, type classes, overloading, what have you) should be able to do the above.
  - borodi 4y ago
    That's one of the cool things about Julia. If it can prove the types of the arguments to a function, or at least reduce them to a small set. It can do the dispatch at compile time. Well, Julia has better than semi decent support for generics, since every function is by definition a generic.
    - gpderetta 4y ago
      That's an advantage versus other dynamic languages without multiple dispatch, but statically typed languages do not have this issue in the first place. The only other dynamic language used for numerical stuff is Python, but its issues go well beyond lack of MD. MD can be useful for static languages of course, but it comes up significantly less often and static MD is simply overloading/ad-hoc polymorphism.
adgjlsfhk1 4y ago
The problems it solves depend a bit on where you're coming from. If you're coming from a CBOO (class based object oriented e.g. Java/C#), the biggest notable thing is that a lot of the Gang of 4 design patterns go away and are replaced with "call/pass a function". If you're coming from a functional language, the main difference is that Julia will compile specialized versions of functions for your types, and makes it a lot easier to write runtime efficient and generic code. For a simple example of this in action, consider the following julia> a = 1//3 # a is the rational number 1/3 1//3 julia> b = 2+3im # b is a gausian integer (complex number with integer coefficients) 2 + 3im julia> a+b # even though these types don't know about each other, appropriate methods get called to get a complex rational result. 7//3 + 3//1*im This might seem really basic, but you'll be hard pressed to make a system like this in another language without hard coding a list of dispatches manually.
- anigbrowl 4y ago
  Sympy is pretty capable but not as beautiful. The first time I tried doing math in Julia was a pleasurable shock.
singularity2001 4y ago
To me julia is the perfect mathematical toy language with great fundamentals and prospects of becoming a serious language once the compile time issues are fixed. It does so many things very right and always from first principles, not ad hoc (ad hacks). some random examples that I love sum(xs...) = reduce(+, xs) julia > (6ft + 1km) * 1km/s 1002 m s⁻¹ julia> 'a' in "abc" true 180° + π == 2π map(x -> 2x, [2,4,6,8]) == [2,4,6,8].*2 julia> ⊕(x, y) = x+y julia> 1⊕2 3 ∑(xs...)=fold(xs,+) julia> ∑(2,4,6,8) 20 ∑(xs)=fold(xs,+) julia> ∑([2 4 6 8]) 20
dandanua 4y ago
With multiple dispatch you can extend the types of your data and functions that process it independently of each other. For example, some people can extend floats to intervals (to keep track of precision) and some other people can write any code that operates on abstract floats. They don't have to communicate and agree on things and conventions, the composite code just works.

by klabb3 4y ago

cmcaine 4y ago

I like it a lot even though almost all of my functions have no dispatch (only one implementation) or single dispatch (implementation differs based on the type of just one of the arguments). Firstly I like the aesthetic and implications of f(x, y, z) over x.f(y, z). I like that f is its own thing and not a property of x. Secondly, it's really nice to be able to reach however far down the callstack you need to go to patch some function "owned" by someone else to act correctly or more efficiently with whatever your type is. You can get correct code most of the time with single dispatch and well-thought-out interfaces, but getting interfaces right in advance is really tricky and requires coordination with other users of the interface whereas multiple dispatch can often work well without much coordination and can also handle cases where you want the implementation to vary dramatically based on the type (the OneHotVector in Karpinski's "Unreasonable effectiveness of multiple dispatch" talk is an example of this).

Polygator 4y ago

Have you seen the Unreasonable Effectiveness of Multiple Dispatch talk on YouTube? It's pretty good if you have the time

klabb3 4y ago
Yes, but I should probably watch it again. Unfortunately it seems most people come from a mathematical angle, so most examples and references are not intuitive to grok for me. I am mostly curious about the implications for general purpose software development.

socialdemocrat 4y ago

For me it solved many reoccurring problems. One issue that popping up for me was the need for a clunky visitor pattern. Say you do collision detection between multiple shapes of different type, or you want to transform a serialized representation of a GUI into GUI elements. In my mind it also removes a lot of cases where I need major restructuring and and refactoring in typical OOP languages. Getting type hierarchies and code organization wrong is so much easier with OOP and much harder to de-tangle. Not always easy to explain with examples. Once you used MD for a while and try SD again you really start noticing how clunky SD makes code writing.

GlenTheMachine 4y ago

Wrote a fairly complex optimization-based translational trajectory generator for a robot arm. Needed orientation as well. Implemented a simple quaternion type, implemented multiplication and addition for it, and fed it to the translational code. Worked off the bat. If I wanted to use eg Euler angles or modified Rodriguez vectors or some other representation of rotation, the identical code pattern would work.

gpderetta 4y ago
But why do you need multiple dispatch? why do you need dynamic dispatch at all in fact? Any language with semi-decent support for generic programming (via traits, type classes, overloading, what have you) should be able to do the above.
- borodi 4y ago
  That's one of the cool things about Julia. If it can prove the types of the arguments to a function, or at least reduce them to a small set. It can do the dispatch at compile time. Well, Julia has better than semi decent support for generics, since every function is by definition a generic.
  - gpderetta 4y ago
    That's an advantage versus other dynamic languages without multiple dispatch, but statically typed languages do not have this issue in the first place. The only other dynamic language used for numerical stuff is Python, but its issues go well beyond lack of MD. MD can be useful for static languages of course, but it comes up significantly less often and static MD is simply overloading/ad-hoc polymorphism.

adgjlsfhk1 4y ago

The problems it solves depend a bit on where you're coming from. If you're coming from a CBOO (class based object oriented e.g. Java/C#), the biggest notable thing is that a lot of the Gang of 4 design patterns go away and are replaced with "call/pass a function". If you're coming from a functional language, the main difference is that Julia will compile specialized versions of functions for your types, and makes it a lot easier to write runtime efficient and generic code. For a simple example of this in action, consider the following julia> a = 1//3 # a is the rational number 1/3 1//3 julia> b = 2+3im # b is a gausian integer (complex number with integer coefficients) 2 + 3im julia> a+b # even though these types don't know about each other, appropriate methods get called to get a complex rational result. 7//3 + 3//1*im This might seem really basic, but you'll be hard pressed to make a system like this in another language without hard coding a list of dispatches manually.

anigbrowl 4y ago
Sympy is pretty capable but not as beautiful. The first time I tried doing math in Julia was a pleasurable shock.

singularity2001 4y ago

To me julia is the perfect mathematical toy language with great fundamentals and prospects of becoming a serious language once the compile time issues are fixed. It does so many things very right and always from first principles, not ad hoc (ad hacks). some random examples that I love sum(xs...) = reduce(+, xs) julia > (6ft + 1km) * 1km/s 1002 m s⁻¹ julia> 'a' in "abc" true 180° + π == 2π map(x -> 2x, [2,4,6,8]) == [2,4,6,8].*2 julia> ⊕(x, y) = x+y julia> 1⊕2 3 ∑(xs...)=fold(xs,+) julia> ∑(2,4,6,8) 20 ∑(xs)=fold(xs,+) julia> ∑([2 4 6 8]) 20

dandanua 4y ago

With multiple dispatch you can extend the types of your data and functions that process it independently of each other. For example, some people can extend floats to intervals (to keep track of precision) and some other people can write any code that operates on abstract floats. They don't have to communicate and agree on things and conventions, the composite code just works.