Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Breaking up a problem recursively into stateful components is completely orthogonal to OOP.

As is coupling state and function. Parent's comment is a good demonstration of the inertia of misinformed adherence to OOP.

Since you seem confident that your understanding of OOP is better than that of "misinformed" people like me who don't think that coupling state and function is completely orthoganal OOP, can you explain what isn't completely orthoganal?

A succinct definition of OOP would be nice to combat the misinformation you're complaining about.

The description of OOP provided in the Wikipedia article on programming paradigms [1] matches my current understanding of OOP.

> object-oriented which groups code together with the state the code modifies,

Maybe that's a little too succinct, because I think it's also worth noting how [2]

> In OOP, computer programs are designed by making them out of objects that interact with one another.

I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either.

I guess this might demonstrate the inertia of the so-called misinformation, but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed.

[1] https://en.m.wikipedia.org/wiki/Programming_paradigm

[2] https://en.m.wikipedia.org/wiki/Object-oriented_programming

The fundamental ideas of OOP are pervasive data privacy and the consequent synchronization via message passing. Now, many OO languages have badly butchered that, but that is the idea, as in Smalltalk: Objects are opaque participants in a colloquy.

I'm not sure where you got "the majority disagree with your definition of the term" when I didn't even attempt to define the term until this reply! Or why you key on the word "orthogonal" which is in the parent of my comment, and certainly is imprecise: A better description would be, OOP holds no exclusive claim to these ideas. We don't all despise OOP, but rather the false notion that it is a "silver bullet." I quite like well done OOP with expressive types.

I'd be irritated by you linking to Wikipedia articles for "Programming paradigm" and OOP except they're mobile links, which means you're getting all in a hissy on the go, and that's sorta cute.

I probably put too much stock in the "As is" at the beginning of your post.

A hissy is a good description of my last comment lol. I was getting pretty annoyed at people claiming that my understanding of OOP is wrong. I don't think OOP should be this incomprehensible thing.

I now understand that you just meant that not all encapsulation is OOP. I certainly agree there. Cheers.

OOP does not start with Smalltalk, but rather with Simula 67 a decade earlier. Simula 67 - not Smalltalk - was the main force that drove Bjarne Stroustrup to extend C into C++ and the rest history: While Smalltalk did enjoy a period of mild popularity in the late 80s early 90s and went on to influence other languages like Objective C and Ruby, the mainstream of OOP was defined by C++ and later Java. These languages viewed focused on statically determined method dispatch rather than message-passing, but this is a feature of their older lineage rather than the butchering of the original pristine form of OOP which never was.

I'd go a little further than Wikipedia however - in my book you need to have a variable that represents more variables. In Java you can do this with a class and an object of that class. In C you can do this with a struct. Both languages are capable of being OOP. Now, in both languages you can also make mistakes, as a programmer. In Java I can decide to make a class called "Monitor" that has a bunch of static methods to control the monitor... such as on/off, change resolution, etc... I would personally consider that a poor design, because while in 1990 a computer had 1 monitor, in 2017, a computer may have unlimited monitors (think controlling monitors over a network for example).

We can make the same mistake of assuming a single monitor in Java or C, but both languages can also easily support multiple monitors ;)

> I certainly wouldn't consider coupling state and function completely orthogonal to OOP though. I doubt most other programmers would either.

The point I was making is that this is not an idea invented by, or reserved for, OOP.

If there's anything somewhat unique to OOP approach (both Smalltalk-like and Java-like), it's constructing the program as a graph of objects communicating with each other (be it via methods or messages).

> but when the majority disagree with your definition of a term, you might want to step back and consider whether you're the one who's misinformed.

Here's the thing: the majority of popular software engineering books were written during the OOP fad. They like to mix up OOP-specific things with universal techniques, making the latter look like a feature (or invention) of the former. A good cure for that is to grab something from pre-OOP era. Consider e.g. reading SICP (or watching SICP lectures) - it's the first book that made me realize just how much concepts popularly associated with OOP are paradigm-independent ways of structuring programs.

TL;DR: OOP did not invent abstraction, it only appropriated it.

Reply on news.ycombinator.com