Models are Programs

I hate the term modeling, it sounds so pretentious. Yuck.

“Before we started to use models in our company, we wrote millions of lines of code, but now we just draw a picture and write some code in a few DSLs and all that stuff gets generated automatically for us!” — Model-Fanboys Inc.

That’s great. That reminds me of some other tool that I use that does something similar. What was it… it translates my C++ code into loads of machine instructions, which I had to write myself before. That’s right, it’s a compiler.

So how did you say this is any different?

Your MDSD consultant will never admit it, since he gets to charge so much because he’s one of the few that knows about this “emerging technology”, so I will tell you instead: modeling is just a fancy pants word for programming. At least in the context of executable models. Modeling just sounds more magical than programming. “Whatcha doin’?” “Oh nuthin’, just modeling an if-statement.” Awesome, right?

Models (formerly known as programs, some like to call them mograms) can take roughly two forms: a visual or textual form:


class Person {

 String name;

 int age;


So… what is the difference here? The first is often called a model, and the second a program. Do you agree this makes no sense whatsoever? Not yet? Alright, another example:

Is this a model or a program?

“Well, that’s a model in a sense, but it is way too low level. It does not abstract from details.” — Model-person

Although the fact that this diagram does not abstract from details is debatable, this fictitious model-person has a point: what makes models work is their ability to abstract from reality.

So apparently it’s about abstraction.

Is abstraction the real invention here? I surely hope not. We’ve been doing that forever. Better yet, programming languages have enabled programmers to develop new abstractions since the dawn of time. These abstractions are expressed in frameworks, libraries, modules, packages, classes, methods, functions and macros.

So what’s wrong with those? If we had the tools all along, why do we still write millions of lines of code? That’s an interesting question. My feeling is that the reason is that developing new abstractions for a particular domain is still too much of an art form. People prefer to copy and paste over discovering the patterns and capturing them in a new abstraction. The reason is not laziness, it’s skill. Larry Wall says “Laziness is a programmer’s main virtue”, implying that if you can find a way to do something that saves you a lot of work, that’s a good thing. David Heinemeier Hansson, whether you like the guy or not, is one of the people that could see the patterns and was able to capture them in a little library we like to call Ruby on Rails, and sure, it’s not perfect, but it seems to dramatically improve developers’ productivity. Is Rails a new idea, though? Not really, it’s just an abstraction, a nicely executed one.

Still, the truth is, there are too few programmers like David. Gosh, I had never thought I’d ever say that.

“But there is more to models than just abstraction! Models are graphs that we can analyze!” — Model-person

When people talk about models they also envision the ability to check certain properties of a model, the ability to handle the model as data and manipulate it. Is it consistent? Are references to other parts of the model valid? Can we optimize the model? Can we weave aspects into it? These types of checks and transformations have been performed by compilers on programs for decades. Not new at all. Another hint that models are simply programs.

So the real issue here, I would say, is how to develop abstractions? How to think in abstractions? And how do we create tools around these abstractions that support programmers in their use (think compilers, optimizers, checkers, IDEs)?

Step 1 is to make developing abstractions as simple as possible. It should be easy to dabble with home brew abstractions, and to extend, build upon them or ditch them as the programmer sees fit.

While there is a thriving group of researchers in academia researching the construction of model-based tools and DSLs, outside academia, programmers seem to be more interested in more light-weight approaches like internal DSLs, in e.g. Ruby, Scala, Groovy, Python and more recently Clojure. This makes perfect sense to me, since developing abstractions as little internal DSLs is cheap, not overly complicated, relatively low-risk and the result integrates well with the rest of the language. You don’t have to take the leap to translate all of your software to EMF models, or worse, do partial code generation where you use a code generator to generate code that you then have to edit manually. I know, who farted, right?

No, internal DSLs like Rake, Capistrano, Active Record, jQuery, scala-query and Lift mix naturally with old-school Ruby, Javascript and Scala code, without the need to take a huge leap into “model land” or full-blown DSLs.

Step 2 is to take the developed abstractions and create better tooling for them. In a sense this is what we’re doing with WebDSL, we took many abstraction ideas from JBoss Seam, Ruby on Rails and other places and polished them up to have a really clean syntax and a damn thorough checker that attempts to catch as many developer mistakes that would otherwise be much harder to fix. The next step is to also create IDE support for these abstractions, that is also being worked on.

To come back to my original point. What we need is programmers that are skilled abstraction builders and the tools to enable them. The goal? Do a heck of a lot less work in software development, i.e. in programming.

Doesn’t the word modeling just sound silly to you now?