Yet my team uses models to design and build very technical, very high-performance software. You just need the right models.
Therein lies the rub.
Model-Oriented Programming is an important and useful tool in a programmer’s toolbelt, but with all due respect to the authors, it is not as wonderful as it is made out to be in the article. (And I disagree with the assertion that they invented it. It is an old technique, arguably popularized by Lisp’s macro system.)
While the article does make this point, it does not stress it enough: making models is hard. To do MOP well, you need a deep understanding of the domain. In fact, it is unwise to even think about making a model until you write multiple, reasonably large programs that work within the domain you are modelling. If you don’t do MOP well, you are left with unmaintanable and unnavigable garbage.
You need to understand the domain well because designing a model means designing a way to express the domain (which is a programming language, basically). This often means that you decide whether you should be able to extend it without redesigning it in the future, in the event that you missed something. That is, you have to leave yourself “an out”. This is an excellent way to achieve insanity and poor designs. Getting extensibility right is arguably harder than getting the model right (for example, consider how hard it is to extend most programming languages). But if you don’t get the model right and you don’t have extensibility, then fixing it later means, in all likelihood, either making a big ball of mud or embarking on a rewrite.
I disagree with the claim by another commenter here that the concepts are impractial in practice. It absolutely is (parser generators and permissions systems, for example). But it is not easy and articles like this that over-emphasize the good without detailing the up-front costs do it a disservice.
Spent three years of my life working at a Wall Street firm that was trying to adopt model-driven development on a large scale. Became an expert in things like the Meta-Object Protocol, UML, Eclipse Modeling Framework, etc. shudder
Ugh, why oh why do we invent this stuff…
Though the concepts seem great, they end up being impractical in practice, for a variety of reasons. The best abstraction we have for domain-specific language writing is something like Lisp/Clojure macros, but even then, they are complex and mostly practiced as a dark art (vs simple functions, which are widespread and easy to understand). Consuming a Clojure or Lisp DSL isn’t so bad, at least; e.g. the Clojure DSL for Storm. But that’s as far as I’d go with this line of thinking.
When you start going in the direction of text code generation based on abstract “models”, you end up with a strange edifice that crosses many layers of abstraction and simply confuses everyone. It reminds me of a book I leafed through at one point, “C++ Template Metaprogramming”. This book teaches you how to take advantage of the fact that the C++ template system, since it is a Turing machine of sorts, offers a way to do computation during the compile phase of C++ compiler runs. If you ever come across anyone who swears by that book, turn around and run in the other direction as fast as you can.