Model-View-Controller — Misunderstood and Misused
paradox1x writes "Malcolm Tredinnick shares a terrific rant against the misunderstanding and misuse of the Model-View-Controller design pattern. In particular he takes issue with the notion that Django should be considered an MVC framework. He says that 'It's as valid as saying it's a "circus support mechanism," since the statement is both true, in some contexts, and false in others (you can definitely use Django-based code to help run your circus; stop looking so skeptical).' I'm not sure I agree with the entire piece, but it is a very good read." We recently discussed another look at the bending and stretching of MVC patterns in the world of Web development.
Umm, Malcolm is probably THE most active Django developer at this time (Django developer as in "someone who develops Django", rather than "someone who uses Django for development).
There's some evidence for that in their naming of the application layers:
Model
Template
View
Seems like you have been mislead on a lot of concepts. Design patterns have ZERO (or very little) with the implementation. What they are about, is the intent. If most fresh college hires you see don't know Strategy, its time you look at hiring from different colleges, it is fairly standard, especially in software engineering degrees (a lot less in purist computer science schools, I'll admit).
Btw, while it is a possible implementation, it is actually uncommon (and not desirable) to implement Strategy by passing a function to a method, as that doesn't allow for a good upgrade path of the API (which is what Strategy is about).
Finally, not all good GUI code is MVC, far from it actually, as it doesn't apply well to event driven and composite application (the former is a large amount of desktop application, the later is also a lot of desktop application, and some heavily customizable web application package), in which case, one (out of many) prefered pattern is MVP, as MVC doesn't play well with the existing APIs and framework.
Finally, very few design patterns are "work around some limitations of C++", because, a gain, design patterns have nothing to do with the implementation, but everything to do with communication and intent. So Singleton in Ruby is actually built in, so you don't need to implement it at all. The concept of Singleton is still there when you talk about it. Observer in .NET doesn't need to be implemented, it is built in (multi-cast delegates). If your intent is to use Observer, thats still what is commonly talked about. And so on and so on.
They are more prevalent in certain fields than others, too. If you take a typical team that works on device drivers full time, you'll probably never find someone who has heard (much) about them, thats understandable.