7 ms·

I’m waiting for interfaces in Julia 2.0… I’m impressed with all that they’ve done, but for finding new talent and dealing with such a strange tool and with mul

I’m waiting for interfaces in Julia 2.0… I’m impressed with all that they’ve done, but for finding new talent and dealing with such a strange tool and with multiple dispatch being such an awkward paradigm compared to traditional OOP, I still don’t think it’s worth the trouble yet. 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.

freemint 4y ago
Interfaces/Traits can be done with macros today.
mattkrause 4y ago
I did some dynamical systems stuff in Julia that absolutely blew Python and Matlab out of the water, both in terms of speed and ergonomics, so that's what baited the hook for me. Multiple dispatch is odd. It took me a while to get used to it, but it turns out to be pretty useful for a lot of math-y things where there are speed-ups for special cases (symmetric matrix, etc) or you need to wrangle data into a common structure first (one variance, list of variances, covariance matrix, etc).
ssivark 4y ago
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.

freemint 4y ago

Interfaces/Traits can be done with macros today.

mattkrause 4y ago

I did some dynamical systems stuff in Julia that absolutely blew Python and Matlab out of the water, both in terms of speed and ergonomics, so that's what baited the hook for me. Multiple dispatch is odd. It took me a while to get used to it, but it turns out to be pretty useful for a lot of math-y things where there are speed-ups for special cases (symmetric matrix, etc) or you need to wrangle data into a common structure first (one variance, list of variances, covariance matrix, etc).

ssivark 4y ago

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.