OOP: 35-year mistake

via Julia Zulip

Some takeaways:

• I like the distinction of “omniscient” vs more strictly encapsulated. One, it clarifies why some of my thoughts on relation-y/graph-y stuff might not translate easily to distributed networks. Two, what’s so bad about omniscience anyways? If you can have access to more information, isn’t it almost always better to have the option? This applies both to encapsulation and also stuff like interfaces or traits or public/private. I know when I first started learning about these kinds of things I was inclined to narrow things down to the most specific, restrictive thing possible, but I’ve come around on that idea. Kind of like with Julia type declarations—if a function can run on an object, let it run on the object! I think it’s often better to be permissive and try than it is to hyper-restrictive. Rather than gate-keeping functionality, I think the rigor should come from being specific about what things mean (e.g. namespacing for semantic purposes?) rather than narrow permission.
  • (I guess the notion of non-omniscience also ties into what I have thought of as “ownership”—in hierarchical patterns like OOP, there is a strict ownership that prevents you from doing things because someone else “owns” them, and often that restriction is unhelpful or that ownership is a forced abstraction that isn’t real—maybe multiple things own it, or maybe nothing owns it)
• Liked the quote near the end(ish) from Alan Kay: “The most treacherous metaphors are the ones that seem to work for a time, because they can keep more powerful insights from bubbling up.”
• For clarification to someone inclined to be offended by the title, I think Casey Muratori means “mistake” more in the sense of “unfortunate oversight” than in the sense of “egregious error”.
• Lol at OOP being like Magic: The Gathering. Lots of database stuff feels the same way.