As the submitter, I want to point out that I submitted this post with the original title. The one that makes it clear a16z are behind the social media astroturfing. The mods changed the title.
Readit Newsgrahamlee commented on A Remarkable Assertion from A16Z nealstephenson.substack.c... · Posted by u/boplicity
In these modern times of ours, the word literally has taken on a new meaning, which is "not literally but with emphasis." This seems like the most likely explanation.
These modern times that literally began in 1769. Oxford English Dictionary, “literally (adv.), sense I.1.c,” June 2025, https://doi.org/10.1093/OED/9189024563.
grahamlee commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve
The fact that Java had to add a whole extra set of keywords to control this indicates that this is a site of complexity. Since it isn't needed for composition, it's a site of unnecessary complexity.
What you lose by using composition is that the composing object is no longer a subtype of the constituent object, so you can't use it as a "decoration" of the original object in a program that expects an instance of the original.
grahamlee commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve
"Composition" is a word that can mean several things, and without having read the original source I never really understood which version they mean. As a rule, I've always viewed "composition" as "gluing together things that don't know necessarily know about each other", and that definition works well enough, but that doesn't necessarily eliminate inheritance.
So then I start thinking in less-useful, more abstract definitions, like "inheritance is vertical, composition is horizontal", but of course that doesn't really mean anything.
And at some point, it seems like I just end up defining "composition" to mean "gluing together in a way that's not inheritance". Again, not really a useful definition.
Article author here. Your idea "gluing together things that don't know necessarily know about each other" is basically what the GoF book means: composition is "this object has a reference to that object and uses its public API". They don't mean "this object ontologically contains an instance of that object" in the sense that a car "has" an engine, which is a narrower definition of composition that people frequently use.
It's that broader version of composition—particularly in its extreme realization, delegation—that underlies a lot of the behavioral patterns in the book. For example, the State and Strategy patterns boil down to "this object relies on another object to fill in the behavior here, and there are ways to choose what that other object is", which is something it's easy to arrange with subclassing and the only point of the pattern is to avoid subclassing.
grahamlee commented on When did people favor composition over inheritance? sicpers.info/2025/11/when... · Posted by u/ingve
An important point not mentioned by the article is that of "co-recursion" with inheritance (of implementation).
That is: an instance of a subclass calls a method defined on a parent class, which in turn may call a method that's been overridden by the subclass (or even another sub-subclass in the hierarchy) and that one in turn may call another parent method, and so on. It can easily become a pinball of calls around the hierarchy.
Add to that the fact that "objects" have state, and each class in the hierarchy may add more state, and modify state declared on parents. Perfect combinatory explosion of state and control-flow complexity.
I've seen this scenario way too many times in projects, and worse thing is: many developers think it's fine... and are even proud of navigating such a mess. Heck, many popular "frameworks" encourage this.
Basically: every time you modify a class, you must review the inner implementation of all other classes in the hierarchy, and call paths to ensure your change is safe. That's a horrendous way to write software, against the most basic principles of modularity and low coupling.
Author here. I wrote “ But even a modestly more recent language like Java has visibility attributes that let a class control what its subtypes can view or change, meaning that any modification in a subclass can be designed before we even know that a subtype is needed.” which covers your situation: if you need to ensure that subtypes use the supertype’s behaviour in limited ways, use the visibility modifiers and `final` modifier to impose those limits.
Damn this is a blast from the past - it was such an ambitious project with so many interesting ideas to explore. CoreObject itself was revolutionary in its thinking about distributed document sharing and versioning, let alone some of desktop environment ideas for managing projects.
I know Quentin Mathé, kept CoreObject going for a decade longer, but I haven't heard from the rest of those involved for a very long time.
David Chisnall is now at MS Research and does cool things with CHERI making a computing platform that's memory-safe by default.
Stray thought: Why 4 and 9? Because the joke is funniest if the number is completely ordinary.
0 and 1 are special and so are all prime numbers. 6 is out because it's the maximum die throw. And one figure is more ordinary than two figures, or negatives, or decimals. That leaves 4 and 9.
That makes 4 and 9 the only two uninteresting numbers, which is interesting, so they’re out too!
Douglas Adams said the same about 42. It’s the answer because it’s completely banal.
Edit: The community has spoken and I've come up with a way to include a16z in the title whilst keeping it under 80 chars.