I may be quite off base here, but i think it has to do with the audience you are dealing with. Once the reader is somewhat familiar with more abstract reasoning

I may be quite off base here, but i think it has to do with the audience you are dealing with. Once the reader is somewhat familiar with more abstract reasoning, e.g. able to identify placeholders in places such as (in programming) function/variable naming, return values and such, it becomes evident that you can put any garbage 'thing' in there, and it doesn't matter. You can gloss over these naming details and distill the entire concept into something like: A function named something, that belongs somewhere, returns something. I'm not entirely sure if the author uses "language documentation" as synonymous to implementation semantics, like OO. The above was written assuming he isn't, because in my mind OO is a concept largely unrelated to the underlying programming language. If he doesn't, then priming the brain with a set of well-known entities or concepts and how they relate to each other and then mapping them to the material you are trying to teach is desired. But, there is a balance to be struck between abstract reasoning and tying abstract patterns to things such as a cat or 'mew'.