Hacker News Reader

Comment by mabbo | Hacker News Reader

I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming. Or they're using hyperbole that isn't really useful.

You want to know why OOP is useful and common? Because it's easy. Easy things allow for faster development, faster onboarding of devs. Humans need a mental models of things and OOP very explicitly gives it.

But like most easy things, OOP still works well enough even when it's done badly. That's not a bad thing. Working software beats non-working software.

We shouldn't be telling people "stop using OOP! It's only for idiots!". OOP will be here forever. We should be teaching people how to do OOP right, what the pitfalls are that lead to bad design, and how to take badly designed OOP and fix it.

View on HN

> I'm always confused when people criticize OOP, because most of the time the criticisms they use are just plain bad programming

Every paradigm can implement any type of program needed, in principle. The point of criticising a paradigm is to argue to what extent that paradigm encourages that bad programming you mention. If OOP naturally frames problems in a way that leads most people to bad solutions for common problems, that's a legitimate criticism.

> OOP will be here forever

Being the overwhelmingly dominant paradigm of the nineties and early oughts, largely because it was better for large scale programming than simple procedural and got bolted on in a very backwards compatible way to the overwhelmingly dominant procedural language of the immediately preceding period doesn't mean it is going to be around, in a significant way, forever.

> You want to know why OOP is useful and common?

Path dependence, its superiority for large products over what was dominant just before, the dominance of C before OOP became common, and the near simultaneous introduction of C++ and Objective-C which framed the debate about how to move beyond C (which C++ won, which is why not only is OOP dominant, but static class-based OOP on the C++ model, both strucurally and syntactically, is dominant within OOP.)

Yes, OOP is easy. At least the layers of sedimentary cruft were comparatively easy to write. The parts that actually do something, not easier in the slightest. It's still procedural code that must move data. (Usually that code is much less straightforward in OOP because it has to deal with so much boilerplate that is in the way of accessing the actual data).

> The parts that actually do something

This comes up a lot, and I think there's a broken assumption here. The core business logic of a product "actually does something", to be sure. But that doesn't mean that all the other code is somehow less important or pointless. Code that allows multiple people to work on the same abstractions in slightly different ways "actually does something" too--it facilitates cooperation and interoperation. Test code "actually does something" too--it helps prevent issues and ensure quality.

All of those things can be done wrong (core algorithms can have bugs, abstractions/interfaces can confuse people, tests can lie/test the wrong things), but they're all equally necessary in many cases. I think the misconception about non-core-procedure code being "cruft" automatically comes about because very early on in small projects, you don't need much more than the core. But when projects grow (to more people or just more code), other goals, like standardization/maintainability/extensibility/testability, become just as important as the goals of the core: if your added engineering staff can't add value to the company, or if your software is fatally buggy, it doesn't matter how good the shape of the original core-ideas code is, you'll lose money.

I had similar thoughts. Before I started learning how to program Rust.

All your arguments ( standardisation, maintainability, extenseability, readability) are true, but they are not necessarily always brought to you by (ab-)using OOP.

I experienced that OOP can be at times something that can make people see everything as a nail, because all they have got is a hammer. In the end a lot of the real work a piece of code is the transformation of data. OOP often distracts inexperienced programmers from this, which leads to unnecessary complexity in bussiness logic and interfacing alike.

Thinking in the line of data transformation is useful because you will focus on two things: how to do this transformation fast/simple/extensible and what the most useful abstraction over said transformation is.

You can (and given some complexity, must) achieve all of the mentioned attributes without using classes at all. And sometimes taking classes away can make things so much better.

It's maybe confusing because you are presupposing OOP as the default. Humans tend to observe some situation and sythesize stories to explain it, even when it comes to observing their own actions.

I don't mean to unfairly paraphrase but to transpose what you wrote so it shows these stories you are telling yourself

- usually people criticising OOP are "bad programmers"

- OOP is easy, alternatives are hard

- Even if OOP model is a bad fit, it's still a model and the extra devs needed to solve its bad fit can easily be chained to the oars

- If OOP makes trouble, it was because it was "done badly"

- Most easy things work well enough even if "done badly" (that is just not true)

- If OOP can be cobbled together to work at all, it is justified since that justifies anything

If you consider a simpler proposition like, "this can be done in a few hundred or thousand lines of C99 instead of latest C++ and boost", I think there is just no valid reason to bring OOP into it.

Even when I was writing C, I had different modules in different files, only exposed certain functions via the header files and had structs with function pointers that did different things based on how the struct was initialized.

This was before I knew anything about OOP. How is this any different than object oriented programming?

It isn't. Not in a significant way at least.

I think the main benefit of OOP isn't really abstraction, like modules, because even function signatures coupled to a struct definition can be a great abstraction. Abstraction is about generalizing something in order to hide its inner workings. Modules can do that just fine.

What OOP "got right" was to make it easy to use indirection to pass function pointers. That way, you can easily create pluggable systems at runtime, so that strategies can be dynamically chosen. Passing function pointers in c can be pretty tedious, if you need to send implicit state with it.

I've started to get really annoyed with indirection though. It's getting abused so thoroughly in order to make bad designs testable through dependency injection. I find that it is much easier to use dependency rejection instead.

What OOP "got right" was to make it easy to use indirection to pass function pointers.

There was the part in my original post...

....and had structs with function pointers that did different things based on how the struct was initialized.

> You want to know why OOP is useful and common? Because it's easy.

With as much proof as you have given, let me offer you a counterargument: it is common because academia loves OOP. It's easy to teach, it's easy to test. It is most decidedly not easy and very often not useful.

My favorite example of how everything falls apart in due time is the color of a car. That's it, right? A car has a color. A Porsche Panamera might be a "carbon grey metallic" and it's stunning, but that's just one color still. Aye, up until the Mini Cooper tells you they need two colors. This world doesn't fit the OOP straightjacket. Your programming course does but the real world doesn't and when it doesn't then pain follows.

In the real world?

If I’m programming in a monolith, I change the Color property to a List and I get a big red dot with the number of errors the change caused in the bottom of my IDE and it tells me all of the places I need to change the code.

If my car class is part of a Nuget package. I change the version number to represent a breaking a change following the standard semver semantics. When the consumer upgrades to the latest package, they either get warnings about Color being obsolete and use Colors instead or I just completely remove the Color property and they get a red dot and change their code or decide they don’t have time and keep the old package around for awhile.

If I’m writing an API, and since I did properly separate my domain model from my view model, I both map the first item in the Colors list to the Color property in my view model and I create another Colors property.

These are solved problems.

You seem to be translating a modeling failure into an indictment of the whole object modeling paradigm. Your car model doesn’t account for multi-color liveries? Revise and refactor the model. Adapting to change isn’t the same as falling apart.

>it is common because academia loves OOP.

Maybe we're exposed to different evidence but it seems like academia heavily favors non-OOP such as functional programming. Programmers also make repeated citations to SICP class they enjoyed in college but were forced to deal with OOP when they got a real job. It's the commercial industry that pushed OOP. Universities seem very anti-OOP while commercial businesses like Adobe/Microsoft/Google use OOP languages like C++. Other companies that write back office "enterprisey" software also favor OOP languages like Java/C# over non-OOP such as Haskell. I also remember the 1990s when professional programming magazines had monthly articles evangelizing the new thing called "object oriented programming" and you had full-page ads for Turbo C++ and Microsoft C++ that touted its new OOP features.

>My favorite example of how everything falls apart in due time is the color of a car. That's it, right? A car has a color. A Porsche Panamera might be a "carbon grey metallic" and it's stunning, but that's just one color still. Aye, up until the Mini Cooper tells you they need two colors. This world doesn't fit the OOP straightjacket.

I don't understand why your example as you've constructed it proves what you want it to prove. If we use your "car color" as a text template to test the validity of other computer science ideas:

Database table paradigm:

  create table car (
    vehicle_id varchar(20), 
    color_code varchar(1)
  );

... but a car like Mini Cooper can have more than one color. The world doesn't fit the relational table straitjacket.

Algebraic data types such as product type:

  struct {
    char vehicle_id[20]; 
    char color_code[1];
  };

... but a car like Mini Cooper can have more than one color. The world doesn't fit the algebraic data types straitjacket. The world also doesn't fit structs. It doesn't fit the char data type, or array of chars, and so on.

It seems like your example applies to any and all computer science concepts that attempt to model real-world data so maybe I'm missing something?

It's not OOP that's the problem, but your mental model. There's no OOP language that says a car has to have one color.

You can define an object to have more than one color, or maybe instead of having a color have a color pattern. How creative is your imagination? If you use a tuple of (r, g, b) to represent color in a functional language, you will still have the same problem when you realize you can have multiple colors or design patterns. if your mental model has a mismatch with the real world, you will have problem at some point.

Sometimes it's not primarily that it's impossible to model this stuff in OOP, but rather that the change in requirements over time can be more difficult to implement in an OOP codebase. At least that's been my experience.

Okay, so how would you model that in a different paradigm? And why could OOP not model that the same way?

Your example also doesn't specify a business context. What kind of software am I building such that I need to model a car and it's color? That simple question will entirely change how the OOP model is designed.

OOP is easy to teach because it's easy to use, to understand. But again, if you use simple poorly thought out OOP, it may work- just badly. And of course there's the problem of "those who can't do, teach" and often those teaching programming are poor programmers.

Why is color of a car an issue with OOP? Without knowing your the use cases, neither of us will model it correctly for the job at hand.

A car obviously has multiple colors. It has at least two: exterior and interior. Quite often there are two-tone colors. But as a manufacturer, I'm going to guess that each interior and exterior color scheme has an ID. If you are a car manufacturer, the interior and exterior color scheme ID would be all you need.

car -> list of parts -> part.color

Although in fact you should probably allow for composite parts with multiple sub-colors, where each part supports its own enumerated list of possible colors.

In spite of appearances, it's not a completely trivial problem.

Maybe OP meant that to someone doing naive modelling, defining a car class and then giving it a single color property is going to cause problems. Which of course it is.

And maybe also that OOP encourages this kind of superficial thinking. Initial ignorance - and initial assumptions - about the problem domain get baked into the architecture. It becomes increasingly hard to change them as time passes and code grows around them.

Essentially, OOP mixes up data schema and software architecture in a brittle way. Of course you can build abstract classes for variable schemas, but then you're really doing meta-OOP, and there are probably better options.

OOP isn't the only paradigm that does this, but the brittleness seems to be characteristic. If you keep your schemas separate and explicit it's not usually all that difficult to extend/change them. If they're buried in class definitions and you don't have a dependency map to see which part of the schema is used in which part of the code, non-trivial refactoring can become a complete nightmare.

> it is common because academia loves OOP.

Absolutely not! I doubt that anybody was ever taught OOP in an academic PL course, unless it was really an "introduction to programming" course, or their professor was working on this topic at the moment. The meaning of a program in an object oriented language with imperative features and inheritance is not pretty.

There are aspects of object oriented programming that are useful for structuring programs (hidden state) and others which are a recipe for disaster (recursive types). This complexity is always swept under the carpet when teaching OOP. Classes/inheritance/objects are always taught via imperfect analogies, which should tell you everything you need to know about how "easy" OOP really is.

No, the reason it is taught so widely is purely practical. It's a popular paradigm and a lot of practical programming projects might need an OOP background.

---

Edit: Just to be clear, I'm not trying to say that OOP is bad per se.

The information hiding and namespacing aspects of objects are really useful, both in theory and in practice. It's just that I think that implementation inheritance is an imperfect way of facilitating code reuse and not something you should teach to new students...

And most professionals agree with you. “Prefer aggregation over inheritance.”

Which by the way Resharper makes really easy. You add a private variable to your class of the type you want to aggregate and it creates wrapper methods in your aggregating class that just calls your other class.

It’s in SICP, leading up to the adventure game project. That dominated intro-PL conversations for a long time. Also, it’s OO with delegation-based inheritance, prototypes—and some discussion of why.

Refactor, with the right IDE this should take minutes. OOP witbout something like intellij or VS.NET is not fun.

What does OOP has anything to do with your IDE. I think you are referring to typings

OOP is often excruciatingly verbose and boilerplate which an IDE can help with.

You can do LISP in vi or emacs just fine, but for java some kind of IDE to handle the sheer data processing load of source editing is necessary.

Sometimes there is just no right way when it comes to using OOP. Sure OOP is often a hammer that will make everything look like nails, but for some problems it really just isn’t the right approach at all.

For a very good example when this is indeed the case, watch (or read!) this amazing talk by kyren on Game ECS: https://kyren.github.io/2018/09/14/rustconf-talk.html

New to OOP programming. Could you explain what sort of arguments are presented against using OOP? I am genuinely curious.

I've been programming for 15 years (so I was around for the rise of OOP). There's nothing fundamentally wrong with OOP. I still write a lot of classes. But what I haven't written in a almost a decade: code with inheritance, encapsulation or polymorphism. Nothing has exploded.

Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions).

This is OK

    User user = new User("John");

But this:

    StringTokenizer st = new StringTokenizer(str, ",");
    while (st.hasMoreElements()) {
      System.out.println(st.nextElement());
    }

Might not be as clean as:

   stdout(tokenize(str, ",")); // functions are hypothetical

I was about to reply in C# that would usually be done with LINQ, but then I realized I kind of just proved your point since LINQ is functional programming not OOP....

> Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions).

Except these aren't objects, they're just records. I don't think it's a good idea to pollute the word "object" or OOP. You use objects specifically when you need procedural abstraction, otherwise you use other types of values, like products/records, sums/variants, etc.

At high system levels, where you have client/server or other types of protocols, objects fit. At lower levels other paradigms tend to be better.

Thank you for posting this snippet of code, to me, it acts like the episode of the madeleine in the Swann's way.

as you said, nowadays people are using String.split ``` List.of(str.split(",")) `` which is less poetic.

> Also, objects are best when used to represent actual objects (i.e. collections of data rather than collections of functions).

This reminds me of a certain blog post about Java flavored OOP[1]

[1] https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

Excellent examples. Minimalist OOP can be beautiful, but over-abstraction e.g. `FactoryObserverFactory` is absolutely disastrous.

The best arguments against OOP, as it is done in most languages today, are made by Alan Kay, the creator of Smalltalk and the term "object-oriented". Alan should have used the term "message passing" so people wouldn't miss this component of Smalltalk that made it so great.

"I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind." - Alan Kay, Source: https://youtube.com/watch?v=oKg1hTOQXoY&t=634s

It's not an argument against OOP, it's an attempt to redefine the term to be more in line with something that Kay invented.

And the world has moved on. OOP is not about message passing.

> You want to know why OOP is useful and common? Because it's easy.

Try rewriting that without adjectives. Engineers are very convincible, but they need evidence. Personally, I don't find OOP to be particularly useful or easy.

Check this out... "I became a much better programmer when I started writing functional code. Now I tend to write OOP code in a functional way, but learning how to do that was and not easy, and I am not sure most would find it useful." By saying that, I'm basically taking a position that's the opposite of yours, and while it's true to me, it provides no evidence for you to help you evaluate my side of the conversation.

My problem with OOP is debugging it when things go wrong.

But this is often the result of the good property of OOP software. OOP software is easy to write, and allows for easily abstracting over problems.

The net result is OOP programs tend to be more complex. Not "more complex than equivalent software". More complex. But also more capable, more abstract, easier to extend, at least along foreseen lines, easier to change (although that's mostly a tooling thing I think).

But yes, bigger, more intricate software is more difficult to debug. Also abstractions don't help, because often the problem is that there are edge cases where the abstraction doesn't work. Also debugging with abstractions require you to know and understand what the abstraction does.

No true Scotsman.

>Because it's easy

There are lots of cases when forcing yourself to stick to OOP styles or programming is much less easy. You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples.

I don't mind having classes that can inherit available in a language, but languages like Java and C# that force you to use only those things leads to a lot of unecessary boilerplate. You can work around this with static classes full of static functions that you can treat as 'modules' full of free functions. Which, is what I do a lot :D

But I wish I didn't have to bother with that workaround.

I would suggest that boilerplate is small price to pay for having a compiler enforce design discipline and conventions. Remember that code should be written for both the run time environment and next coder who will have to understand it. Constraints enforced in java often make it easier for the next dev. I suspect part of this is that in unconstrained languages, there are so many ways of doing the same thing that pattern recognition become more difficult for all but the most experienced programmers.

> pattern recognition become more difficult for all but the most experienced programmers.

In fact the opposite is the case. The boilerplate obscures underlying patterns because it forces you to read twice as much to infer the same amount of information. Roughly the same design patterns are used in more expressive languages, just without all the boilerplate. This makes the pattern being employed completely obvious since it's only a few lines of code.

Once you use a language for awhile you develop boilerplate blindness just like people have developed ad banner blindness.

I'm sure, and yet it remains true that you spend a lot more time scanning and scrolling your wheel mouse than is necessary. You can also fit far less context on screen, making debugging and "learnability" harder.

There is overhead but with that overhead becomes maintainability, type safety, etc.

For me, on one side is Python. No compiler overhead, very little boilerplate, no complicated IDE etc but no type safety and harder to maintain for larger projects and C# with all of the overhead of a heavyweight compiler but the type safety and great IDE makes it perfect for larger projects where multiple people will be working on it simultaneously.

For simple scripting, where can I mentally keep everything in my head and think through how one change will affect everything else, Python is my go to language. For larger projects C#.

I’ve hated all scripting languages I’ve encountered over 20 years, but for some reason I love Python. It’s also a great teaching language.

I agree Python is good for teaching, but the maintainability and type safety aren't features of the boilerplate. This is clear when considering languages like OCaml, Haskell and other languages featuring type inference.

Python has an external static type checker with type inference.

I learned Rust after learning Python. I do solve similar problems in Rust as I did in Python.

The single worst thing that python thought me, is that it would be cool/useful to make classes. Some call that a “sea of objects”. When I tried similar concepts in Rust I learn quickly that things started falling apart much faster at a point reached much earlier.

However this was also happening in Python – only much later in the game. This made me realize: instead of focusing on the flow of data and useful abstractions (”blackboxes”) over it, I actually made a lot of classes and objects and tried to pipe them into each other, without giving too much thought on the flow of data.

It felt so reassuring to make a Car-class for car objects, wit a Wheel class for its wheels, that I somehow forgot to think about the actual data that I wanted to work on.

The danger of OOP is IMO that it highly encourages bringing in preexisting patterns of abstraction that seem to make so much sense that you discard other, potentially more useful abstractions.

I have more broken Python code than I have broken Rust code, and one of the reasons is, that a lot of the stuff I did in Python (rightfully so) wouldn’t even compile in Rust.

Not a compete one. Full Python semantics is not soundly typeable. Which type checker are you referring to?

To go with the above example of c# vs f#. I find f# far easier to understand because the compiler enforces a strict top down compilation order. Combined with the encouraged basic type system (records and DU) this enforces a very rigid design structure that is easy to understand.

Compared to that c# is a ball of wool where not only have you to follow all strands but also understand when something will happen.

> You could look at various comparisons of code line counts of equivalent programs between C# and F# code as some basic examples.

People have done this methodically, and the results may surprise you:

http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm

That's the one from 1996, there was a newer one that pretty much confirmed the results.

I agree. Even in Domain Driven Design, sometimes you just have transaction scripts. Call a spade a spade and write your code accordingly.

Reply on news.ycombinator.com