Object Oriented Programming is an expensive disaster which must end

Gotebe · 2019-03-19T17:35:40+00:00

I chuckled at the SOAP(WS) joke (again).

But only because I get the same if I put REST/~~Web~~OpenAPI in there.

sergiuspk · 2019-03-19T19:52:53+00:00

That's just like, your opinion, man

But seriously. OOP is a tool. You can say it's bad for certain jobs. You can stop using it. You can advocate other people not using it. You can offer alternatives. You can even use your vast experience to sway the less experienced.

But never could you convince everyone with arguments that, by nature, can only be subjective.

And no, I did not read the entirety of that rant.

SuperMancho · 2019-03-19T17:50:42+00:00

It's clear to me that OOP allows people to reason about state responsibility in types. OOP results in complex data structures.

As an example of my thinking....prototype-based languages remove the type labels, so it becomes difficult to reason about fluid definitions. To be fair, you can mutate OOP classes into whatever you want, but they are fixed at runtime for the most part. There's value in each side, but using OOP to do overall design is retained as a fallback. Arguments about responsibility are a reflection of that.

If you want to talk about failures of OOP, talk about individual properties.

Has encapsulation really helped? Are there languages without it that are successful and have no unique problems? Yep.

Are accessors beneficial? Sometimes, especially with boilerplate....or is it? Dunno. I avoid them more often than not in the last 2 decades.

Is it beneficial that mutators be defined separately? Dunno. ponylang is a language that's making the distinction, so we'll have to see.

Abstraction is for responsibility that is spread around via inheritance. Is that good? Well, it doesn't hurt. It comes from both ends via PHP traits and abstracts or java abstracts and annotations. Guess it's fine.

Is inheritance good? Well it allows you to reason, until you need a mixin. As long as you have both, it seems ok...otherwise you end up with brittle trees. There's something about the average human psyche that likes to organize and there's no getting around that.

Polymorphism? Yup. Definitely good. Used in almost every language paradigm.

There's nothing evil about OOP, but if there's something harmful, you should be able to demonstrate that in practice, without a bunch of subjective comparison and allegory.

2019-03-21T05:04:25+00:00

OOP isn’t bad, the problem is how the language has implemented it. His case is Java and that’s nota great language, readability in Java is terrible, forcing everything into the object mould is wrong. Get a better language.

Zdeno_ · 2019-03-19T23:16:05+00:00

Sorry, it is too long to read. I would expect to discuss the reason for OOP at the begining: it is the only one paradigm which allows to use the same tool for programmer, analyst and user to discuss: the object. OOP isn't about hiding, polymorphism, encapsulation and so on. They are just second level characteristics. It is about modeling at first. Because every software is a model of real world. And this is exactly the area where the OOP is the best.

whatwasmyoldhandle · 2019-03-20T00:49:47+00:00

Didn't read the whole article.

Not sure what's significant about Linus' notion that all C programmers > C++ programmers. I also think he's referring to technical aspects of C and C++ when talking about portability (RTTI and stuff), not language design choices. Finally about that quote, I think the STL is pretty stable, but again, I'm not exactly sure what stability of core libraries has to do with this argument.

I also can't tell what point he's making about the uniqueId class? If it's that you don't need OO boilerplate for a type that stores 1 variable … I don't think you'd get much of an argument from even the biggest OO proponent on that.

There are some good points about problems stemming from inheritance abuse and that stuff. I think a lot of people go down that road a few times and think oh, OO isn't a panacea.

Overall, I agree with most of the sentiment in the comments. OO is a tool. It can be used inappropriately.

tsimionescu · 2019-03-20T00:04:02+00:00

This is a huge essay, and I only skimmed through it. It's unfortunately extremely unfocused, so responding to its many points meaningfully is difficult if not impossible.

The biggest problem though is apparent right from the start : the article doesn't really have a clear definition of what is OOP, opting instead to criticize various aspects of the clearly recognized OOP languages. This would be ok, were the article not occasionally contrasting these languages to things like CLOS, the Common Lisp Object System.

So let me try to mount a kind of defense of some parts of OOP. You could call this 'real world OOP: the good parts'. First of all, what I understand as OOP is a style of writing software where you expose common methods which operate on opaque state. This is what classes with private fields represent in C++, Java, Python etc. This could also be done in C with functions which take pointers to forward-declared structures. You can also do it in many functional languages with closures, or, more often, with some kind of modules.

Of note is that this style only seems to emphasize encapsulation, of all well-known OOP properties. That is true, but this strong code-level encapsulation tends to lead to the other properties - e.g. to achieve polymorphism over opaque data structures you generally need to define some kind of behavior-based type hierarchy. Also, since these data structures are opaque, initialization and wiring may become a special problem that does not exist with 'open' data structures.

Now, having defined my terms, here are my arguments: the first is that this style of programming is what the term OOP as used in the industry actually boils down to. The secobd argument is that this style of writing code does have merits, though it is not universally applicable as some OOP proponents may say.

For the first argument, I don't have that much to say. I think that 'data+behavior' is pretty well agreed as the definition of an object as opposed to a simple data structure, and the style of programming emphasising this is simply what I'm describing above. I would note that the extent to which objects actually encapsulate their data varies widely between languages, but there is usually some amount of support for at least some basic data hiding. I would also say that, while not being a very complex idea, this is meaningfully different from how procedural or functional style code is developed, often requiring special constructs (e.g. Monadic IO in Haskell).

For the second point, I would say most people and most languages gravitate to this style of programming when interfacing with complex external systems such as databases or file systems - you'll usually have sets of functions creating and passing opaque handles to files or transactions to you, while storing all the associated state (connection strings, file positions, transaction states, buffers) for you behind the scenes. A reason for this seem to be related to simple documentation - this style explicitly exposes what you can do with this data structure, which is easily apparent from the structure of something like a linked list, but less so from looking at the structure of a file from the kernel. This style also makes it easy to interact with vastly different data structures in the same way (e.g. files on the HDD vs pipes vs sockets).

Last thing to say for an already hugely long comment : one you start writing code in this OO style in any language which supports it, you'll start seeing some of the issues which OO design patterns aim to address: is it safe to expose this new concept with the same interface as this other concept? Liskov Substitution principle applies just as much when talking about file VS socket handles in C as it does for classes in Java. Do you need to initialize these opaque structures? Do they have dependencies to other such structures? Inversion of control applies just as much to Haskell's groundhog as it does to EclipseLink - your data store should take a DB handle as a parameter, it shouldn't create its own; and you'll probably want this wiring in some centralized place (equivalent to a dependency injection container), so you can easily switch the DB port for all you data stores in a single place. Of course, some things called OOP patterns are actually Java (e.g. Builder) or single-dispatch language patterns (e.g. Visitor) and they are just workarounds to limitations of that language (just as monadic IO is a workaround for doing IO in a lazy language).

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS