3 ms·

IIUC, this article highlights the importance of dynamic dispatch, but implicitly restricts itself to single dispatch (OOP) completely eliding any mention of mul

IIUC, this article highlights the importance of dynamic dispatch, but implicitly restricts itself to single dispatch (OOP) completely eliding any mention of multiple dispatch. Single dispatch is great/sufficient for modeling process encapsulated by a “single agent” but multiple dispatch feels far more elegant to encode interactions between multiple agents. Eg: Neither a.sum(b) nor b.sum(a) is as cleanly extensible as sum(a,b)

agumonkey 5y ago
any resource on multiple dispatch design ? i'm doing some common lisp and I have to admit I'm walking in the fog a bit
- Verdex 5y ago
  IIRC Practical Common Lisp does a pretty good job with it. https://www.amazon.com/Practical-Common-Lisp-Peter-Seibel/dp/1590592395 https://www.amazon.com/Practical-Common-Lisp-Peter-Seibel/dp...
- oscardssmith 5y ago
  If you are interested in multiple dispatch, you really should check out Julia. In my opinion, the biggest reason Julia has been as successful as it has is that everything uses multiple dispatch, and the system for it is simple enough that you might not notice.
  - agumonkey 5y ago
    forgot julia used it, thanks
kazinator 5y ago
Bringing in special True Scotsman OOP systems into the paper would distract from its point. It would be confusing: is the paper saying that OOP is inevitable as it is, in the common state, or do we need to progress toward True Scotsman's OOP and then OOP will be completely unbeatable? If regular old OOP beats everything, then True Scotsman OOP is just a footnote; oh, by the way, not only has single dispatch OOP eaten the world, but there are even better forms of OOP, which will lick the plate clean and ask for seconds. (But regular old OOP has been so successful that we have not had to massively adopt these.) Now let's look at your sum(a, b). The paper talks specifically about service abstractions, and how OOP has specifically helped us manage them. sum(a, b) is not a service abstraction. It's a functional abstraction! We add a and b, which could be many combinations of types (and so we need dispatch). But at the end, we will be returning a new object c, leaving a and b alone. While multiple dispatch is all well and good, the paper's argument is, via anecdotes and hand-waving, that regular old OOP that your pointy-haired-boss is familiar with has been successful because it represents service abstractions well, in which services can be extended while remaining compatible. Services is a code word for objects that change their state in response to requests. A.k.a. receive messages, change state and send replies. Speaking of actual services, multiple dispatch has a poor story in distributed systems. It's difficult to send a message to three different objects in different geographical locations and get that to look like a single method. When you have components from different vendors, multiple dispatch has gone out the window. Multiple dispatch requires classes to be completely open so that methods can peek into the innards of several classes. How will that work with server RPC API's from different vendors, COM objects from different vendors, you name it. Multiple dispatch works well in large part because, at the bottom, a concrete piece of code gets dispatched, which has access to all the arguments and can do the work in one place, all within the same address space of one dynamic language image. Single dispatch scales beyond process and machine boundaries. If you stick to a single dispatch design in the straw man prototype of a system, you will not have to redesign that basic aspect of the system to go to the wooden man that works across a network. Like oh shit, objects A and B of this double dispatch method are actually RPC proxies that live on different servers; now what?
- oscardssmith 5y ago
  The problem with oop is that there are some problems that come up a lot (type promotion for example) where there just is no good solution. You can write a program in Julia that defines 4 different types of numbers and adds them all together in about 30 lines of code (and which is extendable to adding more number types). That just doesn't work in any oop language. You would have to choose the number types you're supporting ahead of time, and would have to write literally exponentially more code to make it work.
  - kazinator 5y ago
    I understand; but, to reiterate, that is not a mainstream problem involving modeling a service. And, by the way, that specific example is doable (somewhat) in languages with static dispatch on multiple arguments, like C++'s function overloading. We're just stuck with a statically determined result type; C++ won't statically model something like that an division of two Integer classes yields an Integer, otherwise a Ratio. If we don't need that, we are good to go: // no OOP dispatch to see here quaternion mul(const quaternion &left, double right); quaternion mul(double left, const quaternion &right); Static polymorphism may be good enough for a good many use cases, and runs fast too due to all dispatch being resolved at compile time. Multiple dispatch will not save you from the fact that if you have N different kinds of numbers, you may have to code all N*N combinations of some operations that don't commute, or N(N+1)/2 for those that do. It will give you a minimal-boilerplate way to write that though, with accurate modeling of situations where the result type depends on properties of run-time value.

agumonkey 5y ago

any resource on multiple dispatch design ? i'm doing some common lisp and I have to admit I'm walking in the fog a bit

Verdex 5y ago
IIRC Practical Common Lisp does a pretty good job with it. https://www.amazon.com/Practical-Common-Lisp-Peter-Seibel/dp/1590592395 https://www.amazon.com/Practical-Common-Lisp-Peter-Seibel/dp...
oscardssmith 5y ago
If you are interested in multiple dispatch, you really should check out Julia. In my opinion, the biggest reason Julia has been as successful as it has is that everything uses multiple dispatch, and the system for it is simple enough that you might not notice.
- agumonkey 5y ago
  forgot julia used it, thanks

kazinator 5y ago

Bringing in special True Scotsman OOP systems into the paper would distract from its point. It would be confusing: is the paper saying that OOP is inevitable as it is, in the common state, or do we need to progress toward True Scotsman's OOP and then OOP will be completely unbeatable? If regular old OOP beats everything, then True Scotsman OOP is just a footnote; oh, by the way, not only has single dispatch OOP eaten the world, but there are even better forms of OOP, which will lick the plate clean and ask for seconds. (But regular old OOP has been so successful that we have not had to massively adopt these.) Now let's look at your sum(a, b). The paper talks specifically about service abstractions, and how OOP has specifically helped us manage them. sum(a, b) is not a service abstraction. It's a functional abstraction! We add a and b, which could be many combinations of types (and so we need dispatch). But at the end, we will be returning a new object c, leaving a and b alone. While multiple dispatch is all well and good, the paper's argument is, via anecdotes and hand-waving, that regular old OOP that your pointy-haired-boss is familiar with has been successful because it represents service abstractions well, in which services can be extended while remaining compatible. Services is a code word for objects that change their state in response to requests. A.k.a. receive messages, change state and send replies. Speaking of actual services, multiple dispatch has a poor story in distributed systems. It's difficult to send a message to three different objects in different geographical locations and get that to look like a single method. When you have components from different vendors, multiple dispatch has gone out the window. Multiple dispatch requires classes to be completely open so that methods can peek into the innards of several classes. How will that work with server RPC API's from different vendors, COM objects from different vendors, you name it. Multiple dispatch works well in large part because, at the bottom, a concrete piece of code gets dispatched, which has access to all the arguments and can do the work in one place, all within the same address space of one dynamic language image. Single dispatch scales beyond process and machine boundaries. If you stick to a single dispatch design in the straw man prototype of a system, you will not have to redesign that basic aspect of the system to go to the wooden man that works across a network. Like oh shit, objects A and B of this double dispatch method are actually RPC proxies that live on different servers; now what?

oscardssmith 5y ago
The problem with oop is that there are some problems that come up a lot (type promotion for example) where there just is no good solution. You can write a program in Julia that defines 4 different types of numbers and adds them all together in about 30 lines of code (and which is extendable to adding more number types). That just doesn't work in any oop language. You would have to choose the number types you're supporting ahead of time, and would have to write literally exponentially more code to make it work.
- kazinator 5y ago
  I understand; but, to reiterate, that is not a mainstream problem involving modeling a service. And, by the way, that specific example is doable (somewhat) in languages with static dispatch on multiple arguments, like C++'s function overloading. We're just stuck with a statically determined result type; C++ won't statically model something like that an division of two Integer classes yields an Integer, otherwise a Ratio. If we don't need that, we are good to go: // no OOP dispatch to see here quaternion mul(const quaternion &left, double right); quaternion mul(double left, const quaternion &right); Static polymorphism may be good enough for a good many use cases, and runs fast too due to all dispatch being resolved at compile time. Multiple dispatch will not save you from the fact that if you have N different kinds of numbers, you may have to code all N*N combinations of some operations that don't commute, or N(N+1)/2 for those that do. It will give you a minimal-boilerplate way to write that though, with accurate modeling of situations where the result type depends on properties of run-time value.