The Death of Object-Oriented Programming [video] | Hacker News Reader

The Death of Object-Oriented Programming [video]

youtube.com

62 pointsmpweiher42 comments

I think there's too much attention payed to ideologies in programming. OOP is bad but only because it is so demanding in its scope. Everything in programming is really just a set of tools, so who is deciding which tools I am to use all the time?

The flaw in OOP is simply that a lot of things do not need to be instances. Fewer instances of different things, fewer problems. If you want to perform a mutation on an object, it's best to pass that object into a mutator and get your mutated object on the other side.

I shouldn't need an instance of a mutator, which gets I suppose attached to the object I want to mutate. That adds all kinds of (in this comment unspecified) unnecessary and really useless complexity.

"It's not so much about the death of object oriented programming, but asking the question: 'How can we prevent it from dying? How can we recapture the spirit that was, I believe, the vision in the 1980's and make it come back to life again?'"

In particular, he wants to focus on:

1 - bringing models closer to code

2 - trying to exploit the domain models in the development environment

3 - linking code to the ecosystem

"It's not so much about the death of object oriented programming, but asking the question: 'How can we prevent it from dying?'"

don't. Don't prevent it from dying. Just let this academic bullshit go away. "Why won't you just die (https://www.youtube.com/watch?v=nvTb1B253fQ)"

The problem with OO is not that it is "academic bullshit". The problem is that assembling a system out of bags of hidden state communicating with messages isn't always a good idea, particularly when they all can have references to one another. If anything, it's a lack of rigour - something that might be considered academic.

> The problem is that assembling a system out of bags of hidden state communicating with messages isn't always a good idea

Of course, as soon as your system is socio-technical (includes people), you're rather doomed in that direction already ...

> If anything, it's a lack of rigour

More specifically, some people do a poor job following basic best practices to reduce and manage complexity, such as encapsulation and the tried and true separation of concerns, and then proceed to pin the result of their own failures on abstract concepts, such as programming paradigms.

There's that saying that goes something like "a bad workman blames his tools"... Well, a programmer bitching about basic programming paradigms is just that.

Vague best practises, coupled with "if it works, the method works. If not, you must have failed to do it right".

It's easy to talk about the notional "bad programmer", and scapegoat that, but why shouldn't the methodology take a hit? I find one of the differences between a novice and an experienced developer is not adherence to "best practise", but knowing which ones are good, and which ones are bullshit (or nuanced, i.e. might get you in trouble).

Also, "tried and true" is problematic, there are lots of biases and confounding factors. I would say a lot of OOP project may succeed because there is a lot of investment in OOP, diverging from this automatically puts you in new territory.

what does this mean, practically? maybe I'm just not experienced enough with programming to understand but this all seems to be vague words that don't mean anything

In other industries and sciences people would look at facts, sample companies and practitioners and form hypothesis.

In our industry people with no broad experience formulate what they think the world should look like and go around trying to convince others.

How does this relate to the talk (rather than some of the comments here)? Did you watch the talk?

Yes. Did you?

I find people go around with "experience", which is anecdotal narratives of their own success/failure, and use this to inform their view of how things should be done.

If you aren't actively researching software engineering, or applying stats beyond the scope of your own experience, you might as well pick some kind of ideology as a guide to what things should look like, otherwise you'll only have your own biases/subjective-experience reflected back at you.

He poses the question asking what Object Oriented Programming paradigm is, and then responds that the obvious answer is the notion of Classes, Inheritance, and Objects. He then goes to correct that notion by suggesting that "what it's really about is...you figure out what the domain abstractions are for you, and here we give you these mechanisms to implement those. But in the end you don't write your programs with objects and classes, you write your program with the domain abstractions which you have defined."

This to me is a ridiculous statement. EVERY paradigm is about providing tools to handle the domain abstractions which we have defined. Object Oriented Programming is exactly and specifically defined by a paradigm expressed by Object instances of Classes, meant to embody Encapsulation, Inheritance, Abstraction, and Polymorphism. OOP clearly means something to this person that it doesn't mean to the rest of the world, but he strikes me as someone who has spent the better part of the last 2 decades in pure academia.

There is no "death" occurring in regards to OOP, and there won't be for a long time, if ever. It works very well for many things and times it's not the best choice are the exception. Misleading title.

How do you know what the best choice is? Seems to me is just OOP by default, with very little alternative.

This is kind of fun for me being a 90s kid. I learned to code when imperative frowned upon (maybe it was never in style?) - and now OOP is falling from its pedestal (but still useful to understand). I'm looking forward to the next decade when people become disillusioned with functional programming. :-)

Functional programming by itself doesn't scale.

Can you explain more what you mean?

If a problem can be simply modeled by state machines, use OO. If it's simpler to model a solution using function composition, use FP. You can write shit code in any language, but patterns are timeless.

Any problem can be modeled by either of those things. What matters is whether you abstract your state mutations or scatter them all over the place.

Absolutely agreed. Goal should be simplicity with a healthy dose of mechanical sympathy.

> healthy dose of mechanical sympathy

This is interesting -- it's something I think about too, but it's not clear to me what it _really_ means, unless its a personal thing specific to ea. developer being sympathetic, and is just meant to mean "Are you mindful of what's going on? If not, pause until you are". Maybe then one sees earlier pitfalls, or chances to succeed.

Can be, yes, but that doesn't mean modeling it that way would be sane. Working with a fully FP game engine sounds terrible, for example.

Why do you say that?

The hard part is figuring out what that should look like. There are hardly any purely functional game libraries (graphics, physics, sound) so to say that an entire engine sounds horrible makes no sense. What would that horrible even look like?

Agreed. I'll add, ask yourself:

    - Will it cost a lot to change your mind?
    - Will this make it harder to debug or easier?
    - How long have I gone without a big, costly/risky rewrite?

This is what it means to have a good or a bad architecture.

Can we all stop repeating those platitudes / tautologies please?

Well, that or we could identify them as common repeated argumentative elements, attach names to them, and call them rhetorical patterns :)

This has been already thought of: https://en.wikipedia.org/wiki/The_Futurological_Congress " Instead, papers are distributed in hard copy and speakers call out paragraph numbers to call attention to their most salient points."

Look I get that many people like to make these broad statements about the quality of one model vs the other, when the reality is that they do better for different things. OOP works really well for abstracting and creating easy to read and write code. Functional Programming works much better for data science related tasks. The truth is both are here to stay, and that is a good thing.

Well put. Programming paradigms shouldn't be an ideology but a tool. Too often did I see FP evangelists abuse FP as an excuse to write "academic" code.

I can't see that this is true - how is OOP better at abstraction? Or readability?

OOP abstracts pieces of functionality into objects, which is closer to how we view the real world. It is often much easier to think about code that has been abstracted into objects, given that good abstractions have been made. This makes code re-usability more well organized. This all breaks down, however, when the task at hand is not well suited to OOP(think data science). If the number of abstractions per amount of code gets to be too great than OOP starts to become somewhat detrimental. In this case Functional would be easier to read and have more efficient abstractions.

I think the first point is precisely why OOP is dangerous: https://en.wikipedia.org/wiki/Reification_(fallacy)

It may be initially easier to model a problem with 'Nouns', but this won't necessarily reflect the structure of the implementation, which is what I think the code should reflect.

http://homepage.ntlworld.com/christopher.mallagh/INCKy/OrgPr...

Sometime the abstractions aren't quite as perfect in their implementation as modelled in the mind. Then you realise you need to model implementation differently from domain, and the difference between the two can cause issues (leaky abstractions, shared-encapsulated state, etc).

To put it another way, information should be communicated using concepts from the way people thing about the problem, and the code can communicate this, but the actual structure of the code should reflect the implementation.

the same kind of thing that can happen in ORMs wrt the actual difference between object-hierarchy structures, and relational database structures...

Another rant against OOP, while on the real world every successful mainstream programming language has some form of OO paradigm support, yes even the FP ones.

C and Assembly are probably the only non-OOP languages ones still left.

Did you actually watch the talk??

No, because they are always the same.

They rant OOP is dead and there is some new path being chosen, beating the dead horse on Java and C#, while forgetting almost every other programming language, including FP ones, do have OOP support.

One just needs to look at the SIGPLAN papers to see that there is more to OOP approaches what Java and C# (actually Smalltalk) offer.

Likewise FP isn't Haskell, there are many other FP approaches.

Meanwhile in the real world, most successful programming languages are either mainly OOP based or multi-paradigm (including OOP).

Well, you might actually want to watch the talk, because it's pretty much the exact opposite of what you describe....

>beating the dead horse on Java and C#

> most successful programming languages are either mainly OOP based

Aren't those two of the most popular languages?

Obligatory: "What's dead may never die"

TL;DR:

OO would be great if the world were completely different from the way it is.

"Uhhh.."

Reply on news.ycombinator.com