The title of this blog stems from the phrase "Lions and tigers and bears, oh my!"; a phrase that originates from the 1939 movie The Wizard of Oz. The underlying meaning is an expression of anxiety for escalating, unknown, or overwhelming fears; or in a lesser sense, having to face daunting tasks and challenges. In the movie, Dorthy, the Scarecrow, and the Tin Man chant it as a nervous mantra as they walk through a dark forest potentially holding dangerous creatures.
This article title is my nervous mantra... the ambiguity, overloading, and misuse of terms, is staggering....
Without using terms I first, with ChatGPT’s help, have to understand what the “boxes” are, what belongs in them, and where their responsibilities begin and end. Only then can I write about AI architecture in a way that helps others understand by later connecting those boxes to terms such as models, agents, and tools.
The purpose of this article is to let you know [if you are searching] that it isn't you. We are in and AI industry, where the architects are too far removed from their ignorance, a place where overloaded and reused terms do not detract from their meaning (in the context of experience), but leave no breadcrumbs for those of us learning.
As I study AI architecture for the development of a Visual Studio Extension, using the Anthropic Model context Protocol (MCP), so that I can use Codex for development. I'm brought back to an article I wrote for MSDN Magazine in 2011 where I coined the phrase "MVPVM", this is not so much a shameless plug as it is the danger of not clearly understanding terminology, in its misuse, and overloading of terms; it can make it "very" difficult to understand and learn and the ambiguity continues to propagate and become "the" standard - painting many developers into a corner.
Martin Fowler warned us of this back in the early days of MVC (a term we still misuse). I provide an excerpt from my article MVPVM Design Pattern - The Model-View-Presenter-ViewModel Design Pattern for WPF of this warning.
In Martin Fowler’s “GUI Architectures” document (bit.ly/11OH7Y), he states the following about MVC: “Different people reading about MVC in different places take different ideas from it and describe these as ‘MVC.’ If this doesn’t cause enough confusion, you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers.” The “Whatsa Controller Anyway” document at bit.ly/7ajVeS sums up his point nicely stating: “Computer scientists in general have an annoying tendency to overload terms. That is to say, they tend to assign more than one meaning (sometimes contradictory) to the same word.”
Smalltalk MVC gets further complicated by the fact that developers lack a common core of experience with their great architects in regard to the architect environment. As such, the overloading of terms and “Chinese whispers” are convoluted even more by the fact that most of us don’t even know what a Controller is because we’ve never had to use one—the OS has always handled its functionality for us. With a few facts to provide the common core of experience we lack, you’ll find MVC is actually easy to understand, and that the “C” in MVC has nothing in common with the “P” in MVP.
The underlined statement above is the crucial point and understanding. With it I will drive my point home - when the Operating System "OS" came into the picture, it embedded the Controller functionality into controls - you no longer had to manually create a controller to handle gestures (mouse or keystrokes) as the OS did it for us. When the controller disappeared, it now became a model-view pattern, which would later be called MVVM for WPF; the defacto standard that encompassed the exact issues Martin Fowler was warning us about for their Application Model pattern. It was why extensible applications required a Presenter (MVP) to manage the view-model so that they could remain decoupled and reusable.
As a result, MVVM would paint developers into a corner that would not permit them to easily reuse their models or views. You'll still find articles on MVC vs MVVM as what pattern is best to use. These are anti-patterns, replaced with MVP-VM solving problems our great architects warned us of.
I did not create the pattern MVP-VM, it was a pattern created by Microsoft in their early PRISM projects when Dependency Injection first emerged - I simply coined the phrase and my article was my attempt to help people understand their history, lest history repeat itself; I wasn't successful, you merely have to search for MVVM and MVC to see this.
Now the learning begins again, with ChatGPTs assist I'll generate articles that breaks it all down, coining new terms if/as applicable. In the meantime, don't look internally if you are confused - again, it isn't you.
To be continued....