drainyard

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. :)

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.

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.

If that is what you are saying, that is nonsense.

I would argue that a business domain is defined by it's data and how that data is transformed and displayed based on user input.

So simply put: 1. Data goes into system 2. Data is displayed to user 3. User interacts with data (button, CLI etc.) 4. Data is transformed based on interaction

That is ALL a program ever is. So you can model a program by just specifying the transformations that happen on each user interaction.

This can be optimized heavily if each interaction requires a large set of data to be transformed, e.g. through data oriented design you can work on big sets of data based on previous interactions and transformations and only work on data you need to work on.

It's not a design pattern. It's just a way of thinking about programs as what they are. A design pattern is something you put on top of data because you want a human understanding of business logic.

This talk by Mike Acton (Formerly Insomniac now Unity): https://www.youtube.com/watch?v=rX0ItVEVjHc

I recommend this talk all the time, since it is the one that got me convinced to look into DoD seriously.

Also: More Mike Acton (now at Unity): https://www.youtube.com/watch?v=p65Yt20pw0g

Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design”: https://www.youtube.com/watch?v=yy8jQgmhbAU

Overwatch Gameplay Architecture and Netcode (More specifically about ECS): https://www.youtube.com/watch?v=W3aieHjyNvw

The main argument is that you work with data so you should care about data. All a program does is take some input, do something with it, and give you an output. If you structure your program around this mindset, a lot of problems become much simpler. Concurrency is one thing that becomes much simpler to reason about now that you understand how your data is managed and moved around. Realisations that most of the time you have multiple of something and very rarely do you have a single thing. So having a lot of small objects of the same type each doing some work within their deep call-stack, rather than running through an array of them and doing the work you need to do.

I disagree that encapsulation is a brilliant idea _in general_, because it promotes hiding data, and hiding data is not inherently good. There's obviously cases, where there is internally critical, but since all your state is simply tables of data, your program is just choosing to represent that data in some way, which can make it easier to centralize a bug early.

There's obviously pros and cons, but I don't think you should discount the possibility of it being a good idea just because it questions ideas that seem standard.

They take what they are given, and engineer a solution that fits that piece of hardware as well as possible. No bullshit FactoryManagerFactory.

It's easy to try something new all the time, but it is tough as nails to stay with something even in the many cases where it sucks and gets difficult. Finishing something is it's own reward though, so even though it's tough it's always worth it.

Here in Denmark we have a nice services where you can cancel your order or reorder every week, but I never know how much time I have at the beginning of the week.

A lot of applications, such as video games, don't require the type of security others do, but require performance to a much higher degree.

Rust is a good middle-ground, since it does have some compile-time issues at the moment still which are getting better. But it is incredibly stingy about anything unsafe. Even unsafe blocks of code are borrow-checked.

Considering how slowly things run these days on any OS, and OS's specifically having performance issues, I doubt the user experience will benefit from a completely managed OS either, but I'm no expert.

Personally, at this point the way I write software is so far removed from this discussion that I just do what feels right and what people can generally agree on within my teams. Solve the problem, don't discuss code, discuss solving the actual problem.

code::dive conference 2014 - Scott Meyers: Cpu Caches and Why You Care: https://www.youtube.com/watch?v=WDIkqP4JbkE

CppCon 2014: Mike Acton "Data-Oriented Design and C++": https://www.youtube.com/watch?v=rX0ItVEVjHc

They're mostly about C++ and cache aware/data oriented programming.