Comment by koonsolo | Hacker News Reader

Comment by koonsolo | Hacker News Reader

I'm getting sick an tired of all these OOP bashing articles.

X is terrible, Y is super! Fact is that everything has benefits and drawbacks, and so does OOP, Functional programming or whatever.

The strength about OOP is that it's practically the best to program most software. If you look for example at the SDL library written in C, it uses an OOP interface with handles to keep things nice and simple. Yeah that's right, OOP in C, why would anyone do that? Because it has benefits, that's why.

So why is most software nowadays written in OOP? Because it has the most benefits. You can sure find examples where functional programming would be better, but they are a minority.

So yeah, next time I would expect an article to properly make a comparison between benefits and drawbacks of both things that are compared. Not the usual "all drawbacks of X, but look at all benefits of Y". This kind of thing screams "Junior alert" to me.

Meantime, I'm developing my apps and games and applications in OOP, and absolutely loving it. Wouldn't trade it for anything else in the world.

SDL having an interface with handles has nothing to do with OOP and is simply the concept of opaque handles. This is often seen in data-oriented code bases where a system behind the scenes is dealing with transforming data in a hardware-oriented and cache optimized manner.

Sure the article isn't super well-written, but it raises a fair point and shouldn't just be thrown away. Just because something is the most used or standard does not mean it is the best solution. Eating junk food is very common, but you would hardly argue that it is the best way for a human to get nutrients.

You can use OOP all you want, and it's fair to say that the article should have been less biased (though he has a disclaimer that says he is biased), but there is nothing suggesting that OOP is practically the best paradigm to program most software other than the fact that it is the most used.

There is no doubt that using handles like that takes concepts the same like OOP, such as constructor, encapsulation, object methods, etc. Therefore moving this API interface to OOP would mean a straightforward 1-on-1 mapping. Claiming this has no relation to an OOP setup is therefore not correct. It would have had the exact same interface if it was written in OOP.

Maybe we are talking next to each other about what a good programming language is. For me as a professional programmer, it means to sell value. This implies that the companies I work for can make the most amount of revenue. Thanks to free market forces, we can assume that the most "optimal" programming languages survive. Remark that "optimal" is not expressed in terms of aesthetics or whatever, but is purely the productivity of generating money.

You can indeed claim that fast food is not healthy, but from a business perspective, it is a success story, and therefore also popular. I don't know how "healthy" OOP is, but it is hard to argue that it is not a business success story. And that is exactly what I offer to my clients.

Edit: And to be honest, I would have no clue how I could make the business case for any of the projects I ever worked on for not using OOP. These include games, consumer mobile apps, robotics and various business applications (smart client-server, etc).

Fair enough with that argument you can say it has a relation. I think what I was trying to say was that I don't necessarily think the authors of SDL were inspired by OOP when designing this type of interface.

Maybe we are talking next to each other about what a good programming language is.

Yes, I think we are at least in a sense. If we are speaking about programming languages from a business perspective we can agree that the language leading to the most productivity will - in a business sense - be the most optimal. I think my point is we have been productive in spite of OOP and not because of it. OOP here meaning the way it has been since Java and not Alan Kay's original ideas. When something like OOP becomes ingrained in an industry like it has been in software development in both the business and in academia, I'm not sure just waiting on the free market is going to do us any good if we (i.e. me) want to change it. Personally I am vastly more productive in the non-OOP code-bases I have worked in as opposed to the opposite. This is a personal bias, but I am no the only one and there is a growing movement of moving away from it and often already completely gone away from it. So it's not just a case of the grass being greener.

I assume you are more senior than me, since I am not particularly senior, so you can again write it off as me being a junior. But it's a growing paradigm shift, especially in game and game engine development, which is what I do for a living.

Senior also means that I built up a certain way of reasoning and avoiding or working around common problems. So I might not be the best person to push a new paradigm shift ;).

You got me intrigued about being less productive in OOP. Can you share what exactly you are working on? My first guess would be that it has something to do with concurrency or parallelism? It especially interests me since it's game development :).

Senior also means that I built up a certain way of reasoning and avoiding or working around common problems

I see this in my current senior colleagues, who may be very OOP-oriented but they are incredibly productive because they are super experienced in their field and in the code-base. I 100% respect that type of seniority of course, because I have learned a lot from my seniors.

Regarding my productivity I think it is first and foremost related to how my brain solves problems. I especially like the idea of Data-Oriented Design, because I think of solving programming problems as three simple steps: 1. Some data comes in 2. Data needs to be transformed into something else (based on some business rules) 3. Data needs to be presented

So when I want to solve a problem I first define my data, then I define my transformation functions and then where they are used afterwards. It's not necessarily a purely functional approach, since they do change state as opposed to returning new state, but it has very little overhead in my brain. And as you mention concurrency, it simplifies it vastly because you usually know exactly who is using which data where.

I work mostly on engine development, so there's a lot of room for optimization and understanding how a lot of data is transformed every frame, which makes performance a super interesting topic for me. I can reason much more easily about performance in a procedural code-base than in an OOP code-base, so that might be part of my bias. :)

Reply on news.ycombinator.com