All evidence points to OOP being bullshit (2013)
blog.pivotal.io
blog.pivotal.io
Erm, Java is by far not the most OO programming language there is.
For example, primitive types are not objects (no, auto-boxing doesn't make them objects).
> But is Object Orientation (OO) a good idea?
Probably as good as any other programming paradigma out there.
> Does it have problems?
Sure, like every other language as well.
> Is it the right tool for everything?
No, like every other language isn't as well.
> Let’s explore some of these questions in a slightly tongue in cheek and cathartic rant.
And here I stopped reading. If you need to rant, do it over coffee and don't waste my time when even your introduction is not witty enough to keep my interest.
OOP has some fantastic applications and may have been oversold to the author for a project he worked on. OOP(s)!
Yes, OOP is great for agent-based simulations. Only. This is a fantastic, exciting area, but it is extremely niche and tiny.
Anywhere else, OOP is nothing but an obstacle.
The heavily OOP libraries with deep hierarchies are the least pleasant to use. With all those horrible enterprisey FactoryFactoryFactoryFactories, etc.
Flat, fluent, ideally DSLish APIs are much easier to use.
Does the presence of inline assembler make C++ a machine language? I don't think so. Similarly I don't think the presence of primitives in Java make it less of an OO language. They're a leaky abstraction meant to improve the language's performance, which arguably make the language less ergonomic to use.
let's consider a website you would need io -> handler -> database so the io and the database is a mutable connection between the handler that by itself could be fully mutable.
Mostly I think most problems of OOP and FP are solved by Reactive Streams since they encourage small units and each unit could be either programmed with OOP or with a Functional Style. This solves a lot of things.
Btw. I'm mostly writing Scala and I love it, still I use some Objects or sometimes use Java. Golang or other stuff. It mostly depends what I'm doing.
In my my mind OOP is the next logical step after procedural programming (simply packaging up a set of procedures into an object, and adding a few new ideas like inheritance and so on). Functional programming though is not the next logical step; it is a total paradigm shift. The main argument is that you get rid of state etc which means you can parallelize better - but why are no cutting edge games made in an FP language I wonder? Surely they would want to distribute all the physics collision rendering and so on to multiple cores?
It's because functional programming as a separate language makes no sense, you lose too much. But incorporating FP style into OOP languages (such as with the new C++ constexpr, C# linq, and Java lambda), and giving the programmer the choice to use it when it makes sense is a far more powerful option.
objects are used to hold a state and to act as gateway for valid transitions.
most complaints I see come from people using OO programming languages badly, leaking abstractions all over the place and making it so you have to mentally take care of the state of everything instead of trusting your objects to take care of themselves, and thus you get the worst of both world: rigidity coupled with complexity
I need information hiding because my brain is only so big, so I cannot possibly have in mind the whole application state and all it's permutation at all time while programming.
functional languages work similarly in a sense: you avoid thinking about state transitions because the only things you have to take care of is each function input and output
in a broader sense, programming becomes way way simpler if you think of your functions as having 4 well defined input output: the inputs, the return values, data from a persistent store and a state.
And with experience you start noticing that it is much much more simple and productive if in any of your method at a given time you only reduce the 4 io ports in 2: on one side you have functional languages, only ever working with inputs and returns, on the other you have OO languages, which focus so much on the input, state and state, return couples.
mastering the ability of using both styles where appropriate is the key here. but people get dragged into name specific too much, forgetting that these pattern emerged from coding and not the other way around.
That said, especially for a lot of the typical web-related work I do, I find that I'm generally better off leaning towards a more functional approach, as most of what I do boils down to transforming database values to html in 'one pass'. I'd say many of the typical functional programming approaches are excellent for that. Avoiding mutable state has been a wonderful lesson, for example.
Modules and namespaces are the next logical step. And they've got nothing to do with OOP and its dynamic dispatch, which is absolutely, totally illogical.
So, a module is a higher-level instrument of encapsulation and information hiding than an object, but still very much OO.
However, that does not mean that OOP languages are a bust. It is only the OOP principles that are a problem.
So far my experience goes, I've learned to mostly stop creating analogues of real-world things (as OOP principles would have it), except where it makes sense to, and instead use OOP features to create distinct responsibilities. Turns out OOP languages are identical to, let's say, "responsibility oriented programming" languages.
OOP languages can also be used for other things, as previously mentioned: data oriented programming. DOP is used widely in gamedev. Gamedev also happens to be an industry that heavily uses an OOP language: C++.
Hate the principles, not the languages. There's a big difference.
I agree. Almost everything useful around us is the product of ideas with our needs in mind, there was no TV and TV remote control in nature, no vacuum cleaner, clothes, watches... if ever, nature inspired us. We create artitifical things that make us more efficient and effective than it would be by just dealing with raw stones and sticks as they are found in nature. When it comes to today OOP we have to deal with stones and sticks again instead of thinking about a new aritifical thing that directly satisfies our needs (you call it 'responsibility').
That was simply the closest word I could come up with. You've described what I was trying to say in significantly more detail (thanks!).
Someone would ask "why not assembly/plain C/Fortran/etc.". The answer is that C++ gives you a lot of good ways to structure your code semantically, while still letting you produce tight machine code. That's the real kicker here - I need to reason about my program as an engineering construct running on real hardware, not as an expression of Computer Science algorithms.
In a nutshell, for a new programming language to be a viable way to build our core product, it has to
1. Go Fast and let us Go Faster Than Everyone Else, preferably letting me write platform-specific assembly when I need to
2. Interoperate with C++
I've seen a few recent languages attempt to cover 1., e.g. Go, Rust, Julia, for some use cases. However, I have never seen a language attempt to tackle 2. Not even for the case when you have vanilla classes with virtual functions and a few sane templates.
I think education carries most of the guilt for this. The typical examples given in OOS classes are stuff like Car is an ancestor of Truck and SportsCar. Which led to Beans and Entreprise Java. You never want this kind of shit with your data. Much better to use plain old maps to carry content the way God intended, and to put your effort in creating flexible and reusable methods.
> Beans and Entreprise Java
I don't know. Netflix is built on Java, using OOP. It works well for them. Windows is built on OOP, quite a big application and works.
J2EE has its problems, but it also gives you a lot of functionality. Reusing methods is nice, but developers on projects with very complex business rules (does not equal simple, but large scale projects!) don't worry that much about flexible methods as they're experienced enough. Distributed transactions, session replication, etc. are slightly more important. J2EE gives you all that by default.
(And I really don't like EJBs and this kind of stuff, but don't mix up two very different levels of problems.)
I did have that in the back of my head when I wrote the comment. And speaking of, I'm also aware that OOP was very popular, and I don't feel completely comfortable when I criticize successful stuff - it must have worked for a reason. But still, that's as far as my brain can take me by itself: OOP should be used sparingly and EJB should not exist.
(For the record I code mostly in Java, though as lisp-like as I can)
So close to haiku,
only one more syllable,
great embarrassment.[0] http://www.bristol.ac.uk/arts/exercises/grammar/grammar_tuto...
Unfortunately, I can not change the post any more.
Subtlely different meanings to be parsed...
You can guess that functional programming is going to be his response I suppose considering this page is the second part of a functional programming article. (the first part being missing)
If you want to analyse, you would need to also talk about what OOP is good at and how that translate in whatever other paradigm. This article only concludes with a "I do think it is a valuable mechanism for developing software", but there is absolutely no backing for that statement anywhere in the article.
I tend to agree with GP. At the end of the day, for general programming, any paradigm is going to end up producing similar quality of code. Developer competence, motivation and budget are going to be #1 factors that determine code quality.
Google, OSS, Modern IDE, Engineering practices like Continuous Integration/Deployment, TDD/BDD are all having a much bigger impact on the code quality than the specific languages or paradigms.
I'd say that "pure" paradigms tend to be almost equally bad (tried functional programming in production code, wasn't all it's advertised to be). But this actually leaves you with more freedom, because you have to pick pieces and create your own style. So it turns out to be more important, not less, that you understand the how and why of each paradigm.
As for how good this particular article was - well, I agree with the premise and it gives links to sources. May not be the Mona Lisa of articles, but it got my upvote. I'm not a regular HN reader so it's the first article on this topic I've seen in a while.
My intention was to point readers to some of the good ideas that were emerging (more accurately: had emerged some time ago) from alternative paradigms and how they could be used to make OOP programs better. Agreed that its certainly more about the team than what syntax you use to push bytes around, but tools do matter.
I use closures to hold state all the time in node, I still don't understand why state in a closure is better than state in an object.
If someone could explain this I'd be grateful: articles like this just seem to say 'state is bad' and ignore that it still exists in functional scopes.
I do not buy that.
The reality is, that when OOP is correctly executed (and there is the real culprit, since few people have really understand it!) it really can help you to lower the complexity of programs -- and that is decisive, not some halve-religious statements.
[1] One example: Inheritance vs. Composition -- even OOP people have seen the problem that overuse of inheritance is bad. But they don't throw the whole thing out of the window, but tell where to use it or restrict its usage. Don't just find the problems and fanatically throw all (even the good stuff) out of the window!
Yet to be proven. I never seen a single example of OOP bringing anything but more unnecessary complexity.
Can you find anyone who agrees on what "correctly executed OOP" is? I don't think there is a consensus on this idea, nor any particularly objective criteria for how to achieve good OOP.
Bjarne Stroustrup - Object Oriented Programming without Inheritance - ECOOP 2015
Well, turns out that one of the oldest programming languages in existence, Fortran lets you do OOP, it also has pure functions and subroutines. I'm talking about about Fortran 95/2003/2008:
http://h21007.www2.hp.com/portal/download/files/unprot/fortr...
Unfortunately, I don't think it's something that can be bolted on after the fact.
Maybe some Javascript "transpiler" could do it... it would be really interesting.
The advantage of going with some sort of transpiler is that you can have two kinds of code within the same process whilst you make a gradual transition. I feel like, it could be made to work, but the boundary would have to be quite heavy-weight. Think less gradual typing and more FFI.
Edit: actually, in depends on which side is doing the calling. Going from checked to unchecked code is a minefield, but if it's unchecked code calling into checked code, it could work quite well as long as the arguments are immutable and don't have methods that can do IO.
http://stackoverflow.com/questions/3141087/what-is-meant-wit...
But after I saw a comparison of OOP and FP [0] I had to laugh a bit. What about monads and category theory? I also didn't fully grasp FRP with all its streams and lifting.
A bit of Googling yields no source for the alleged Alan Kay quote either.
"'good C++' is better than 'good C'"
OOP has some brilliant patterns. It is also very hard to do correctly.
Because they are implementation details that have no place in pseudocode. Their absence there does not say anything about their usefulness in general. You can't point at some observation about pseudocode and say "See, they don't use it so it must be rubbish." Exceptions, handling of error variables, monads, unsigned ints are also absent from typical pseudocode (unless the context is about those concepts). Does that make them useless concepts aswell?
FTFY
But I would be interested in your arguments.
Basically I think we need to use tooling (in which I include languages and paradigms) that aim to come with less foot-guns and more safety rails.