4 ms·

IMHO multiple dispatch feels more awkward compared to OOP only because we’re far more used to the latter. And if that’s what you want to stick to, I guess you c

IMHO multiple dispatch feels more awkward compared to OOP only because we’re far more used to the latter. And if that’s what you want to stick to, I guess you could program in that style by making the “object” the first method argument, and wrapping the functions along with the struct definition in a module. > Additionally, everybody I’ve met thus far for interviews who knew Julia, also knew either Python or R, so it’s sort of a “why bother?” scenario. Well, if it isn’t substantially improving on a pain point that makes you really want to switch, then why bother? :-) Eg: For a problem I happened to be working on yesterday, I probably could have reduced ~1000 lines of Python code to ~100 lines of Julia code (all because of multiple dispatch… not just by calling some library) and cut through a lot of the not just tedious but also error-prone boilerplate (lots of little indexing details).

leephillips 4y ago
An odd take by the GP, as the usual version of OOP (I assume “traditional OOP” doesn’t mean Smalltalk, but the class-based horror used in Python or Java) is an awkwardly constrained, special case of multiple dispatch where we can only dispatch on the first argument.
- ssivark 4y ago
  I agree, but I can also understand that the familiarity of OOP patterns really helps “grease the wheels” for a lot of people. With something new (even if strictly superior in capability) they now need to re-think questions of architecture and code organization every time they sit down to write code. Personally, I found multiple dispatch (and Julia) to be a breath of fresh air because I never found classes/OOP too natural (for the kinds of problems I’m most interested in) and hated the amount of boilerplate & repetition. But if someone comes in with a different perspective, the radical modularity and code reuse can take some time to get used to :-)
- sundarurfriend 4y ago
  I was thinking about this recently, in the context of why it feels so weird to explain multiple dispatch. It's because it's the natural way to think about functions, once you unlearn the "awkwardly constrained , special case" as you put it. So it starts to feel obvious, a way of doing things that would need no explanation. It's just that unlearning things like this is a hard process that not a lot of people have experience with, especially compared with learning things in a purely additive sense.
- igouy 4y ago
  > … doesn’t mean Smalltalk, but the class-based horror used in Python or Java… If you're suggesting Smalltalk is not class-based then what do you mean by "class-based" ?
  - leephillips 4y ago
    I was trying, clumsily, to bring to mind the differences between Smalltalk’s object/message model and the class/method model of Python, etc.
    - igouy 4y ago
      In the first case, program + program changes; in the second case, program definitions. Smalltalk language implementations provide a prototype program and we make our software by making changes to that prototype — by sending messages to instantiated objects — not by writing definitions.
sidpatil 4y ago
> And if that’s what you want to stick to, I guess you could program in that style by making the “object” the first method argument, and wrapping the functions along with the struct definition in a module. You might not even need to do that. This package was released recently, implementing OOP: https://github.com/Suzhou-Tongyuan/ObjectOriented.jl https://github.com/Suzhou-Tongyuan/ObjectOriented.jl
Buttons840 4y ago
OOP is nice to stumble through because what's possible for a given object is spelled out. Your IDE can suggest a list of possible methods and you pick the one that sounds good. Whereas in Julia there's an infinite number of potential functions that can operate on the value you have, and I haven't seen a good way to list them.
- ssivark 4y ago
  Fair point. I wonder whether this is a good reason to rethink the UI of autocomplete. 1. Instead of operating sequentially as you type, maybe one could type out the variable(s) one wants to use, select them and then have the ask the language analyzer to suggest functions? 2. Another change (possibly more effective) is to stop thinking in terms of data (and completing with functions) and instead start thinking in terms of functions (and completing with data). Just thinking out loud what might be a different thought process… The language (and types/classes) are not there to constrain you; write down the code/functionality you would like, and then find/construct the types you need to have that code be true :-?
  - leephillips 4y ago
    Your #2 makes much more sense to me than your #1 or the GP’s comment. Suppose my data or variable is a floating-point number. How does it help me to have my editor listing the thousands of functions that can operate on a float? Say what you want to do by writing the verb (function) that does what you want, then give it the arguments that you want it to act upon.
  - sundarurfriend 4y ago
    > rethink the UI of autocomplete ... maybe one could type out the variable(s) one wants to use, select them and then have the ask the language analyzer to suggest functions? This wasn't mentioned in this blog post, but the NEWS.md with a more complete changelog mentions a new feature in the REPL > ?(x, y followed by TAB displays all methods that can be called with arguments x, y, .... (The space at the beginning prevents entering help-mode.) MyModule.?(x, y limits the search to MyModule. There's long been discussion of this kind of redesigned autocomplete UI that's suitable for this paradigm, in the Julia community. I really like this solution that they ultimately went with.

leephillips 4y ago

An odd take by the GP, as the usual version of OOP (I assume “traditional OOP” doesn’t mean Smalltalk, but the class-based horror used in Python or Java) is an awkwardly constrained, special case of multiple dispatch where we can only dispatch on the first argument.

ssivark 4y ago
I agree, but I can also understand that the familiarity of OOP patterns really helps “grease the wheels” for a lot of people. With something new (even if strictly superior in capability) they now need to re-think questions of architecture and code organization every time they sit down to write code. Personally, I found multiple dispatch (and Julia) to be a breath of fresh air because I never found classes/OOP too natural (for the kinds of problems I’m most interested in) and hated the amount of boilerplate & repetition. But if someone comes in with a different perspective, the radical modularity and code reuse can take some time to get used to :-)
sundarurfriend 4y ago
I was thinking about this recently, in the context of why it feels so weird to explain multiple dispatch. It's because it's the natural way to think about functions, once you unlearn the "awkwardly constrained , special case" as you put it. So it starts to feel obvious, a way of doing things that would need no explanation. It's just that unlearning things like this is a hard process that not a lot of people have experience with, especially compared with learning things in a purely additive sense.
igouy 4y ago
> … doesn’t mean Smalltalk, but the class-based horror used in Python or Java… If you're suggesting Smalltalk is not class-based then what do you mean by "class-based" ?
- leephillips 4y ago
  I was trying, clumsily, to bring to mind the differences between Smalltalk’s object/message model and the class/method model of Python, etc.
  - igouy 4y ago
    In the first case, program + program changes; in the second case, program definitions. Smalltalk language implementations provide a prototype program and we make our software by making changes to that prototype — by sending messages to instantiated objects — not by writing definitions.

sidpatil 4y ago

> And if that’s what you want to stick to, I guess you could program in that style by making the “object” the first method argument, and wrapping the functions along with the struct definition in a module. You might not even need to do that. This package was released recently, implementing OOP: https://github.com/Suzhou-Tongyuan/ObjectOriented.jl https://github.com/Suzhou-Tongyuan/ObjectOriented.jl

Buttons840 4y ago

OOP is nice to stumble through because what's possible for a given object is spelled out. Your IDE can suggest a list of possible methods and you pick the one that sounds good. Whereas in Julia there's an infinite number of potential functions that can operate on the value you have, and I haven't seen a good way to list them.

ssivark 4y ago
Fair point. I wonder whether this is a good reason to rethink the UI of autocomplete. 1. Instead of operating sequentially as you type, maybe one could type out the variable(s) one wants to use, select them and then have the ask the language analyzer to suggest functions? 2. Another change (possibly more effective) is to stop thinking in terms of data (and completing with functions) and instead start thinking in terms of functions (and completing with data). Just thinking out loud what might be a different thought process… The language (and types/classes) are not there to constrain you; write down the code/functionality you would like, and then find/construct the types you need to have that code be true :-?
- leephillips 4y ago
  Your #2 makes much more sense to me than your #1 or the GP’s comment. Suppose my data or variable is a floating-point number. How does it help me to have my editor listing the thousands of functions that can operate on a float? Say what you want to do by writing the verb (function) that does what you want, then give it the arguments that you want it to act upon.
- sundarurfriend 4y ago
  > rethink the UI of autocomplete ... maybe one could type out the variable(s) one wants to use, select them and then have the ask the language analyzer to suggest functions? This wasn't mentioned in this blog post, but the NEWS.md with a more complete changelog mentions a new feature in the REPL > ?(x, y followed by TAB displays all methods that can be called with arguments x, y, .... (The space at the beginning prevents entering help-mode.) MyModule.?(x, y limits the search to MyModule. There's long been discussion of this kind of redesigned autocomplete UI that's suitable for this paradigm, in the Julia community. I really like this solution that they ultimately went with.