Is Object-Oriented Programming "Dangerous"?

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.

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

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.

A software engineer saying "I'm only going to use OOP" or "I'm only going to write functional code" is like a carpenter saying he is only going to use a miter saw, regardless of what he is building. Just like a carpenter, a software engineer should use the best tool for the job, regardless of which paradigm they prefer.

Suzdalnitski's article must be a joke.

When I read it I feel like the intention is the opposite: Promote the OOP.

Somebody that takes every single advantage of OOP and strongly discredits them with the most dubious claims waiting other people jump in its defence.

Either that, or there is an strong disinformation and he just want to learn from the replies.

We need to be very responsible of treating the topics related to programming theory the same way that tutorials. We should not make so strong statements product of our empiric experiences without additional references.

I mean, somebody can be expert using a language, a lot of frameworks or programming paradigms but in order to talk about the theory everything should come with references, like in scientific papers.

Just to put one example all the section The Problem with Real World Modeling is so wrong that it seems a joke. I am sure he can not find scientific paper that states that The real world is not hierarchical.

The world seems to be not hierarchical, but the complexity of the systems that compose the world are organized that way (the matter, chemistry, biological systems, social systems). For more on this read the first chapter The Complexity of the book Object Oriented Analysis and Design with Applications

Not only the world is organized that way, also the scientists have discovered that the human mind organizes the information using similar structures. For more on this read about Semantic Computing or just Knowledge representation and the Semantics of Natural language. There you would find that OOPs use a subset of the semantic structures and relations that the human uses to understand the the world.

The OOP is not the ultimate paradigm to model the system's complexity of the real world but it has the two or three that serve to represent them in computer systems.

For practical purposes: classes, objects and relationships between them did allow to represent most of those problem domains.

The information system that runs in a computer doesn't try to model the whole world, only the part of the real system related to the information.

The article is weak in most of the arguments, but he had the courage to bringing the topic into the table.

It is very hard to deny the role of OOP in one engineering process, and one should be backed up with solid arguments in science and philosophy to do it. It is not just to point out that "it is more difficult".

We should not forget that information systems exist in order to solve a problem, in a problem domain. Those are the functional requirements. And OOP is good to represent that problem domain.

It is a fact that most of the code (85% some years ago) correspond to non-functional requirements ( persistence with data consistence, integrity, availability, scalability with parallel processing, redundancy, resilience to failure, etc..). Many languages, frameworks and software paradigms fit more those parts and many of them less. It is a matter of the effort inverted on each one of them.

At the end they would merge in just one stack, in the meanwhile we should learn how to profit from each one and combine them to solve the problems. It might be that at the end there is an unifying paradigm or something like that, but it would be combining the goods stuff of all of them. Or maybe not, but then ... how would the new paradigm be?

The new paradigm would be still between how the computers work and how we understand the world.

There is no silver bullet, devs! Use the paradigm(s) that better fits/abstracts your problem/use-case. Each one have pros and cons, and a great software engineer should be able to choose the best given its tradeoffs (sometimes both). That's it 🙂

I remember was OOP was gaining popularity. The article was very correct in many ways but also had some glaring flaws.

The issue with OOP lies with the programmer using it in unnecessary ways. It is not the fault of OOP that people add unessesary abstraction.

For instance, if your light isn't turning on and you decide to become an electrician to learn how to turn on the light when all you had to do was flip the lightswitch it isn't the fault of the lightswitch that you went way overboard. Yet if you are wiring the electricity in a skyrise you might need to do a bit more that slap light switches on the walls to get things to work right.

I don't agree with his premise even though I might share some of the same experiences. I have switched to FP. I think I was using some bad instructional material or a bad mental model for OO that basically made objects just imperative programming containers. And I always found that it became increasingly harder to maintain over time. I wish I had discovered better ways of doing OO back then. For example, I've since seen a lot of good stuff from Sandi Metz. In any case, OO is a paradigm that has gotten the job done for a long time. I think if you stay at it long enough, you can figure out how to avoid most of the footguns and write good software with it. But I found FP before I got to the equilibrium point, and now prefer it.

In my opinion, one of the biggest downsides of FP right now is that most instructional materials insist on bringing abstract math into it. It is not needed. And in fact, I avoid putting my own logic in terms of math categories. Because then I am requiring all future readers to be able to think in terms of abstract math to read the code. Which is a non-trivial burden to take on, definitely not friendly to new devs. The way we do FP is probably simpler than OO. I have an article about that approach here.

I think both OO and FP have potentially harmful approaches. In the end, they are just tools to get jobs done. It is all in how you use them.

Is it possible that the Suzdalnitski was edited? I don't see the "functional programmers are typically more smart, and more expensive" line. It would be a good edit if it happened, but it should be mentioned as an edit at the end.

I think part of the problem is that people say OOP but mean imperative programming and that imperative object-oriented programming seems to be the default nowadays. In reality, FP and OOP are more orthogonal than opposites, and it is possible to write very functional OOP, just not in Java*.

My observations, by the way, are based on the set of people I have worked with and, therefore, absolutely not statistically relevant, so here goes nothing.

Different developers value different things, and develop different skills and focus areas. Some developers seem to value most highly having code that just does what it is supposed to do. Since most of the code we are taught and exposed to out there is imperative, and maybe object-oriented, that's the current they usually follow. If they can just write one instruction after another and read that style all the same, bothering with things like function composition, purity, referential transparency, monads, etc. seems just over-complicating things. They can write programs in a style they are already familiar with and, at the end of the day, the program runs the same.

Some other developers seem to be looking for the Holy Grail of programming, a legendary piece of code so perfect that no mortal eyes can withstand. Having your code do what it is supposed to do is nice, but have you ever felt the joy of writing code that reads like poetry, and not like a recipe from your grandma's baking book? Each piece must be abstracted just at the right level and everything must be composable and testable. These programmers write code very differently that the first group, focusing a lot on how the code should do what it is supposed to do.

Some of these developers discover FP and look at the "horrid" code that developers in the first group write and think that the problem lies within (what they call) OOP itself. Afterwards they go around writing articles on how much OOP sucks. But it is fair to say that others just figure out how to write pleasant imperative code.

However the problem is that imperative OOP is the default, so programmers that don't (not yet at least) have a large interest in how the code is supposed to do things stay in this sphere, while some of the developers most focused on the how feel attracted to more declarative paradigms and, not surprisingly, find a lot of like-minded programmers in that sphere.

Basically, my point is that FP forces you to think in a different way about coding than the default, so people that think more about how code should be written are more likely to make the jump. I believe that if declarative functional programming was the norm, we'd see a lot more sloppy FP and articles saying how dangerous FP is and that OOP is the right way.

* The last line of Java I wrote was in Java 1.8, for all I know this assertion could be incorrect nowadays.

Here's a small snippet from my book Refactoring TypeScript on this topic that sums up my thoughts:

It needs to be brought up: What's better - object-oriented programming or functional programming?

For starters, most people don't understand what OOP was intended to be in the first place. Similar to how Agile today is usually misunderstood (e.g. just because you are having daily stand-ups, using story points, kanban, etc. doesn't mean you are doing Agile).

Alan Kay is considered the father of OOP, in a sense. In a certain email, he gave some frank explanations about what OOP was supposed to be.

"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)...

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things...

But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages."

For those familiar with microservices, the actor model, and other advanced programming paradigms, your Spidey sense is tingling. These are actually more closely related to true OOP.

So, is FP better than true OOP?

I don't think so. I think they both have their merits. Languages like TypeScript are embracing both paradigms and allowing developers to use the tools and methods that work best for the given problem!

I have explained it here, I found his claims very funny, cheap is a really wrong word, functional programming is like a building Rocket for transportation from home to office, which ofcourse is expensive and requires great minds, but do we really need it? I would use a simple car without understanding E=mc*2, it doesn't mean car or I am cheap.

Akash Kava • Dec 17 '18

This is exact same comment on different article by me, dev.to/akashkava/comment/7fig

Coding consists of two major parts, one logic and one is organizing logic. Consider logic as a contents of book and organizing as a book library.Book Library is organized by categories and then it is further organized by either author name or title in dictionary form. Imagine if you had a good contents of book but if it wasn't organized properly. Imagine if everyone organize contents of book and book in library with random order.

I consider class as a way to organize logic, you still have your functional ways to write logic but class is well understood by everyone and it is easy to document and organize. And it is very easy to refactor the code because IDE knows all references of identifier and it can safely refactor it. This was basically the reason why C++, Java and C# became more popular because developers need not focus on how to write it correctly and were able to focus on business needs.

Ideally doing everything in OOP or everything in Functions, both are bad, you must choose OOP to organize your logic, which is extremely important for long term healthy library and functions to improve your logic.

Functional programming represents Science computations closely so it is easy to use it for Rocket Science, OOPS is more for business applications.

More than anything important, I see that they outline frustration of not being able to do one thing easily in OOPS that they were able to do it easily in other paradigm, that doesn't make OOPS a trillion dollar mistake !!

Suzdalnitski's article reads like pretty steeotypical functional-programming zealotry to me. FP has it's virtues, but it also brings it's own unique set of issues. The same applies to OOP, and just about any other programming paradigm you can imagine.

Ultimately, the problem isn't OOP, or FP, or any of that, it's people misusing and abusing those paradigms. Yes, you can shoot yourself in the foot with OOP, but you can do so in any language that's actually realistically useful (and many that aren't too).

Developers who hate on OOP don’t know how to use it.

I perceive objects as configurable tools for processing data throughput - ie processors that can be configured by the constructor and are further immutable. No obstruction, no getters or setters, no data. Data pass through the object only. I know it's very similar to functional programming.