
The Death of Object-Oriented Programming [video] - mpweiher
https://www.youtube.com/watch?v=ifW0qEJ7OTM
======
Kequc
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.

------
pmoriarty
_" 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

~~~
shitgoose
"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)"](https://www.youtube.com/watch?v=nvTb1B253fQ\)")

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

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

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

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

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

~~~
_Codemonkeyism
Yes. Did you?

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

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

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

------
coroutines
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. :-)

~~~
ww520
Functional programming by itself doesn't scale.

~~~
js8
Can you explain more what you mean?

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

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

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

~~~
efnx
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?

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

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

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

~~~
Chris2048
I think the first point is precisely why OOP is dangerous:
[https://en.wikipedia.org/wiki/Reification_(fallacy)](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...](http://homepage.ntlworld.com/christopher.mallagh/INCKy/OrgPrelIntro/Intro/PlatFal.html)

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

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

~~~
mpweiher
Did you actually watch the talk??

~~~
pjmlp
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).

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

------
epxlabs
Obligatory: "What's dead may never die"

------
mml
TL;DR:

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

------
leenoox_haxxor
"Uhhh.."

