> In video game design there is a saying: Show locked doors before you show a key
This is something I've tried putting into words many times.
I'll try to solve a problem and get to know its challenges deeply. Then a tool is introduced that brings it all together.
In these cases, I seem to quickly get a full grasp of the operation and essence of the tool.
That's because the use case for classes appears when the information needed to understand the program exceeds the programmer's working memory. At some point, you need some way to make something into a black box whose innards you do not need to understand when not working inside the black box. Languages which do this badly do not scale well.
This is a hard problem. We have, at least, structs, classes, objects, traits, modules, and namespaces. There still isn't consensus on how best to do that.
At a higher level of grouping, we have more trouble. This is the level of DLLs, microservices, and remote APIs. We barely have language for talking about that. We have no word for that level of structure. I sometimes refer to that as the "big object" level. Attempts to formalize that level have led to nightmares such as CORBA, XML schemas, and JSON schemas, and a long history of mostly forgotten interface languages.
It's interesting to read that the author likes Python's new typing system. It seems kind of half-baked to have unenforced type declarations. Optional type declarations, sure, but unenforced ones?
The paper "The Power of Interoperability: Why Objects Are Inevitable" uses the term "Service Abstraction" - "This terminology emphasizes, following Kay, that objects are not primarily about representing and manipulating data, but are more about providing services in support of higher-level goals" It goes on to give examples of how service abstractions arise in a lot of places including the linux kernel.
Author here. I sure would prefer enforced type checking - but a good type checker that runs automatically in the editor and immediately warns me when I inevitably mess up is the next best thing.
> At a higher level of grouping, we have more trouble. This is the level of DLLs, microservices, and remote APIs. We barely have language for talking about that. We have no word for that level of structure. I sometimes refer to that as the "big object" level. Attempts to formalize that level have led to nightmares such as CORBA, XML schemas, and JSON schemas, and a long history of mostly forgotten interface languages.
Here I would like to think TLA+ would help. But it seems it doesn't either.
I do not think JSON schema and XML schema are such nightmares though. They are not that difficult to write most of the time and are quite useful. Maybe they simply are not the best examples for what you want to express.
And what I think it's also important: don't ask for the key if the door doesn't need to be opened.
The examples on the text about Python and OOO are on point. Yes, people would reinvent classes if they needed, but the great thing about classes (and type annotations) are that they're optional
Compare with Java where you need a 'static void main' method inside a class just to begin. Why? Not even C++ requires that.
Do help them keep in their lanes but keep simple things simple.
The sheer irony is that "lite" object systems like python and ruby are actually purer and more faithful to the ideals of OOP (as envisioned by Alan Kay and those with him and before him) than Java can ever be, with its ugly and unnecessary seperation between classes and primitives, a completely irrelevant distraction that is primarily a VM optimization detail which only compilers and other bytecode producers or consumers should have known or cared about.
In python, nearly everything is a PyObject, data, code, source code files (which are just modules, which are just objects). It's highly misleading to name the things you get by calling a class objects, it implies this is somehow special, as if dicts and lists and ints, and classes themselves for crying out loud, aren't objects as well.
This is why I cringe so much when people associate OOP with Java bloat, the language is just unimaginably badly designed, this has nothing to do with OOP. You don't even have to be dynamic like Python and Ruby to be a good OOP system either, although that is a particularly low-friction path pioneered by smalltalk and lisp, but languages like Scala and Kotlin prove you can be highly static, highly OOP, and beautiful to read and write without the sheer amount of paperwork Java heaps on you.
It's not really an optimization detail, it's because Java doesn't have user-defined value types. The primitives are there because they're value types copied from C.
(Java is a memory-safe variant of Objective-C with all the interesting features removed.)
In school, I would always go to the end of the chapter and look at the difficult exercises, think about them for a while and fail to solve them. This gave me the motivation to read the chapter and do the easier tasks. It puts your mind in "the right state", knowing that you are working on a real problem.
Later in life I've discovered a trick that gets me into this state of mind more easily. For any feature, I ask myself: What problem does it solve?
I was thinking about this recently when learning about Monads and that quote hits the nail on the head. It seems to me one of the main reasons so may blog posts try and fail to explain Monads is they try to explain "What" a monad is, without the motivations for why we need them. Unfortunately the "why" is very tied up the nature of functional style, laziness, etc. The primary use of a monad is it allows you to enforce execution order. If you're coming from an imperative language, execution order is a given so the reason you'd want monads really isn't clear.
But I think that's the exact reason we need to learn simple languages here. So that we know the closed doors first (the abstraction problem), then we will create a key or find a key elsewhere. Otherwise if "Class" is made the part of the language, like Java, you will not appreciate the importance of it to any extent and have a overall bad experience....
Yep but in this case a language should be bundled with a good tutorial that introduces everything nicely. But if a person wants to just look at the specifications and code examples, the person would be having a lot of pointless keys..
> Then a tool is introduced that brings it all together.
I totally agree there and I think it's due to the fact that you've got a mental model of the problem space and your brain can see the empty hole. Once you have a tool of that shape, your brain knows where it goes and how it solves your problem.
This is very close to the image I have in my head. I visualize it as a puzzle: The more pieces you have, the more naturally more pieces come and the easier it becomes to see what you need and what is out of place.
This is something I've tried putting into words many times.
I'll try to solve a problem and get to know its challenges deeply. Then a tool is introduced that brings it all together. In these cases, I seem to quickly get a full grasp of the operation and essence of the tool.
I wish education was based around this principle. A bit like what Paul Lockhart advocated for in "A Mathematician's Lament" (https://www.maa.org/external_archive/devlin/LockhartsLament....)