Comment by koonsolo | Hacker News Reader

Comment by koonsolo | Hacker News Reader

Parent Full thread

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