Programming to an abstract interface — and in large codebases, enforced visibility controls — represent the middle ground everyone wants, in my experience, between “OOP” and “sir, this is C”.
The example definitely shines. Doing something barely non-trivial is great since it gives a feeling for the language. I wish other language introduction pages would take note.
It does feel like you need some shared understanding with the author about what the interesting parts of a programming language are and what can be left implicit.
Perhaps the author and I have similar intuitions? I guess I also like that isn't pure LLM output style. It was refreshing to see some human work.
Yep. Interface-based (true) delegation between objects would be my go-to if it existed.
What's the difference between an exemplar and an example?
between “OOP” and “sir, this is C”.
That's more templates, ownership and operator overloading.
Polymorphism is not a modern way to program because it introduces dependencies and enormous speed hits from pointer chasing, both of which are corrosive to a good program.
So in a programming text for a new language, one would use examples of things that are strings, or examples of structures one might declare. You might even see examples of multiple ways to solve a problem in code. An exemplar though shows the one best - or at least most recommended - way to do something in the language.
Why would you use a worse example and how do you know the example you are looking at is the best?
It can be difficult to know if your example is the exemplar. It can be reasonably assumed that if the creator of the language provides only one example, it at least should be the best one. It is at least the best one in the docs if it's the only one.