This morning I came across an article that struck me as a fantastic discussion topic: Why Are So Many Developers Hating on Object-Oriented Programming? by David Cassel. "Hmm, sure it has its quirks but I couldn't imagine someone hating or outright avoiding it" I thought to myself. I read the article and had a few opinions, but I'll save that until the end.
According to Ilya Suzdalnitski, a senior full-stack engineer, Object-Oriented Programming is a "trillion-dollar disaster" and "turn out to be one big glob of global state, [which] can be mutated by anyone and anything without restrictions". Suzdalnitski's article can be found over on Medium, if anyone wants to read it.
Cassel's article provides the details of his over-email interview with Suzdalnitski, allowing for deeper explanation as to why Suzdalnitski has taken the controversial position. He explains that he stepped away from OOP when he realized his own return-on-investment was low in terms of time and education into the practice; these days he writes in F#, JavaScript, and C# (using functional programming styles) and "could never find any [use cases for OOP]."
The most controversial statement in Suzdalnitski's article is the statement "OOP is Dangerous". He claims that OOP is for cheap, inexperienced developers and "functional programmers are typically more smart, and more expensive." Suzdalnitski has received some backlash from the development community, with some even writing their own equally provocative articles: Developers Who Hate On OOP Don't Know How to Use It by Gary Willoughby.
So what do I think about these articles? First, I'd like to say Cassel took a heated topic and presented it in a very neutral way. I appreciate that I can read the article and not have had an indication of where his opinion lies in the debate. As for Suzdalnitski's article, I believe it is an excellent opinion piece and controversy can always be fun - but I do not agree that any one language, programming style, or framework is the be-all-end-all solution to every problem. I absolutely agree that OOP will not work for every need, but I disagree just as equally that functional programming will work for every need.
I also do not think that OOP is reserved for cheap, low-tier developers. There are many incredibly intelligent software engineers working with object-oriented programming and it takes a significant investment of time and practice to reach a level of mastery. That said, I have never tried functional programming, so I can't speak to the differences in use and learning curve.
What are your thoughts on the article? Do you agree with Suzdalnitski? Do you disagree? I'm curious what you have to say!
If you'd like to catch up with me on social media, come find me over on Twitter or LinkedIn and say hello!
Latest comments (61)
Thank you for gathering the different opinions and bringing them up for exchange. Usually, I stop reading when someone says "xyz is outright evil and made by the devil himself". Most of the time, there are a lot of things coming together.
The most important part to me is, that you can write good maintainable software with both approaches. And both approaches a far from being new. Even the interpretation of the teens has changed over time when the experience with them accumulated.
In my experience, people often then away from one thing because they are facing a problem and then focus on solving this aspect. If someone was lost in a big pike of interfaces, classes using each other and being distributed over numerous namespaces, it is natural to find something appealing that eliminates the need for that.
If someone is lost in a system where everything is a function, but the things you are looking for are spread across different areas and you have a hard time publishing your state to all places where you need it, I can understand if they seek the order of interfaces and the ability to mutate state.
But there is no silver bullet in a paradigm or language. Each one has advantages and each advantage is bought by the downsides that come with it. So instead of focusing on the negative points, I find it more helpful to look at the advantages and then trying to judge if these are a good enough reason to cope with the inevitable disadvantages. And that's the real skill you have to master as software developer.
We all have biased perspectives towards certain subjects. I think that referring OOP to being very mutable is kinda naive. A lot of the data can be immutable. "Collections.unmodifiableSet(nameOfSet);" as an example and many more.
It is..if the guy who coined the term said it is slippery.
If OOP is the way we organize our thinking then it completely failed us since the original idea was about objects and their connections.
The version of OOP we are using is about classes and their dependancies. Yes we need to make object connections through classes' connections. How many objects we have in our app, and how many classes you have in our code, and exactly how they are connected, if we want to change object connection s how do we do that... if we cannot answer those questions with precision then fine, they will come back as bugs any way. The old folks could answer those questions with procedural programming. Of course you can throw back: who cannot handle those bugs are cheap developers.. but that should be another topic.
Hint: if OOP is broken for us, it is broken for others too, especially the ones invented it, look for them, some of them tried to fix OOP for a long time. It is us with practical thinking and move on with whatever we have in hand. Those guys invented things because they did not just moved on.
I think a lot of the "controversy" comes from not understanding the basic problem.
Which is state-management.
OOP was design to help manage state in a time when the issue was quite new.
It does this by grouping state in objects, this organization comes at the hefty price of lots of bootstrapping code. But at the time it was implemented it was revolutionary. The result was Java, C#, C++ etc..
FP does away with all that bootstrapping and suggest just writing the bare-bones of what you need and then passing state along as needed. State is then only kept at the code entry point and then passed along.
This video goes over the history of state-management fairly well imho:
youtube.com/watch?v=QM1iUe6IofM
The question really should be, what idea-set is best of managing state?
IMHO it is FP, since it takes most of that pesky bootstrapping away, which enables code-reuse, testing, librarization and verbose action oriented code.
On top of that, you do not need as much specialization in your language to support FP. Which takes loads of complexity away.
In theory FP concepts could be applied in Basic using goto...
In the world of software development you (almost) never need to worry about your technology being frowned upon, because...
Give it 15 years and a new batch of genius newbies will be reinventing it as better than the standard technology they were trained on.
In a decade and some, a brilliant person hating functional programming will invent something better... probably a new way to do JavaScript programming... it'll have 2 main objectives... Prudence and Reusability... each of those solving 2 problems each found in functional programming.
They will probably call it the Micro-Ecology methodology. (It will work well with Micro-Services and Micro-Frontends... and it will encourage environmentally friendly concepts!)
...
The only time you need to worry is if your favored technology is too RAD and doesn't need a command prompt... then beware.
People should stop comparing these and focus on best use cases. There is no God tool in a professional world. Visit any professional craftsman’s workspace and you will see very interesting gadgets for very specific actions that you would handle with a hammer and screwdriver at home. God tools are for amateurs that are ok to solve average problems with ease (edit: while not minding extra time and effort spent).
Suzdalnitski says in the article: "Some might disagree with me, but the truth is that modern Java/C# OOP has never been properly designed. It never came out of a proper research institution"
And why on Earth would they even need to come out of some institution? Languages are created for specific needs, not to stroke the ego of some Computer Scientist who has patented/perfected the One True Language. I do not care of purely theoretical aspects implemented in X language that is supposed to make everyone so much more productive... but only so long as you understand quantum entanglement / advanced lambda calculus / the origin of the Universe. Rather, does it fulfill my needs? Can I implement something elementary in it like mutating some data without working around artificial limitations of the language? Does it expose a competent API / can it integrate itself easy with, say, C libraries? These are the questions I ask myself when picking a language.
The truth is, the OOP aspects of the languages Suzdalnitski mentioned work absolutely fine for a lot of people (dare I say, the majority of people using those languages), and using them properly never hurt anyone, which is why most desktop/business software of today is written in, guess what, C++, C# and Java.
He just makes himself sound like every purist elitist nerd with a CS degree out there who discovered FP and deems it to be the all true solution to all problems in programming out there. I hate this kind of people with all soul, they only make programming worse.
Well, so don't use java and OOP for everything, they are designed for a specific needs.
Functional programming is based on maths, maths is used in every science to describe how the universe works.
So Functional Programming can be used for everything.
Java (how is an OOP language) is not worst, is limited, because it's created for a specific needs.
OOP is not "dangerous", not any more than FP. It is just inadequate, it is almost always a very poor match for the actual semantics of the real world problems. Not surprisingly, FP is also very rarely an adequate fit.
Ah yes from Ilya Suzdalnitski, the same auther as from "Functional Programming? Don’t Even Bother, It’s a Silly Toy"
Don't feed the troll...
The article on Functional Programming is ironic and not a denigration of Functional Programming, at contrary... Read it.
I had no idea he had written a similar article against Functional Programming! I'll have to read this when I have another opening to look at Medium (silly paywalls). Thanks for sharing!
Only reason to hate one or the other is if you're stuck working with someone else's code. If you work at a place that only provides Craftsmen tools but you prefer SnapOn, get a new job rather than try to convince the whole Internet that Craftsmen sucks.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.