Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

331–340 of 357 posts

Re: OOP Is Dead, Long Live OOP

#331
post #311

Earlier quoted context omitted.

>>When I read articles complaining about OOP, I just can't relate at all. Most problems start with OOP when people try to take the longest possible path to achieve a goal. Enterprisey code, like having to deal with thousands of classes(AbstractClassFactoryFactorySingletonDispatcherFacadeInitializer types), dependency injection, design pattern abuse. Then on top of this comes things like Spring framework etc. At that…

I feel like this comment is exactly what the article refers to as the typical straw-man argument against OOP. Yes, a lot of bad enterprisey OOP code has been written in the last 20 or so years, but that does not mean things like design patterns, dependency injection and the Spring framework don't have their place. Don't throw the baby out with the bath water. Yes, AbstractClassFactorySingletonWhatever classes do exis…

>>but that does not mean things like design patterns, dependency injection and the Spring framework don't have their place.

Part of the reason why Go has picked up so well, And languages Python and Perl still such widespread use is because many people aren't developing monstrous megalith applications like in the pre-2000's.

You needed all these big complexity management features because people were padding every tiny little feature callable from 'public static void main', then you see there are some very tiny far abstract patterns of code that overlap in such a giant megalith, and then to make use of that you unload the entire design pattern text book to make it happen.

This was totally unnecessary. In fact its perfectly ok to have 5 - 10 % duplicate code if it comes at the expense of simplicity and maintainability of the remainder 95% fo the code.

The overall rise of micro services architecture and those trends are only going to increase this way of developing software.

>>Yes, AbstractClassFactorySingletonWhatever classes do exist in the Spring framework, they are there to help abstract away the complexity and flexibility of the framework so you as the application programmer can have a simple, productive programming environment, and you can still reach into the complexity (and extend it) when you need to.

I'm not sure, but there are other language communities which solve the same problem without writing 30 classes just to do variable++

>>Beans, interface inheritance, implementation inheritance and dependency injection are the building blocks of a programming environment that allows me to be very productive, and still write maintainable, testable, extendable and configurable code.

Yet to see such an environment.

It feels like Java community programmers create tons of complexity and then tons of complex frameworks to solve that complexity that shouldn't even exist at the first place.

Re: OOP Is Dead, Long Live OOP

#332

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

Practical Object-Oriented Design in Ruby by Sandi Metz

Don't worry about the "in Ruby" part, it's just as good even if you know nothing of Ruby. I enjoyed it and have never written a line of Ruby in my life :)

Re: OOP Is Dead, Long Live OOP

#333
post #316

Earlier quoted context omitted.

> my view on OOP (let OOP denote class based OOP as found in Java or C++) Maybe you should take a look at a real OOP language like Smalltalk before you tell us why OOP is a bad idea. Otherwise, I might tell you why consumers will never adopt cars as I drove a Trabant once.

Did you read the stuff between the parentheses?

In fact, I did. But I think it is wrong to judge OOP based on crude implementations. That is the reason why I added the Trabant example:

> The Trabant was loud, slow, poorly designed, badly built, inhospitable to drive, uncomfortable, confusing and inconvenient. (source: https://en.wikipedia.org/wiki/Trabant)

Java and C++ are both great tools for specific jobs, but from an OOP perspective, they are badly designed. So if you want to discuss OOP as a design choice, it would be unreasonable to discuss it based on those poor implementations. Smalltalk, on the other hand, has its own set of problems, but a poor OOP implementation is not part of it.

Re: OOP Is Dead, Long Live OOP

#334

Earlier quoted context omitted.

> Except for the fact that objects can be serialized and ORM's exist to convert your data into OOP. How do you think Entity Framework works? How do you think Rails works? You can build almost an entire ORM from a database without even writing any code in Entity Framework. That was actually sort of my point. You need all of this extra stuff _because_ your code is all objects. Data doesn't get serialised, data just get…

>Maps can be represented 1:1 as e.g. JSON. Any JSON data is basically a big map data structure. It's one function call instead of hours of writing ORM classes or custom serialisation methods just to send some data over a wire Again, you don't write the ORM classes, the framework does it for you. And what you advocate is essentially sending a table over the network. So, what happens if your data within that map is com…

And now you have to rely on a framework, where there's more opportunity for leaky abstractions, more surface area where bugs can show up.

I'm not sure what you mean by complex data - data is data, and using a serial format like edn allows you to encode a lot of different stuff as data - even functions. I think you're stuck in the oo mode where you're passing around objects and classes instead of just data. Data is so much easier to deal with!

Re: OOP Is Dead, Long Live OOP

#335
post #311

Earlier quoted context omitted.

I don't understand what the problem with OOP is. My OOP code has always been clean and easy for myself and other people to read and modify. When I read articles complaining about OOP, I just can't relate at all. The idea of functional programming makes no sense to me except for writing very specific simple programs. For example, I like using some functional programming on the front end with VueJS but even there, I st…

>>When I read articles complaining about OOP, I just can't relate at all. Most problems start with OOP when people try to take the longest possible path to achieve a goal. Enterprisey code, like having to deal with thousands of classes(AbstractClassFactoryFactorySingletonDispatcherFacadeInitializer types), dependency injection, design pattern abuse. Then on top of this comes things like Spring framework etc. At that…

One argument that I often don't see mentioned when talking about OOP code, especially the admittedly awful enterprise type, is that this style of coding is happening for a reason.

I think the reason is this: you have a large sprawling codebase, consisting of tens of thousands of 'business rules' or more, and you have to find a way to allow cheap run of the mill programmers to make changes to those business rules in an approachable manner.

I don't think it's fair to evaluate enterprise OOP code based on the style you would prefer when undertaking a standalone project, even a large one, when one of the very problems that this enterprise style is trying to solve is how to have hundreds of fairly green developers work on the codebase.

Now, as an exercise imagine taking this social problem I've described above, and implementing it in your favourite programming style, be it lisp/scheme, functional programming, JS or whatever you prefer, and try to honestly imagine whether it would hold up any better under those conditions.

Re: OOP Is Dead, Long Live OOP

#336
post #311

Earlier quoted context omitted.

>>When I read articles complaining about OOP, I just can't relate at all. Most problems start with OOP when people try to take the longest possible path to achieve a goal. Enterprisey code, like having to deal with thousands of classes(AbstractClassFactoryFactorySingletonDispatcherFacadeInitializer types), dependency injection, design pattern abuse. Then on top of this comes things like Spring framework etc. At that…

One argument that I often don't see mentioned when talking about OOP code, especially the admittedly awful enterprise type, is that this style of coding is happening for a reason. I think the reason is this: you have a large sprawling codebase, consisting of tens of thousands of 'business rules' or more, and you have to find a way to allow cheap run of the mill programmers to make changes to those business rules in a…

Do you mean that in order to allow green programmers to change big codebases you make the code more complex? I honestly don't understand.

Re: OOP Is Dead, Long Live OOP

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

Or… if you're talking about languages like C# and Java (and presumably C++), just make sure all of your classes are either sealed or abstract. This turns classes into proper algebraic data types. To wit, implementation inheritance gives you a sum type (e.g. a Shape is either a Circle, or a Square, or …) whereas interface inheritance gives you a product type (class Foo : IBar, IBaz means that Foo is an IBar and an IBa…

Nice idea, but without match expressions (checked by the compiler) it’s just not as good as a true FP language.

Re: OOP Is Dead, Long Live OOP

#338
post #336

Earlier quoted context omitted.

One argument that I often don't see mentioned when talking about OOP code, especially the admittedly awful enterprise type, is that this style of coding is happening for a reason. I think the reason is this: you have a large sprawling codebase, consisting of tens of thousands of 'business rules' or more, and you have to find a way to allow cheap run of the mill programmers to make changes to those business rules in a…

Do you mean that in order to allow green programmers to change big codebases you make the code more complex? I honestly don't understand.

Sorry not quite, I believe that people use OOP in enterprise settings perhaps thinking:

* Encapsulation might make it safer for programmers to modify code without affecting other areas.

* Inheritance will make it easier to set standards for large numbers of high turnover programmers.

and that then it grows complex for various mostly social factors.

The testable hypothesis in this is that if you started with another programming model, and applied the same social pressures to it, it would end up just as ugly and complex.

These codebases have hordes of programmers banging away on them, with little regard for the bigger picture which makes the code ugly and inconsistent.[1]

Architects then react to this and attempt to enforce standards by introducing patterns and subclasses and facades etc, which is what makes it complex.

Basically, I'm saying that the main straw-man used to argue against OOP: the enterprise codebase is chosen for the wrong reasons.

Put any other programming style under the same pressures and you'll end up with a similar big ball of mud.

[1] https://en.wikipedia.org/wiki/Tragedy_of_the_commons

Re: OOP Is Dead, Long Live OOP

#339

Earlier quoted context omitted.

Duck typing is the worst of all worlds, in my experience. And in defense of inheritance, the Liskov Substitution Principle is extremely useful and makes a lot of sense. If a function accepts a `Weapon` as parameter, surely you should be able to pass it a `Sword`.

Except Firearms require the reload() method be called periodically between calls to use(). So now we have to think about whether Swords need an empty reload() method or whether there need to be separate Firearms and Blade interfaces based on Weapon.

Yup, that's how it works. And why inheritance and polymorphism is so popular: it's powerful, easy to explain, and captures elegantly a lot of problems we need to model.

In contrast, non class based languages such as Haskell struggle to model problems that are trivial in OOP, such as how to reuse 90% of existing functionality but override 10% with more specialized behavior. Good luck solving that problem elegantly with type classes.

Re: OOP Is Dead, Long Live OOP

#340

Earlier quoted context omitted.

> The fact the the original code is a straw-man is discussed. Yes, but instead of timing it against the improvements the grand-author made to the straw man, you still timed it against his straw man. So I'll quote you: "You need to work on your speed reading skills before throwing shade..." > The fact the flexibility is being removed is discussed too You state: "Why do these frameworks exist then? Well to be fair, the…

Calm your titties my dude, you're angrier than me, here... You're still missing my point, claiming I'm making points I'm not, and insulting me for it. Grab a handful of good faith, please. I timed it against the bad starting point because that's what Aras did too when showing that "ECS beats OOP by 10x". My version wasn't designed to be optimised - it was designed to be a simple rule abiding OOP rewrite. The point of…

Welcome to HN! (I'm a moderator here.) Please stick to civil, substantive comments, regardless of how wrong someone else is (or you feel they are). Swipes like "calm your titties" (or even telling people to "work on their reading skills", as you did upthread) are the sort of thing we ban accounts for. We're trying hard to prevent this place from sinking into a toxic swamp, as so much of the internet has become. Doom is probably inevitable in the long run, but we're still hoping to stave it off for a while.

If you'd please read https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here, we'd appreciate it.

Post reply on HN