4 ms·

I don't claim that this technique is impossible in OOP; it's just not as natural without discriminated unions and match expressions.

gambler 7y ago
You're missing my point. In OOP every object is computation represented as data. It's not some kind of "unnatural" design pattern programmer should concoct in a special way. Erasing the distinction between data and procedures (or getting rid of both, if you look at it in another way) in one of the fundamental ideas that lead to creation of OOP in the first place. It sounds like Alan Kay was more interested in getting rid of data, but it does work both ways. Thus, saying "let me explain this to OOP developers" is highly ironic. If that's not clear, let's go back to your description: >Sometimes, you can improve your code by having it return a description of what to do Every object is (or at least should be) "a description of what to do" in the exact sense you're using here. This is crucial to understand for properly using OOP.
- kreetx 7y ago
  I think what the parent means is that even if you have data in your object, still the (OOP) language doesn't have discriminate unions nor match expressions. Also, if you call that method on the (OOP) object then "it still does the thing" - rather than returning a description of the thing. The author talks about a different (meta) way of programming where you create data types for all the actions the program should be able to do, then have your functions modify these descriptions, and, as the very last step interpret the description/run the program.
- sixbrx 7y ago
  I think that's a vision of OO that not many OO programs that I've seen actually follow. It's more common to see OO programs where object methods represent the computations, not the whole objects, while the bundled data is used to store resulting state of the computations, with much or all of the data hidden to preserve invariants for that state. Just acting directly on the data like that without an intermediate representation of the computation itself is just the sort of liberty that the video I mentioned in the sibling post, warns about that can turn into unwanted constraints in some cases.
  - gambler 7y ago
    >I think that's a vision of OO that not many OO programs that I've seen actually follow. Maybe not, but it absolutely was part of the original vision. This is why Smalltalk 80 implements if/else statements and loops as methods, rather than keywords. A boolean in smalltalk is not just a value. It's a latent algorithm for choosing between two blocks of code at some later point in time. It's also a latent algorithm for operating on other booleans via binary logic methods. Until you start seeing objects this way, you will not be able to appreciate the elegance of object-oriented programming. Here are some examples of how this can work in non-trivial scenarios: http://www.vpri.org/pdf/tr2007003_ometa.pdf http://www.vpri.org/pdf/tr2007003_ometa.pdf https://bracha.org/executableGrammars.pdf https://bracha.org/executableGrammars.pdf
- dfgdghdf 7y ago
  > Every object is (or at least should be) "a description of what to do" in the exact sense you're using here. This is crucial to understand for properly using OOP. I think you may have missed the point. In most OOP languages, an object exposes some capabilities (methods that can be called, properties that can be read, etc), but it does not describe itself very well at all. This is why we have RTTI, instanceof etc. to switch on what an object is. Alternatively, we can use the visitor pattern. As the OP states, these are not as elegant as DUs and matching.
- BoiledCabbage 7y ago
  The fact that almost every modern use of OOP consists of objects with numerous methods all with differing behavior essentially contradicts what you've stated. This concept is not OOP.

gambler 7y ago

You're missing my point. In OOP every object is computation represented as data. It's not some kind of "unnatural" design pattern programmer should concoct in a special way. Erasing the distinction between data and procedures (or getting rid of both, if you look at it in another way) in one of the fundamental ideas that lead to creation of OOP in the first place. It sounds like Alan Kay was more interested in getting rid of data, but it does work both ways. Thus, saying "let me explain this to OOP developers" is highly ironic. If that's not clear, let's go back to your description: >Sometimes, you can improve your code by having it return a description of what to do Every object is (or at least should be) "a description of what to do" in the exact sense you're using here. This is crucial to understand for properly using OOP.

kreetx 7y ago
I think what the parent means is that even if you have data in your object, still the (OOP) language doesn't have discriminate unions nor match expressions. Also, if you call that method on the (OOP) object then "it still does the thing" - rather than returning a description of the thing. The author talks about a different (meta) way of programming where you create data types for all the actions the program should be able to do, then have your functions modify these descriptions, and, as the very last step interpret the description/run the program.
sixbrx 7y ago
I think that's a vision of OO that not many OO programs that I've seen actually follow. It's more common to see OO programs where object methods represent the computations, not the whole objects, while the bundled data is used to store resulting state of the computations, with much or all of the data hidden to preserve invariants for that state. Just acting directly on the data like that without an intermediate representation of the computation itself is just the sort of liberty that the video I mentioned in the sibling post, warns about that can turn into unwanted constraints in some cases.
- gambler 7y ago
  >I think that's a vision of OO that not many OO programs that I've seen actually follow. Maybe not, but it absolutely was part of the original vision. This is why Smalltalk 80 implements if/else statements and loops as methods, rather than keywords. A boolean in smalltalk is not just a value. It's a latent algorithm for choosing between two blocks of code at some later point in time. It's also a latent algorithm for operating on other booleans via binary logic methods. Until you start seeing objects this way, you will not be able to appreciate the elegance of object-oriented programming. Here are some examples of how this can work in non-trivial scenarios: http://www.vpri.org/pdf/tr2007003_ometa.pdf http://www.vpri.org/pdf/tr2007003_ometa.pdf https://bracha.org/executableGrammars.pdf https://bracha.org/executableGrammars.pdf
dfgdghdf 7y ago
> Every object is (or at least should be) "a description of what to do" in the exact sense you're using here. This is crucial to understand for properly using OOP. I think you may have missed the point. In most OOP languages, an object exposes some capabilities (methods that can be called, properties that can be read, etc), but it does not describe itself very well at all. This is why we have RTTI, instanceof etc. to switch on what an object is. Alternatively, we can use the visitor pattern. As the OP states, these are not as elegant as DUs and matching.
BoiledCabbage 7y ago
The fact that almost every modern use of OOP consists of objects with numerous methods all with differing behavior essentially contradicts what you've stated. This concept is not OOP.