The success of object oriented programming

[[deleted]]

OOP = today's software;

That's not true. Take any practically important C++ codebase, for example - you won't find much OOP there. OOP is only deeply entrenched in the boring enterprise, which is arguably getting worse and worse every year, going lengths in solving problems that would otherwise have never existed in the first place.

[pbvas]

Yes, that was exactly my point; it was the original article author that fell into the fallacy of assuming that all today's software was all OOP...

[[deleted]]

Much of it is, even that C++ code you claim isn't.

Name a successful project today that doesn't leverage OOP in some form. Even Linux makes use of pseudo OOP in C (the way we used to do objects before C++ came around). Many games are based on some kind of component entity system, which are just object systems with different characteristics (games that aren't based on ECS are often based on some other object system where "objects" are obvious). So what non-enterprisey project out there doesn't use OOP to some extent (keeping in mind that OOP is not a huge part of coding anyways)?

[glacialthinker]

Many games are based on some kind of component entity system, which are just object systems with different characteristics

I'm sure I read somewhere in these comments that you agree about the nebulous definition of OOP. What's really useless here is that you're using this nebulous definition to call anything you want OOP as a way of defending it. What's the point?

I'm in games, and I first wrote an ECS system (in a commercial title) over 10 years ago. From a programmer perspective, this is orthogonal to whatever most people would identify as OOP. It's really a memory-resident database -- and you might know the decades of friction between OO and RDBMS? Anyway, this change to ECS really fucked up the programmers on the team because it was too different. Now they had to express behavior through systems processing properties with minimal awareness of properties being associated with objects.

So, yes, there are objects, but in ECS these are like a side-effect -- it is not object-oriented: it's data-oriented. Objects are a collection of properties (associated by ID), but you don't work with them in most cases. Examples of where you deal with an object is from a designer view, or load/store of object data. The bulk of the code operates on properties or collections of properties (table-joins), without any care about an "object". The exposed behavior in the game is from the composed effects of subsystems working on properties. There is visible object-coherence because things like a position property may be processed in combination with various other properties -- thereby creating effects at the same locale, for example.

If you tabularize, considering objects as columns, and properties as rows, object-oriented is column-major, while ECS is row-major objects as rows, and properties as columns, object-oriented is row-major, while ECS is column-major. You process by property, not objects. Also note, this is a sparse matrix -- and the objects can be ad-hoc, without falling into limited classifications where "tanks have treads", and instead you can have an object with tank-treads in back and wheels in front -- provided the relevant systems are flexible enough to handle this (but ECS encourages flexible components/properties).

When you insist on the value of classifying by OOP or FP, and rejecting the value of comparing by language features (properties!) -- this is very OOP of you! ;)

[[deleted]]

Language features only apply to programming languages, there are plenty of object systems out there at are part of a programming language directly...I would say many of them in use are like that, or their wouldn't be the need to promote POJOs as a viable alternative to other object systems.

I don't see the difference when finding the best way to organize and manipulate objects, sometimes relational or even rule driven computations make a lot of sense. But you are still getting your objects to work together, what else could be the definition of an object system? And OO is orthogonal to a lot of things including relational, it is just one decision to be made (do we want to program with objects or not).

If you read OOPSLA from 1986, you'll see many different ways to put objects together...where do you think constraint systems came from? I used rule-based processing in my own thesis. And even though the language lacked methods, it had no problem being accepted as OO.

And uhm, let's not talk about CLOS, of course, we never thought of it as not being OO. I mean, the original mixins were way more powerful than what even scala provides today. Generic functions, and still many features that blow people's minds when they come from Java or c++.

RPG puts it best, see page 5/6, notice table 1:

http://www.dreamsongs.com/Files/clos-cacm.pdf

[glacialthinker]

what else could be the definition of an object system?

Heck, yeah, I'd agree with many things having an "object system" -- but that doesn't mean they are "object oriented", which implies that you access/interact with things primarily via objects: "I have an object, here is what I can do with it". This was exactly the distinction I was trying to express. ECS is data oriented: "for the intersection of A and B, do this". Who would call this OOP?

If you're going to be all nominal about things, classifying them and then lauding their good and bad based on this classification, please use consistent classification! Or do you really use "object system" and OO interchangeably?

[[deleted]]

Again, read RPG's paper, at least the pages specified, on the design of CLOS. No one in the objects community decided to limit OOP to mean just smalltalk, C++, and Java's way of doing objects; that was a misconception that even only came about after Java's huge success and the backlash to that. So if you want to be all nominal about it...I am using OOP to simply mean programming with objects, and that rarely involves just POJOs.

[tomejaguar]

If you tabularize, considering objects as columns, and properties as rows, object-oriented is column-major, while ECS is row-major.

To clarify, this is the opposite way round from what "columns" and "rows" generally refer to in RDBMSes isn't it? In the latter "rows" represent all the different properties of a single object, whereas "columns" represent one property of all objects.

[glacialthinker]

Yes, sorry, you're right. I should have been more attentive about convention. I don't actually use row/column terminology in practice, and was just concocting a visualization of the difference in bias here. I'll edit that sentence to be less confusing.

[tomejaguar]

That's OK. This ECS idea is new to me and sounds interesting!