> I won't say we're absolutely comprehensive on all of these topics, but if the bar for I think you're right not be comprehensive, trying to dig deep would be

> I won't say we're absolutely comprehensive on all of these topics, but if the bar for I think you're right not be comprehensive, trying to dig deep would be ridiculous. I think the parent is specifically looking to address the problem of teaching an abstract concept (programming, often through algorithms, data structures, object orientation, all extremely abstract things), which can be aided by some orientation of where the topics in the class reside in the larger concrete, applied space. I remember when I was sitting in my first object-oriented programming class trying to figure out what all of the "objects" and "instances" were that the instructor was talking about. I didn't have the mental model to associate the groupings of code snippets on my page to "things" that could be manipulated and could "communicate" with each other. Once I was able to build that model, I was able to grok the concept of object composition, etc. Years later after designing a few systems, I am able to construct large mental models and know where what I'm looking at at a given time (whether that be a database, business logic snippet, or HTML elements) lives in relation to the rest of the system. It's far from essential to learning "how to program procedural code", but it's essential in building entire things, or even pieces that touch other parts of a whole.