Hacker News Reader

Comment by Buttons840 | Hacker News Reader

In Julia you can `@which naked_function`. That might help.

With Julia's function overloading a function might come from multiple packages.

Even though you can do `@which naked_function` it's a fair position to have that you prefer to import modules and be explicit about where they come from. I tend to prefer explicitness like that in package code, but for data analytical scripts (like the examples here) it would be superfluous in my opinion.

It is nice that Julia leaves this style decision to the user. I personally find the constant prepending of modules to be one of the clumsiest aspects of Python for data analysis.

Or rather, a function from one package can be extended with methods by other packages.

And to add:

Which of the many method of that function is called depends on the type of all the arguments (not only the first argument, as in single dispatch languages like C++). In other words, the implementation actually executed (and thus the source package) might vary depending on the argument type. If I understand Julia correctly.

I still don't get why multiple dispatch was chosen over having seperate functions with typed arguments. It just seems to add complexity with limited benefit.

This video is my best attempt to explain it (not a rickroll, I swear): https://youtu.be/kc9HwsxE1OY

Nice talk, you're a really good speaker. Thanks.

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:

https://www.youtube.com/watch?v=kc9HwsxE1OY

Reply on news.ycombinator.com