I've noticed OO education has a habit of appropriating every good idea from software engineering as if it was a distinctive feature of OO approach. I think reading SICP opened my eyes to that for the first time. As it turns out, you can do abstraction without objects just fine.

What OO education? I find that people just fling around random tenants when they talk about OO, even worse when they talk about FP. Even crazier is when some darling FP technique like entity component systems specifically use a synonym for object (entity) to avoid being called OO.

> I was taught that there were 4 tenents

> I find that people just fling around random tenants

It's tenets. TENETS.

Please do not fling around random tenants! We'll have to re-plaster the walls again!

Sorry, my post is too old to edit. I did get a nice chuckle out of this, though.

Entity Component Systems is an FP technique now? That's new to me.

ECS is one of the bigger confusion of ideas out there. The articles about it tend to mix together at least three of the following, each in different proportions, and without realizing it: composition over inheritance, relational data model and SoA/data-local design.

IMHO, the relational data model is the more fundamental part of ECS. Struct-of-arrays is a bit lower-level of a view on the same (with more emphasis on performance and less on architecture), and composition-over-inheritance shows up elsewhere (although the mechanism for composition is _not_ at the language level, where most people expect it to be).

Once you have the relational model, the Systems part of an ECS architecture almost defines itself as you figure out how to work with your data.

But entities really are not objects, because they neither send nor receive messages, and because they have no associated data (and therefore no encapsulation). In fact, the component-system relationship encourages you to break encapsulation.

OO is just programming with objects, regardless of how you coordinate them. Encapsulation is a multi dimensional thing, ECS just favors one form of encapsulation over another.

I'm not a fan of that as a definition: To me, object-orientation means modelling computation as communication between stateful objects. An object-oriented programming language has features that facilitate such a design. Inheritance would be such a feature, but it could easily be substituted with other ways of subtyping and code reuse.

Absolutely. Tight coupling between data set instance and function that manipulates this data seems to be the current definition of object-orientation (as opposed to something more philosophical like "living entities communicating together", which is a bit vague IMHO).

Rather than having one big memory chunk, and one big function chunk (like the old DATA DIVISION and PROCEDURE DIVISION of cobol), you divide thoses into smaller data+procedure bits that idealy map to existing concepts from your domain.

That seems like a much more effective way of seeing the thing. Although once you start adding parallelism and asynchronous communication, you do probably end-up in something closer to the Kay definition.

Isn't abstraction a tenet of every programming paradigm?