4 ms·

"double dispatch" is not a problem. It's OO epicycles. "Deciding what to do based on the sort of input" is the problem. The point of these realizations not tha

"double dispatch" is not a problem. It's OO epicycles. "Deciding what to do based on the sort of input" is the problem. The point of these realizations not that "oh, just use church encoding". Church encoding, like the visor pattern, is annoying an obtuse: get a language with pattern marching. Rather, the point is to show that the theory is legit because it shows up even among the work of those ignorant of it. And church encoding remains useful theory because sometimes it's advantageous to boil everything down to functions.

skybrian 6y ago
That is changing the problem definition, which may or may not be a feasible move. "Double dispatch" is indeed a problem when the language you're allowed to use has to be taken as given, as it usually is.
- Gabriel439 6y ago
  Author here: it's not changing the problem definition. I can confirm that the original motivation for writing the post was to show the theoretical underpinnings of the visitor pattern, not to encourage people to gratuitously use double dispatch.
- dragonwriter 6y ago
  > "Double dispatch" is indeed a problem when the language you're allowed to use has to be taken as given. No, it's not, at least with most modern real OO languages, because most support functional style as well. It's the low impedance solution course for certain problems when you have a preexisting idiomatic code base in some languages, though. But that's a different thing than being the problem. (Also, whether the language is usually an advance constraint rather than a trade-off depends on a lot of things, including your role; certainly, polyglot runtimes and the ability to link code from different languages are common enough that even “must integrate in-process with existing code base in language X” is usually not a technical constraint that narrows the solution space to language X.)
  - skybrian 6y ago
    We should distinguish between "double dispatch" in the abstract and a concrete problem being solved with it. The concrete problem often has more constraints, not mentioned when talking about it abstractly. For example, using a different language means that the build system needs to support the other language, which can significantly complicate the difficulty for users of a library compared to a "pure" version written in the same language as the rest of the ecosystem. It may also limit portability, if the original language and the other language you pick don't support the same platforms. This isn't a good thing to inflict on users of your library. To be a bit more concrete about it, suppose you are writing code in Rust to target WebAssembly. Pure Rust libraries are more likely to work than those written in a different language. There are other ways to avoid this. In Go, you can use the "go generate" command to generate Go code from code written in another language, and check in the Go code, so downstream users of your library don't need any special tools. That's probably okay for private dependency on code written in another language, but less useful for datatypes used in public API's. Someone talking about OO "epicycles" is ignoring most of the constraints that library maintainers face. It seems unsympathetic and out of touch.
    - Ericson2314 6y ago
      It's fine to justify how we write code based on the code we've already written, but that is the very "hammer-first" reasoning the original comment was disparaging! Even if we can't rewrite everything up front, it's used to think about the problem at hand from first principles, ignoring the constraints of any particular language. From the vantage point "double dispatch" will never arise.
      - skybrian 6y ago
        If this Church-encoding workaround were useful, there would need to be at least one concrete situation where you find it useful. It's apparently not useful in languages with sum types, and it doesn't seem useful in an object-oriented language either (where you'd use the normal visitor pattern). So, when is it useful? The author doesn't have a practical example. I guess there might be a language somewhere that has neither sum types nor methods? It's kind of a reach. But, maybe it's useful educationally, as a good way to think about problems? That doesn't seem particularly likely either, considering that you can apply the visitor pattern just fine without knowing about Church encodings at all. Disparaging "double dispatch" as "epicycles" while promoting Church encoding as "legit" just seems out of touch with how practical programmers think. I can't think of any reason why I'd want to use Church encoding to explain what's going on to a newbie. Maybe there is some other situation where it's useful, but it's not explained.
jameshart 6y ago
Maybe the fundamental problem isn’t double dispatch itself, fair. The fundamental problem is that you need to teach the computer how to choose which of a number of computations to run depending on two enumerable dimensions, and you need to embed that into your program in a way that covers all the possibilities, is bug free and maintainable. Like, I need to be able to add shapes to my program, and things I can calculate about shapes to my program, and whenever I do so I need to either add all the new calculations for my new shape, or add my calculation for every existing shape. That’s the essential complexity at the heart of this problem. Double dispatch is the problem you then get when, in looking to solve that problem, you want to express the operations you want to run as functions that take every pairwise combination of types, and you are at a point in your code where you have a couple of objects and need to choose which of those functions to run. Like, I have an operation I want to run (could be calculate area, could be calculate perimeter), and a shape I want to run it on (could be a square, could be a circle) and I need the computer to go and run the correct one of four possible bits of code for me right now. This is a double dispatch problem no matter what facilities your language has to address it. If your language can pattern match on typed tuples you can use pattern matching to dispatch to the right piece of code. If not, maybe you need to use something like the visitor pattern.
- Ericson2314 6y ago
  > Like, I need to be able to add shapes to my program, and things I can calculate about shapes to my program, and whenever I do so I need to either add all the new calculations for my new shape, or add my calculation for every existing shape. > That’s the essential complexity at the heart of this problem. Agreed > This is a double dispatch problem no matter what facilities your language has to address it. If your language can pattern match on typed tuples you can use pattern matching to dispatch to the right piece of code. If not, maybe you need to use something like the visitor pattern. But the "double" part refers to the OO solution to that. With pattern matching, there is nothing that sicks out as "double". Pattern matching on two arguments is the same as pattern matching on a single pair. A solution-neutral term might be https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem

skybrian 6y ago

That is changing the problem definition, which may or may not be a feasible move. "Double dispatch" is indeed a problem when the language you're allowed to use has to be taken as given, as it usually is.

Gabriel439 6y ago
Author here: it's not changing the problem definition. I can confirm that the original motivation for writing the post was to show the theoretical underpinnings of the visitor pattern, not to encourage people to gratuitously use double dispatch.
dragonwriter 6y ago
> "Double dispatch" is indeed a problem when the language you're allowed to use has to be taken as given. No, it's not, at least with most modern real OO languages, because most support functional style as well. It's the low impedance solution course for certain problems when you have a preexisting idiomatic code base in some languages, though. But that's a different thing than being the problem. (Also, whether the language is usually an advance constraint rather than a trade-off depends on a lot of things, including your role; certainly, polyglot runtimes and the ability to link code from different languages are common enough that even “must integrate in-process with existing code base in language X” is usually not a technical constraint that narrows the solution space to language X.)
- skybrian 6y ago
  We should distinguish between "double dispatch" in the abstract and a concrete problem being solved with it. The concrete problem often has more constraints, not mentioned when talking about it abstractly. For example, using a different language means that the build system needs to support the other language, which can significantly complicate the difficulty for users of a library compared to a "pure" version written in the same language as the rest of the ecosystem. It may also limit portability, if the original language and the other language you pick don't support the same platforms. This isn't a good thing to inflict on users of your library. To be a bit more concrete about it, suppose you are writing code in Rust to target WebAssembly. Pure Rust libraries are more likely to work than those written in a different language. There are other ways to avoid this. In Go, you can use the "go generate" command to generate Go code from code written in another language, and check in the Go code, so downstream users of your library don't need any special tools. That's probably okay for private dependency on code written in another language, but less useful for datatypes used in public API's. Someone talking about OO "epicycles" is ignoring most of the constraints that library maintainers face. It seems unsympathetic and out of touch.
  - Ericson2314 6y ago
    It's fine to justify how we write code based on the code we've already written, but that is the very "hammer-first" reasoning the original comment was disparaging! Even if we can't rewrite everything up front, it's used to think about the problem at hand from first principles, ignoring the constraints of any particular language. From the vantage point "double dispatch" will never arise.
    - skybrian 6y ago
      If this Church-encoding workaround were useful, there would need to be at least one concrete situation where you find it useful. It's apparently not useful in languages with sum types, and it doesn't seem useful in an object-oriented language either (where you'd use the normal visitor pattern). So, when is it useful? The author doesn't have a practical example. I guess there might be a language somewhere that has neither sum types nor methods? It's kind of a reach. But, maybe it's useful educationally, as a good way to think about problems? That doesn't seem particularly likely either, considering that you can apply the visitor pattern just fine without knowing about Church encodings at all. Disparaging "double dispatch" as "epicycles" while promoting Church encoding as "legit" just seems out of touch with how practical programmers think. I can't think of any reason why I'd want to use Church encoding to explain what's going on to a newbie. Maybe there is some other situation where it's useful, but it's not explained.

jameshart 6y ago

Maybe the fundamental problem isn’t double dispatch itself, fair. The fundamental problem is that you need to teach the computer how to choose which of a number of computations to run depending on two enumerable dimensions, and you need to embed that into your program in a way that covers all the possibilities, is bug free and maintainable. Like, I need to be able to add shapes to my program, and things I can calculate about shapes to my program, and whenever I do so I need to either add all the new calculations for my new shape, or add my calculation for every existing shape. That’s the essential complexity at the heart of this problem. Double dispatch is the problem you then get when, in looking to solve that problem, you want to express the operations you want to run as functions that take every pairwise combination of types, and you are at a point in your code where you have a couple of objects and need to choose which of those functions to run. Like, I have an operation I want to run (could be calculate area, could be calculate perimeter), and a shape I want to run it on (could be a square, could be a circle) and I need the computer to go and run the correct one of four possible bits of code for me right now. This is a double dispatch problem no matter what facilities your language has to address it. If your language can pattern match on typed tuples you can use pattern matching to dispatch to the right piece of code. If not, maybe you need to use something like the visitor pattern.

Ericson2314 6y ago
> Like, I need to be able to add shapes to my program, and things I can calculate about shapes to my program, and whenever I do so I need to either add all the new calculations for my new shape, or add my calculation for every existing shape. > That’s the essential complexity at the heart of this problem. Agreed > This is a double dispatch problem no matter what facilities your language has to address it. If your language can pattern match on typed tuples you can use pattern matching to dispatch to the right piece of code. If not, maybe you need to use something like the visitor pattern. But the "double" part refers to the OO solution to that. With pattern matching, there is nothing that sicks out as "double". Pattern matching on two arguments is the same as pattern matching on a single pair. A solution-neutral term might be https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem