3 ms·

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

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.

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.