> Extremist languages like Java force you to think of everything in terms of objects.
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.
Can someone make a chrome extension to filter out the OOP vs FP articles on hacker news? I mean, how many more articles do we need? Is there anything new?
Yes, FP is cleaner. Yes, OOP is useful for things like plugins. Yes, favor composition over inheritance. Yes, FP is impossible to read. Yes, immutability has its limits. Yes, Yes, Yes. Enough already.
Even FP needs some mutability when it comes to databases and user input.
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.
Compare the DirectX XNA OOP library to the OpenGL procedural library, and you will quickly see that when OOP is done right it makes code fun and easy to work with again.
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.
OOP is about information hiding and providing well defined state transitions.
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.
> In my my mind OOP is the next logical step after procedural programming
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.
OOP, as defined as a set of principles, is a complete load of horse shit. There are many more reasons other than what the article states as to why it doesn't deal with realities of software (e.g. data oriented programming solves some of them). OOP principles are likely one of the reasons it takes so long to train fresh-out-of-college employees, as they first need to learn how to forget that utter bullshit.
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').
To me, as a C++ programmer, none of this really matters. I'm working on a very compute-intensive program with a lot of modules, used in professional settings. It has to go fast. If using C++ means we can go faster than someone using whatever else, at the expense of needing five times the people and six times the development effort, we'll pick C++. We're interested in the maximum performance achievable with the language, not the average use-case.
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.
Depends on how you use it, of course. Libraries make wonderful showcases for OOP strengths - I always like to give Java Collections as an example. But if you actually build your application code as OOP... well, I might privately think you deserve everything that happens to you because of that.
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.
> But if you actually build your application code as OOP
> 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.)
This is a very general problem. As a organizational unit, you need to follow a path, but if it is difficult to determine the source of your problems in the first place, many things will sound like solutions.
[Shameless plug] For a philosophical interpretation on the differences between OOP and FP, you may enjoy my gist: Descartes, Berkeley and Functional Reactive Programming
It's actually a common misquote of Descartes to say "I think therefore I am." A more proper translation is "I think, I am" which has significant implications for his philosophy.
This article is just pointing at the flaws, not really offering any alternative. It is just as GP said, a rant better kept for the water cooler area.
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.
> At the end of the day, for general programming, any paradigm is going to end up producing similar quality of code. Developer competence
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.
Author here, FWIW this article was one of many posts some colleagues and I wrote at Pivotal during a "blog writing tontine" to encourage us all to write more and develop our skills, written hastily and intended to be part of a series I didn't finish before leaving.
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.
State in a closure is equally as bad as state in an object. The difference is FP gives you ways to manage and isolate state that simply don't exist in OOP.
"All evidence" seems to me a real gross overstatement here. The author collected some topics, where he means that OOP is bad and sticks some (partly related) statements of other people to it and wants to convince with that, even when he makes some valid points here [1].
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!
> The reality is, that when OOP is correctly executed
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.
Zed Shaw talked about experiences teaching programming in this LXTHW series. I cannot cite the exact source right now, but in essence he said, that novices grasp all concepts up to OOP, where there is no more analogy in computer architecture and people seem to get stuck.
Does anybody know of any language that supports OO, but that lets you declare pure functions/methods - enforcing that those pure functions/methods only use other pure functions, don't use global objects, etc? Lately we're adopting Redux [1] together with React and the idea of being able to mix functional and OO in a better way looks more and more interesting to me.
Does anybody know of any language that supports OO, but that lets you declare pure functions/methods - enforcing that those pure functions/methods only use other pure functions, don't use global objects, etc?
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:
I'm actually working on such a language [1]. It's OOP, but it makes a division between 'doing objects' (services) and 'being objects' (values). It's coming along, but it's still missing many vital things. It wasn't inspired by, but bares a striking resemblance to, the noop language [2].
As a comment indicates, all evidence points to this article being a load of bullshit. There's not a single concrete example in it that proves anything of the author's claim. To counter, I think this will do nicely: http://www.johndcook.com/blog/2015/07/31/the-success-of-oop/
I really like many points of FP. I like to stick to immutability, map-reduce and expecially Redux.
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.
I believe OOP gained such a foothold in programming world because it was (and still is) very useful for building GUIs on the PC. Since PCs have taken over the world, so had the OOP. But in other areas the OOP model is questionable. For example, you have transaction processing applications that have been built for years on mainframes with different models.
[+] [-] bhaak|10 years ago|reply
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.
[+] [-] d--b|10 years ago|reply
[+] [-] brudgers|10 years ago|reply
[+] [-] merb|10 years ago|reply
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.
[+] [-] hacker_9|10 years ago|reply
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.
[+] [-] LoSboccacc|10 years ago|reply
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.
[+] [-] sklogic|10 years ago|reply
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.
[+] [-] zamalek|10 years ago|reply
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.
[+] [-] lunz|10 years ago|reply
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').
[+] [-] anon4|10 years ago|reply
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.
[+] [-] tadlan|10 years ago|reply
[+] [-] steveklabnik|10 years ago|reply
[+] [-] godDLL|10 years ago|reply
[+] [-] radu_floricica|10 years ago|reply
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.
[+] [-] sz4kerto|10 years ago|reply
> 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.)
[+] [-] flipp3r|10 years ago|reply
[+] [-] JupiterMoon|10 years ago|reply
[+] [-] sedlich|10 years ago|reply
[+] [-] userbinator|10 years ago|reply
[+] [-] mtrn|10 years ago|reply
[+] [-] PythonicAlpha|10 years ago|reply
[+] [-] dmvaldman|10 years ago|reply
https://gist.github.com/dmvaldman/f957dd9a8ed3f6edf35d
[+] [-] n0us|10 years ago|reply
[+] [-] gutnor|10 years ago|reply
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.
[+] [-] radu_floricica|10 years ago|reply
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.
[+] [-] excepttheweasel|10 years ago|reply
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.
[+] [-] malux85|10 years ago|reply
[+] [-] nailer|10 years ago|reply
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.
[+] [-] seabee|10 years ago|reply
[+] [-] pvdebbe|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] PythonicAlpha|10 years ago|reply
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!
[+] [-] sklogic|10 years ago|reply
Yet to be proven. I never seen a single example of OOP bringing anything but more unnecessary complexity.
[+] [-] excepttheweasel|10 years ago|reply
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.
[+] [-] mtrn|10 years ago|reply
[+] [-] nly|10 years ago|reply
Bjarne Stroustrup - Object Oriented Programming without Inheritance - ECOOP 2015
https://www.youtube.com/watch?v=xcpSLRpOMJM
[+] [-] danmaz74|10 years ago|reply
[1] https://github.com/rackt/redux
[+] [-] AlexeyBrin|10 years ago|reply
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...
[+] [-] DanWaterworth|10 years ago|reply
[1] https://github.com/DanielWaterworth/plastic
[2] https://en.m.wikipedia.org/wiki/Noop
[+] [-] bitJericho|10 years ago|reply
[+] [-] rhodysurf|10 years ago|reply
[+] [-] Delmania|10 years ago|reply
[+] [-] k__|10 years ago|reply
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.
[0] https://pbs.twimg.com/media/CNPKc6xU8AApYPy.jpg
[+] [-] chmike|10 years ago|reply
[+] [-] billsix|10 years ago|reply
[+] [-] asgard1024|10 years ago|reply