Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

131–140 of 357 posts

Re: OOP Is Dead, Long Live OOP

#131

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

A poor model for computation that is pervasive in the industry. Poor models usually don't become pervasive.

The engineering organization where I work is full of dysfunction. This is because numerous poor practices were ignored or encouraged over the years. Now there is strong inertia against change because the incompetent long-timers know all the tricks and manage their job security through the system as it is.

This is not uncommon especially in the Bay Area.

Re: OOP Is Dead, Long Live OOP

#132
post #117

Earlier quoted context omitted.

How so? I believe I was addressing the fundamentals of OOP: Classes, methods, inheritance, overloading, visibility, etc. Also, Rust, while allowing the assigning of behavior to a type, is explicitly not OOP. Check it's Wikipedia page (which doesn't include OOP in the list of paradigms) and the O'Reilly book (which says Rust isn't OOP).

I didn't mean rust was fundamentally OOP, but that rust implements, through runtime traits, exactly the behavior you are criticizing OOP for. Sorry about that

Can you please point out exactly what I said when you say 'the behavior I'm criticizing OOP for'. Haskell typeclasses are very different from OOP inheritance or OOP classes. In any case, I don't see how that relates to the explicit criticisms I made.

Re: OOP Is Dead, Long Live OOP

#133

OOP is just a mental model. Deep down everything is made of bits. The church of OOP has failed but if something looks like a duck, walks like a duck and talks like a duck it probably is useful to make a duck class. We're now down to fighting for nuances. You can do most things with OOP or without OOP but each path has some upsides and downsides and most of the time it's good to use some things it provides where it ma…

> The great architect has the foresight on how the code will be used in five years and design it accordingly Perhaps this is a function of me working in startups and consulting my whole career, but it seems extremely misguided, if not negligent for an experienced engineer trying to design for use cases five years in the future. Five months into the future is even pushing it. What kind of companies operate in this way…

Probably every company outside the startup domain? If you're working on product-market fit, then you can expect to discard lots of systems, however, that's a niche and even startups are only temporarily in that position (unless they fail). For any business where there is a clear product-market fit (which, employee-wise, is pretty much all businesses) the systems rarely go away, they accumulate - if you're not a startup, or if you have found your product-market fit, then you expect that your products and processes won't disappear after 5 months or 5 years, and neither will the code that supports them, unless it's so broken that it's prudent to invest in a full rewrite.

Even if a company fails, their products, processes (and code) usually get absorbed by some other company and need to be maintained - startups get acquihires that keep teams but discard products; "normal companies" get M&As that discard headcount but keep product lines, divisions and processes that require lots and lots of running code. The large companies often have multiple "inherited" codebases from all the other companies they have absorbed. And there is a lot of old code running; nothing is as permanent as temporary code - I have seen comments stating "this won't work properly on the boundary between fiscal years, but the system is scheduled to be replaced by then" that were made IIRC 6 years before I was looking at that system, so it obviously did not get replaced back then. In many industries a 10-year old company is a young company; heck, most of the current "internet startup unicorns" are 10, 20 or more years old; in established industries (you do know that the vast majority of software people work in non-software companies, right? most code is written for internal business needs, not sold as a service or product or consulting to others) there is a lot of mature code serving business processes that have been there for decades, will be there for decades, but often have some changes that require also code adaptations. The same goes for all the code that's inside industrial products - in the automotive industry, in home electronics industry, etc; you may have a new model of car every year, but most of the code in that car will be much older than that.

I mean, the trivial fact is that if we look across the whole industry, all the statistics show that the majority of programmer manpower is spent on maintenance. So the total costs of software are dominated by how easy it is to maintain it, and a lot of that comes from proper design that takes into account what the likely needs are going to be after a bunch of years.

Re: OOP Is Dead, Long Live OOP

#134
post #54
post #20

I’d be very wary of hiring an ”OO” dev who can’t reasonably formulate what the SOLID principles are and why they exist.

SOLID is mostly a bunch of over-confidently stated opinions. Here is my over-confidently stated opinion: if a principle is not applicable to Smalltalk 74, it is not essential to OOP. The only rule in SOLID I would say someone should follow at all times is L, and even then only in statically typed languages. This should be obvious . For example, can you define "responsibility" in any way that's not entirely gut feelin…

They’re guidelines and tools. You have to know how and when to use them. There are no unambigous rules in programming beyond what the language itself enforces. But that doesn’t mean some rules aren’t useful. As the saying goes in science: all models are wrong but some of them are useful. Or in art: you have to know the rules before you can break them.

Re: OOP Is Dead, Long Live OOP

#135
post #100

Earlier quoted context omitted.

That presentation basically says "write simple code". I'm not sure how is that helpful to anyone.

It's immensely helpful. Stuck in a rut designing your type hierarchies and making sure they are perfectly SOLID? STOP. Write the simplest, most clear and concise thing that works, refactor it once it gets too big to fit in your head. Not sure if your AbstractFactoryBeanProxyImplImpl is generic enough to cover all use cases? STOP. Write the simplest most clear and concise thing that works, refactor it to adapt to more…

"You Aren't Going To Need It" is the most overlooked piece of advice anyone has ever given anyone.

Re: OOP Is Dead, Long Live OOP

#136
post #117

Earlier quoted context omitted.

How so? I believe I was addressing the fundamentals of OOP: Classes, methods, inheritance, overloading, visibility, etc. Also, Rust, while allowing the assigning of behavior to a type, is explicitly not OOP. Check it's Wikipedia page (which doesn't include OOP in the list of paradigms) and the O'Reilly book (which says Rust isn't OOP).

I didn't mean rust was fundamentally OOP, but that rust implements, through runtime traits, exactly the behavior you are criticizing OOP for. Sorry about that

[deleted]

Re: OOP Is Dead, Long Live OOP

#137

Does anyone know of a good reference for idiomatic OO(P)? Like the Codd paper for Relational Algebra.

If you use a typical IDE that comes with Squeak or VisualWorks, you can quickly inspect a lot of idiomatic code from the standard library. The most common mistake I have seen is that people who know about other programming languages, start looking at OOP as a way to separate and organize code.

Instead, it starts from the other side: OOP is based on a few core concepts, and those concepts are critical to understanding OOP. The first concept is 'Everything is an object', the second might be 'Objects can receive messages'. So if you have some code:

  1 + 2
It means that there is an object '1' which receives a message '+ 2'. If '1' is an Integer, Float, String or whatever might be relevant for its inner workings but if you want to understand OOP you first have to understand the concept-side of it (and ignore the implementation). Once you know the concepts, you can reason about good and bad implementation/code.

You might wonder about the preachy tone, but in the beginning, it took me a few months before I understood that I was trying to understand OOP from the wrong side (at the time I was thinking in C) and I would like others to have a quicker start than I had.

Re: OOP Is Dead, Long Live OOP

#138
"Before you decide that OOP is shit and ECS is great, stop and learn OOD (to know how to use OOP properly) and learn relational (to know how to use ECS properly too)."

This is why DDD needs to be in place before using OOP

Re: OOP Is Dead, Long Live OOP

#139
post #117

Earlier quoted context omitted.

I didn't mean rust was fundamentally OOP, but that rust implements, through runtime traits, exactly the behavior you are criticizing OOP for. Sorry about that

Can you please point out exactly what I said when you say 'the behavior I'm criticizing OOP for'. Haskell typeclasses are very different from OOP inheritance or OOP classes. In any case, I don't see how that relates to the explicit criticisms I made.

> All in all, OOP is a toolkit for building bad abstractions: abstractions that do not easily model computation, that hide data.

That's a fundamental property of type erasure, which is not exclusive to OOP, and far from the extent of what modern OOP is about

Re: OOP Is Dead, Long Live OOP

#140
post #9

If we just had made inheritance as something to be avoided unless absolutely needed then OOP would have probably never got such a bad reputation. All the other concepts make perfect sense.

I've found that inheritance is very useful in one situation, and adds nothing over mixins otherwise. If a class does two broad things simultaneously then inheritance can work great. For example, a User class that inherits from a DB mapper class. I don't want to have to tell my class how to write a record to the DB. All that code can be centralized into one thing and then relied upon for its uniformity across all my m…

> I don't want to have to tell my class how to write a record to the DB

You don’t need inheritance to achieve this.

Your User class contains data and probably some business logic. The fact that it’s going to be persisted in a database at some point is a detail that the class shouldn’t know.

Consider using the data mapper pattern (or an ORM implementing this pattern). In this pattern, your User object doesn’t even know it will be persisted. It doesn’t have any parent class. You just manipulate your entities like a graph of plain objects, and when you have finished you ask the data mapper to persist them. In my experience this is much better than what you are describing, which look like the Active Record pattern.

> If a class does two broad things

Doing this is a violation of one very commonly accepted principle: The single responsibility principle.

Post reply on HN