Introduction
In the MDriven community, we have traditionally utilized the terms Gist and Modernity to articulate the distinction between the “idea” of an implementation and the “technology” of the information. While these terms have served us well, they present a pedagogical challenge: they do not tie into the established vocabulary of the broader academic and technical world.
To provide a clearer, more universal perspective, we are shifting our language toward two fundamental pillars: Philosophy vs. Physics. These terms are the “go-to” wording in academic circles when discussing the world of thought and ideas versus the world of reality and implementation.
Defining the Duality
1. Philosophy: The World of the Model
In MDriven, Philosophy represents the “pure thought” of the system. This is the model—the declarations of what a system is and how its components relate.
-
The Intent: It is concerned with truth, logic, and business rules.
-
The Medium: It exists independently of specific hardware or transient syntax.
-
The Goal: To capture the essential meaning without being burdened by the mechanics of execution.
2. Physics: The Reality of Implementation
While some may object to describing traditional coding and hardware management as “Physics,” it is the most accurate description of the work. Traditional development is concerned with controlling the target world in a rigorous, imperative manner.
-
The Manual Governor: Managing database constraints, memory, and hardware is an exercise in managing digital “physical laws.”
-
The Redundancy of the Idea: In pure physics, intent is irrelevant; a stone falls because of gravity, not because it “wants” to. In imperative coding, the “idea” of what we are trying to achieve is often made redundant by the low-level description of what is happening at the machine level.
The AI Risk: Why We Cannot Abandon the Model
In the light of these arguments, a significant concern arises regarding the rise of Generative AI. If AI tools are used primarily to produce the Physics (the code) alone, we inadvertently devalue the Philosophy.
The Problem of Philosophical Erasure
Using AI to bypass the model and jump straight to implementation creates a system where the “Idea” is never formally captured. It exists briefly in a prompt and then vanishes, leaving behind a dense, physical reality of generated code.
-
The Extraction Burden: Anyone wishing to understand the system’s philosophy in the future is forced to try and extract it from the physics. This is a high-effort task with a massive risk of distortion.
-
The Redundancy of Truth: If the “Physics” is all that exists, the original intent becomes a ghost. We are left with a collection of behaviors with no documented “Why.”
-
The Ground Truth: MDriven argues that AI should help us express Philosophy more clearly. If AI understands the model, the engine can automate the physics. But if AI generates physics directly, we are simply creating “Dark Matter”—code that works but cannot be logically audited.
The Redundancy Crisis: From Human Compiler to Philosophical Architect
There is a rising wave of anxiety among software developers today who fear that Generative AI will make them redundant. This concern is most acute among those who have spent their careers as “Physics Implementors”—individuals tasked with taking a requirement and a set of tests and manually grinding out the imperative code to satisfy them.
However, we must be candid: That specific role has always been logically obsolete. The fact that it took a human to translate a logical requirement into a database schema or a C# class was a limitation of our tools, not a reflection of the developer’s unique value. When a developer focuses solely on passing tests without engaging with the Philosophy of the system, they are performing a mechanical task that was destined for automation.
The Evolution: Managing the Philosophical Persistence
The way forward is not to compete with AI in the realm of Physics, but to reclaim the realm of Philosophy. The developer’s true value lies in managing the philosophical implications of requirements and capturing them in a persistent format.
A system of high complexity cannot exist solely in one person’s head. To build something larger and more detailed than a single human can muster, we need a shared, rigorous language of thought. This is where MDriven provides the solution:
-
The MDriven Model as Philosophical Record: Rather than a collection of transient code, we use a persistent format based on UML and OCL.
-
Declarative Intent: By using Declarative ViewModels and Actions, we describe what the user should experience and what logic must hold true, without prescribing the low-level “how.”
-
A Language for Philosophers: This model becomes a document that other “philosophers” (architects, stakeholders, and senior developers) can read, audit, and evolve.
Beyond the “One-Brain” Limit
Traditional coding (Physics) is limited by the “headspace” of the individual coder. When the code becomes too dense, the philosophy is lost, and the system becomes unmaintainable.
By lifting the description into the MDriven model, we allow the system to grow beyond the limits of individual memory. We aren’t just passing tests; we are curating a persistent logical universe that can be navigated by humans and executed by machines. The developer is no longer a manual laborer in the digital mines; they are the Architect of the System’s Philosophy.
Academic Foundations: Additional Reading
To ground this shift in established computer science thought, we look to the thinkers who first identified this tension between the conceptual and the concrete.
-
Brooks, Jr., Frederick P. (1986). “No Silver Bullet — Essence and Accident in Software Engineering.” Brooks distinguishes between the essential complexity of the conceptual construct (Philosophy) and the accidental complexity of the technical implementation (Physics).
-
Dijkstra, Edsger W. (1974). “Programming as a Discipline of Mathematical Nature.” Dijkstra argued that computer science should be a branch of formal logic (Philosophy) rather than an empirical study of how machines behave (Physics).
-
Whitehead, Alfred North (1925). “Science and the Modern World.” Whitehead warns against the “Fallacy of Misplaced Concreteness”—mistaking the physical implementation for the abstract reality.
-
Selic, Bran (2003). “The Pragmatics of Model-Driven Development.” Selic notes that software is unique because it has no natural physical laws; therefore, forcing developers to manage “synthetic physics” manually is a failure of abstraction.
Conclusion
The shift from Gist and Modernity to Philosophy and Physics aligns MDriven with these foundational truths. Our goal is to ensure that the Philosophy (the Model) remains the primary governor of the system. By automating the Physics, we ensure that the “Idea” is never redundant and never lost. In an era of AI-generated noise, the Model is the only “Ground Truth” that remains.
