On Friday, 24 June 2022 at 01:59:07 UTC, forkit wrote:

I once took a course that had the book «Computers in Context: The Philosophy and Practice of System Design» in the curriculum, which looks at systems development from the angle of a philsopher and a system development angle. Sadly, I don’t remember what it said about objects.

But yes, both objects and class hierarchies are reflections of human thought processes. Functions too, and math. Mathematicians talk of «mathematical objects».

On Friday, 24 June 2022 at 13:48:35 UTC, Zoadian wrote:

What you are describing is not the nature of OO-modelling, but the consequences of people not knowing what they are doing, using the wrong implementation strategy, tooling etc.

Objects are appropriate also in real time systems. Actors are objects on steroids and represents one valid approach to creating reliable real time systems. Coroutines have a strong relationship to objects and greatly reduces bug inducing tedium of creating state machines, again an improvement for real time systems if used by a critical thinker. Objects also makes it easier to create transactional systems that allows you to roll back, again a reliability advantage.

No matter what domain you are in, if you deal with uncertainty then also you need a proven methodology and tools that suits the application domain you are working with. With no proven methodology, especially geared towards what you are doing, quality will become less predictable.

If you have no need to maintain state modelling the environment, then of course, you would also not need objects and can choose dedicated tools with 100% verification of the implementation. Is that better? Yes clearly, when you can get away with it.

The OP is relevant to D, because how people thing about objects and their representation affects language design and usage. You confirmed this yourself by stating that you dislike OOP because people are idiots and mess things up (which is the only reasonable interpretation of what you stated). But that is not a consequence of OO-modelling as a concept. It is a result of poor modelling or poor implementation or poor tooling.

What's your use case? without this answer, object has no meaning

Programming computers have no concept of "objects", it is pure programmer's religion, something sold by scholars and forgotten companies to produce cheap engineers

Unity is back to data oriented design because "objects" was found to be inefficient

D doesn't need them, metaprogramming, struct, function is all we need, it's our strength, and we should capitalize on that, and show the world that if they need alternative to "objects, they can find the right tools with D!

Instead of sticking to C# or coming up with a new language HPC# and a new compiler "Burst", Unity should have picked D long time ago, i still try to lobby for them to add support for proper C FFI, so we can properly use D there, but it's hard..

On Friday, 24 June 2022 at 14:11:51 UTC, Ola Fosheim Grøstad wrote:

I'm not claiming objects are generally bad. But OOP in general is a bad design strategy if you want efficient programs. objects bundle too many different variables together, so cache access is most certainly suboptimal. multithreading is another thing that's much harder to do when you start with an OOP model in mind.
All these problems can be solved, at least to some extend, but IMHO it's not a good strategy for implementation. it's fine to model a system as OOP at first, restructure it to something more performant.
But I don't think i have to reiterate the points against OOP here, there are numerous articles on the internet talking about it.
Just to give you one example of a hilariously bad OOP implementation where you'd expect them to know better: chromium.

On Friday, 24 June 2022 at 14:30:05 UTC, ryuukk_ wrote:

Sure, although I guess forkit means that we cannot avoid modelling in terms of objects (or classes) as the human brain is essentially a rather slow abstraction machine that to a large extent has a tendency to create broad sterotypes of what is needed to understand the real world (or in the case of simulation or game, a fictional world). Stereotypes ≈ classes.

I would rather say, whenever you encapsulate something you have a defacto object.

Even in a relational database you have entities, which are corresponding to objects (you can also group them as classes). Those table entries for entities (keys) are defacto object representations.

I don't see a contradiction between object-oriented-modelling, component-based-modelling or entity-relationship modelling, I view it as facets of the same. You can mix. The more modelling knowledge you have, the more cogntitive aids you have, the more likely you are to arrive at a good model. Then you can choose an implementation strategy that suits your use case (one important decision factor is whether you believe that the model has to change later or not).

What is certain is that you need a model of the world you want to represent, be it the real world or a gaming world. And a strategy to represent it your chosen language/database.

Ok, so when you design a framework for others to use, and don't want them to know the inner workings of the framework, then you are willing to pay a rather high efficiency price to begin with. OO-models do not require you to put everything in the same record though. You can split off physics in a game from avatar and soforth.

Also, component based design, which decouples entities by giving them identities (e.g. a number) instead of using the address, has some advantages over using pointers; you can more easily split the system and distribute it over many computers for instance. And if you create many similar systems, then it can make some reuse cases easier as you only deal with an integer-id. But it has a price. In terms of efficiency it can become worse or it can become better… it all depends on wether the decoupling makes sense or not.

But the key point is that you don't have to choose between classic OO implementation or components. You can mix.

Well, but surely structs would be more intuitive to use if they could inherit rather than using alias this? Even if you never go further than one level of inheritance, it is still beneficial. E.g. have one abstract Node struct that takes care of book-keeping and a bunch of structs that inherit from the Node that does the real work that your game cares about. Many ADT implementations use this strategy, and it is OOP. You can use other strategies, but they tend to become clunky and/or verbose.

(I would also argue that template composition can be viewed as a form of object-model implementation, btw)

Unity sound like fun, I don't know much about it, unfortunately. But I agree that it sounds better to build a game with D than C#.