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