The Big OOPs: Anatomy of a Thirty-Five Year Mistake

1. You have entities, which may just be identifiers (maybe a u64 used as an index elsewhere) or some more complex object.

2. You have components, which are the real "meat and potatoes" of things. These are the properties or traits of an entity, the specifics depend on your application. For a video game or physics simulator it might be velocity and position vectors.

3. Each entity is associated with 0 or more components.

4. These associations are dynamic.

5. You have systems which operate on some subset of entities based on some constraints. A simple constraint might be "all entities with position and velocity components". Objects lacking those would not be important to a physics system.

In effect, with ECS you create in-memory, hopefully efficient, relational databases of system state. The association with different components allows for dynamically giving entities properties. The systems determine the evolution of the state by changing components, associating entities with components, and disassociating entities from components.

The technical details on how to do this efficiently can get interesting.

Compared to more typical OO (exaggerated for effect), instead of constructing a class which has a bunch of properties (say implements some combination of interfaces) and manually mixing and matching like:

  Wizard: Player
  FlyingWizard: Wizard, Flying
  FlameproofWizard: Wizard, Flameproof
  FlyingFlameproofWizard: Wizard, Flameproof, Flying

Or creating a bunch of traits inside a god object version of the Wizard or Player class to account for all conceivable traits (most of which are unused at any given time), you use the dynamic association of an entity with Wizard, Flying, and Flameproof components.

So your party enters the third floor of a wooden structure and your Wizard (a component associated with an entity) casts "Fly" and "Protection from Elements" on himself. These associate the entity with the Flying and Flameproof components (and potentially others). Now when fireball is cast and the wizard is in the affected area, he'll be ignored (by virtue of being Flameproof) while everything around him catches fire, and when the wooden floor burns away the physics engine will leave him floating rather than falling like his poor non-flying, currently on fire Fighter compatriot.

I complained a lot about OOP all throughout my 25 years a developer. I wrote a ton of C++ and then Java and nobody can refute my expertise with those languages. I saw so many people make mistakes using them, particularly with forcing taxonomies into situations that weren't conducive to having them. Then, when I began complaining to my colleagues about my feelings, I was ostracized and accused of "not having a strong enough skillset." In other words, the dogma of the time overrode the Cassandras saying that the emperor had no clothes. Meanwhile, the simple nature of C and even scripting languages was considered out date. The software dev community finally realized how bad things had gotten with Java and then the walls came a tumbling down. I far prefer writing non-OO Python (or minimal use of classes) to anything else these days. I went all around the language world--did projects involving Lua, Clojure, tons of Groovy, then moved on to Functional Java, Kotlin, and Golang.

The main issue I have with Java is that the JVM was built to be portable and then we got a superior kind of portability using containers, which makes the JVM totally redundant and yet whenever I point that out, I get funny looks from people!

I guess I have a lot of other problems with Java--jar hell, of course, but also the total inability for corporations to update their junk to newer versions of Java because so many libraries and products were never kept up with and then you get security people breathing down your neck to update the JVM which was LITERALLY IMPOSSIBLE in at least two situations I became involved with. We even tried to take over 3rd party libraries and rewrite/update them and ended up at very expensive dead ends with those efforts. Then, to top it all off, being accused of lacking the skill and experience to fix the problem! Those a-holes had no idea what THEY were talking about. But in corporate America, making intelligent and well-documented arguments is nothing. That's when I finally decided I needed to just stop working on anything related to Java entirely. So after about 15 years of that crap, I said no more. But I'm the under-skilled one.

No. Functional programming is quite a bit more involved than just writing "functions"--it is taking advantage of the fact that functions are first-class "objects" that can be passed as arguments to other functions, which allows for a far more intuitive and flexible form of programming. But FP is even more than that.

> programming is closer to math, not linguistics

It's worth pointing out that actual linguistics is not unlike maths, e.g.: https://en.wikipedia.org/wiki/Formal_grammar, https://en.wikipedia.org/wiki/X-bar_theory, etc. There's an awful lot of vibes-and-feels nonsense about language in the popular press, which one ought not confuse with linguistics proper.

In fact, as Casey mentions in this talk, a lot of the earliest ideas in software architecture came from trying to parse languages - both human and computer.