Platform Strategy & Architecture
« [Other] RESTafarians' dialogs[Other] Semantic CRUD »

[MDE] Apple's Section 3.3.1 and the case for Metamodel Oriented Programming

  05/17/10 08:29, by jdubray, Categories: MDE, BPM, Mobile

Dear Steve:

I am not the only one that has been spooked by Apple's infamous section 3.3.1. I have trouble to believe, though, that you will enforce it. For me, and for many, MDE is the future of software engineering and I cannot imagine that you would want to be in the way of the future. Without you, DOS would be probably still be the dominent OS and daisy-wheel printers would have remained the only way to print QuickBasic listings.

My vision of MDE is called MOP, Metamodel Oriented Programming. In my previous letter, I deferred explaining why MOP could well become a major approach to software construction. If you give me a few minutes, I'd like to go over the arguments.

(Apologies to the author) I don't know who wrote this, but it summarizes very well the situation we are currently in:

Software engineering is advancing, albeit at a glacial pace. I spend most of my days writing in languages and using tools that were obsolete over a decade ago.

Frankly, Objective-C -no matter how elegant it could have been- and XCode fit that description too. Overall, the industry has created a huge mess, unable to evolve without hurting its customers significantly. Imagine a world where you would buy a car, a TV or a house and it would cost several times as much to keep it running, without adding significant value in the process. Yet this is the world that people such as yourself want us to live in. You guys simply can't care less about your platform customers.

I just want you to think just for a second why would a platform vendor want its customers to write code that is completely independent of the platform on which it runs? Why would anyone let their customers write solutions in a language that is both architecture and technology independent. Why would they even tell them that it is possible? Who says that a solution needs to be coded in Java or C#, HTM or Javascript? Who says that when you are "coding" a solution you have to think about it's scalability, its data access layer or even its presentation layer.

It is easy to see how many people make a comfortable living helping solutions delivery organizations deal with this permanent scaffolding that the Software Industry has become.

What is MOP?

Most people in our industry have forgotten it, but our current Software Engineering practices stem from the creation of simple abstractions on top of assembly languages. You probably remember how much a step forward BCD was... not to mention the undocumented instructions of the 6502... Sure, I understand that in these days you couldn't possibly care about the solutions people were building with your computers. There were two separate worlds. Yet, we are still there today -more than 30 years later. Every programming language, every platform can be traced back to incrementally better abstractions on top of assembly languages. Don't you think we know enough now to start looking at the problem from the solution and not from the platform?

Metamodel Oriented Programming is an approach to Solution Construction that relies on developing a Solution Model. Unlike traditional Model Driven Engineering approaches, MOP is not afraid of the "P" word, programming. A MOP based Solution Model is both polyadic and cogent, i.e. it is a dedicated programming language which unlike traditional programming languages is composed of multiple entities that compose the solution. For instance, WSPER is such a language.

Yes, you have read it correctly, I am recommending that dedicated programming languages be created, as solution models, to support the construction of families of solutions (information systems, games, real-time systems, OSes,...).

MOP is not about creating Meta-Platforms. It is not about creating a common denominator of platforms that enables developers to write solutions that run on different platforms. As a side effect, a MOP Solution Model could be instantiated on different platforms, but I cannot insist enough to say that the goal of MOP is to create Solution Models that are both architecture and technology independent.

I understand why you might think this is a crazy idea, but I actually give you the recipe to create a programming language. Lots of programming languages are created to correct the issues of other languages, yet, hardly anyone creates a language for a specific type of solutions. People often create metamodels for that. The problem with MDA / MDE is that they reject "code" entirely. They claim that a (meta)model must be purely declarative otherwise it is not MDA. Eventually, when the solution's behavior needs to be expressed, they create more metadata, instead of introducing the right amount of imperative style. Expressing behavior with metadata is a losing value proposition and IMHO, explains why MDA/MDE has not had more success.

So today, we have to chose between monadic programming languages which require countless patterns, recipes, rules and what not to produce anything useful or extremely granular metamodels which remain nevertheless limited in expressing the solution model.

Why MOP?

Lots of solutions we use everyday belong to families of solutions. The concept of a "lone" application that would fit everyone still makes sense, but often groups of people need slightly different things and we see lots of solutions which are better represented by a collection of variants of otherwise a common solution. Actually, I would argue that it is not even necessary to think in terms of families, one could think that a solution is typically made of parts and one could define a programming language optimized for the part types that make up the solution. Isn't it what we do all day as we create object or function libraries from which the solution are built? MOP is simply making that step explicit and independent -totally independent- of the solution model.

This clear delineation between the solution model and the implementation of the parts is why MOP is a superior approach to solution construction. The solution model is not only totally independent of the platform on which the solution is deployed, it is also independent of the way part types are constructed. It starts with the assumptions that the part types are defined somewhere, but the environment in which the part types are defined is totally sealed from the solution model. Why? because it is otherwise impossible to have the discipline to do that in a traditional programming environment.

Is MOP that crazy?

Is MOP that crazy? Hell no, the semantics of the solution model are buried in code today. A new developer coming in, even if he or she is an expert at both the platform and the type of solutions will have the hardest time to take control of hundreds of thousands of lines of code. What do you think is easier? To learn a proprietary (MOP-based) programming language from which the solution is expressed with a fraction of the LOCs needed with a traditional programming language or to learn the code base? To maintain millions of LOCs or tens of thousands of LOCs? What would you rather say on your resume? That your last 3 project failed because it took too long, cost too much? or that you last 10 projects succeeded?

Ultimately standard solution models will emerge just as well, so the proprietary aspects of MOP will disappear too.

Steve, I am not sure you want to stain your resume by holding back the Software Engineering advances that are yet to come. You guys (the platform builders) have done enough damage in the last 20 years. Don't you think you owe us something? Don't you think we deserve a better way to build solutions? Don't you think the future would look far brighter if only we could focus on Solution Models and not native APIs?

I, again, ask you, respectfully, to reconsider section 3.3.1 of the OS4 license agreement.


Jean-Jacques Dubray

No feedback yet




My views on SOA

I work at

Recent projects

the old ebpml

powered by b2evolution

©2017 by Jean-Jacques Dubray

Contact | Help | b2evo skin by Asevo | framework | vps hosting | François