Modeling and Programming

Some time ago we had a Workshop on Modeling and Programming at SPLASH2011 in Portland.

It was a pleasure to meet many nice  old chaps there.

In particular I remember some pleasant discussions with my modeling colleague and nevertheless good friend Ed Seidewitz. After the workshop, we chatted again about the discussion cliché of modeling vs. programming (in french we don’t say cliché, but tarte à la crème or custard tart). We came to the conclusion that it would be a positive service to the community to write a consensual paper on this subject.  We are loosing so much time endlessly arguing on this that it takes a significant energy that could be spent on more constructive debates.

French philosopher Albert Camus used to say:

Mal nommer les choses, c’est ajouter au malheur du monde”   which could be translated byTo misname things is to add misery to the world

And I believe this perfectly applies to the “Programming vs. Modeling” debate.  From time to time I tried to list the pro and cons arguments. Why modeling is programming and why programming is modeling?   Why both are similar and why both are different? If you want to have some fun in software circles, launch the discussion after a couple of beers on this subject and then just observe and enjoy. The nice property of this debate is that nearly everybody has strong opinions on the subject.

In december, at the CHOOSE Forum in Bern we had again this discussion.  Another respected colleague and my good friend Markus Voelter gave a talk with the title: “Modeling and Programming – isn’t all the same?” and with the following summary:

“Modeling and programming are often considered two different things. Programming languages are (perceived to be) different from modeling languages. DSLs are different from GPLs. But are they? Should there be a difference between the two worlds? How closely should the two approaches be integrated? In this talk I will argue that programming and modeling are really essentially the same thing; they are only different in terms of the abstraction level ….”

The more I look at the problem and the more I become convinced that organizing debates on the subject will lead us nowhere. We are in a blocked situation where the notion of modeling … and also the notion of programming have too many different definitions and meanings, usually very loose and sometimes completely contradictory.


So I came to the conclusion that we should propose a moratorium on any discussion on this subject. That obviously does not mean that the subjects of modeling and programming are taboo. That only means that we should give more time to provide precise definitions of  “program engineering” (or programming) on one side and “model engineering” (or modeling) on the other side.

Proceeding in that way, we may be able to somewhat cool off the debate while allowing all camps to build more solid definitions. Hopefully at some time, these definitions will allow avoiding sterile, futile, and non productive  arguments and leaving the discussion by the top and not by the bottom (i.e. not reaching Godwin’s point !).

We can study the differences and the similarities between these two forms of engineering. After all, if we find only similarities at some point, that may be good news. This seems a very respectful and scientific approach:


Let us let the champions of both approaches producing good and precise definitions. This is not so easy. I have been very careful to use “model engineering” and not “model driven engineering” which is a completely different subject. The relation of program engineering with language engineering (or software language engineering as it is often called now ) has also to be studied very carefully. But the relation of model engineering and language engineering has similarly to be made much more precise.  Markus Voelter recently published an excellent book on “DSL Engineering” which can be read as a  contribution to the subject because it touches the three topics of program engineering, model engineering and language engineering.

Finally we will also perhaps agree that software engineering is some kind of composite engineering encompassing program engineering, model engineering, language engineering, and many other forms of engineering. But this is a more ambitious subject.SoftwareEngineering

This entry was posted in Modeling, Programming. Bookmark the permalink.

4 Responses to Modeling and Programming

  1. vhanniet says:

    My contribution to the debate through some previous posts on my own blog :
    – I think one of the main keys to compare modeling & progamming practices is to check what they are used for : What is the focus of analysis: problem or solution? at
    – Another key is to find out if their usage is clearly established at a level where we can distinguish between craftmanship and industry : Modeling/Programming: Art or Science? at
    – I also like very much the reconciliation point tentative : if modeling and programming are the same can we use a model and a program the same way ? MDA/MDD: don’t round-trip! at
    – And finally about the question itself : MDA/MDD: Model is not code!? at
    All posts have comments that worth reading (including some comments from Ed Seidewitz by the way)

  2. We are learning that engineering systems, which seem straightforward to design, exhibit unpredicted and unstable behaviour when constructed. Take the example of a bridge that is made up of a simple suspension structure. Tests on scale models can show the bridge to be both strong and stable, but when the real structure is built it may sway unsteadily. Nonlinear dynamics, the mathematics of chaos, can help us to predict such behaviour and correct the design before construction begins. Similar techniques enable the engineering mathematician to understand phenomena as diverse as chaos in semiconductor lasers and patterns in traffic jams, to predict the weather, or to send spacecraft to the sun using only a tiny amount of fuel!

  3. TY says:

    There might be many of the same or similar properties in the concepts of programming and modeling (or programs and models) if rise the level to a certain generalized level. But IMHO it makes more sense and valuable to distinguish their differences.
    There are a general expression form to an engineering: engineering
    The “objects” are what the artifacts the engineering will establish, i.e. the outcome of the engineering process.
    Recognizing that they exist at the same time in a field is to admit that their object is different, for example, the programs and the models in software engineering in the picture of the post, isn’t it?

    • TY says:

      Oh, sorry, it may be write as “There are a general expression form to an engineering: [objects] engineering”; it appear to be lost in above comment because I used a pair of angle brackets.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s