Hacker News Reader

Comment by kkdaemas | Hacker News Reader

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

View on HN

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.

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.

>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

https://bracha.org/executableGrammars.pdf

> 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.

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.

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.

Reply on news.ycombinator.com