Live data from Hacker News

Object Oriented Programming is an expensive disaster which must end

smashcompany.com

1–10 of 123 posts

Re: Object Oriented Programming is an expensive disaster which must end

#4
post #2

i haven't read the whole text of this yet. but god damn it, all that text.. and that layout... thats a disaster that must end.

At first I thought it was because I had javascript disabled on the site, but nope, enabling it didn't help one bit.

It's almost as if the site was designed to be solely read on some tiny-screened mobile device or something, with all that text squished in the middle.

Re: Object Oriented Programming is an expensive disaster which must end

#5
post #2

i haven't read the whole text of this yet. but god damn it, all that text.. and that layout... thats a disaster that must end.

If ever an article needed a tl;dr, then this is it.

As far as I can tell, the OP has seen something working in practice, and has set out to demonstrate why it doesn't work in theory.

Re: Object Oriented Programming is an expensive disaster which must end

#6
post #4
post #2

i haven't read the whole text of this yet. but god damn it, all that text.. and that layout... thats a disaster that must end.

At first I thought it was because I had javascript disabled on the site, but nope, enabling it didn't help one bit. It's almost as if the site was designed to be solely read on some tiny-screened mobile device or something, with all that text squished in the middle.

With that much badly organised text, it's almost like it was designed never to be read at all.

Re: Object Oriented Programming is an expensive disaster which must end

#9
> this is my experience whenever I argue against Object Oriented Programming (OOP): no matter what evidence I bring up for consideration, it is dismissed as irrelevant.

This, I thought before even reading the article. I know that frustration myself too well, but have to admit I am often in the wrong, asking the wrong questions, having false preconception.

Lloking at different impleme tations it's clear, experts aren't all that sure, either, even though most implementation specifics aren't detrimental to OOP, so language critizism in lieu of OOP concepts is clearly a strawman. then I stopped reading.

Re: Object Oriented Programming is an expensive disaster which must end

#10
But tell us how you really feel!

I had to bail out about 1/3rd of the way through. Wow, what a rant.

I don't mind the invective, and I'm becoming more skeptical of OOP the more I see larger-scale FP apps work. Mutable state and hidden dependencies are killing us. But I do not like the way this essay is arguing its case. Please do not trot out famous people, tell me their ideas, and then show me how things did not work out for them.

Frankly, I couldn't care less what Alan Kay thinks of OOP. Or Bjorne. Or any of the others. I'm sure they're nice people, and probably a million times smarter than I am. What I'm interested in is this: why do people who know multiple ways of creating a solution pick OOP? And does it fulfill the implied promises it makes to those folks?

The classic example is the statement "OOP is required for creating and maintaining large systems, because it forces developers to think about where things go first, ahead of what the system does."

So here we are presented with a problem: large-scale systems with lots of developers have a difficult time working without a clear definition of where everything goes and how it works together. From my experience that seems like a reasonable problem to consider. So let's talk about that problem, how OOP helps, and how OOP falls down on the job.

Repeat and rinse. Then we get a list of real-world problems that choosing OOP is supposed to help with. We also can start creating some success criteria for both OOP and non-OOP projects.

Otherwise, our arguments get caught up in personalities and theory-of-the-universe crap that doesn't really go anywhere. I can line up a dozen experts, cherry-pick some quotes, and rant away. A person disagreeing with me can do the same. Then we can each talk about how the theoretical system the other guy's way of solving things is built on a shaky foundation. The other guy will demonstrate that this is incorrect by citing an example. It's not productive.

The reason it is not productive is that it is trying to make a universal case based on theory, as if programming were some sort of extension of calculus or geometry. Yes, I understand the association with category theory and such, but programming is the act of multiple humans coming together and creating some better way of doing things for another group of humans. Yes, languages are mathematical, but programming isn't. You want better programming, you'd better start listing out a bunch of ways humans screw the pooch when they're trying to make stuff, then try to help them stop doing that. You don't trot out the set theory books. Wrong answer.

Think in terms of machine language. At the end of the day, bits gotta go somewhere -- both data bits and coding bits. Instead of trying to say "well, we always do things this way because $FamousAuthorX told us", it might be much better to say "we have this process that allows us to dynamically change the method of grouping that proceeds like so"

This is much better because it starts with the problem and lets the solution evolve. Instead of starting with already knowing the solution and then just taking the problem and a big hammer and making it all work [insert long argument for mixed-mode languages here, like Ocaml or F#]

ADD: I also note that developers love making things complicated, and OOP is like a massive playland where you can run off and make complicated stuff all day long. Become your inner architecture astronaut. This is extremely difficult for many to resist.

Post reply on HN