I was hoping someone would point this out. I tried many times to understand what MVC meant and came to the conclusion it was ill-defined. The M and V are easy to understand: separation of presentation from content. That is what your teacher was teaching. But the definitions of what C is and how it interacts with M and V are so vague and varied that I eventually threw the whole concept out. (Note that there's no C in your teacher's example. Both command-line and GUI programs have control responsibilities. Actually, both have views too. Yet the distinction is still instructive.)
I believe we should focus on first principles on the one hand (in this case, separation of concerns) and specific problems on the other. Trying to formalize first principles into proto-programs has proven to be a mistake. You end up with ersatz abstractions that don't stand up to interrogation - things that take the form of something precise, but aren't precise. That is confusing, leads to a great deal of useless secondary thinking like "is my program really MVC", and inevitably bogs down in semantic disputes. The more one focuses on such stuff, the less one focuses on real software. It makes you worse at building systems, not better.
First principles are imprecise, but simple and profound. They guide you very well if you let them. Specific designs are precise, but always relative to the specific problem they're trying to solve. Both these levels of abstraction make sense; it's the in-between layer that leads to confusion and should be eschewed. But it's perennially seductive to people who are attracted by the thought of figuring software out at a meta (but still technical) level.
Edit: skimming through the comments in this thread shows how differently, and how incompatibly, people interpret these terms. They exist to provide "a common vocabulary so people can know what they're talking about" (the standard rationale for patternspeak), but the facts on the ground are Babelian.
I believe we should focus on first principles on the one hand (in this case, separation of concerns) and specific problems on the other. Trying to formalize first principles into proto-programs has proven to be a mistake. You end up with ersatz abstractions that don't stand up to interrogation - things that take the form of something precise, but aren't precise. That is confusing, leads to a great deal of useless secondary thinking like "is my program really MVC", and inevitably bogs down in semantic disputes. The more one focuses on such stuff, the less one focuses on real software. It makes you worse at building systems, not better.
First principles are imprecise, but simple and profound. They guide you very well if you let them. Specific designs are precise, but always relative to the specific problem they're trying to solve. Both these levels of abstraction make sense; it's the in-between layer that leads to confusion and should be eschewed. But it's perennially seductive to people who are attracted by the thought of figuring software out at a meta (but still technical) level.
Edit: skimming through the comments in this thread shows how differently, and how incompatibly, people interpret these terms. They exist to provide "a common vocabulary so people can know what they're talking about" (the standard rationale for patternspeak), but the facts on the ground are Babelian.