Helping you drive digital innovation
RSS Feed of the Mendix Blog
Thanks for Subscribing

Keep an eye out for Mendix resources coming straight to your inbox.

Stop generating code!

on October 13, 2008


While Model-Driven Engineering (MDE) is receiving more and more attention, the confusion is becoming bigger. Just look at the number of abbreviations starting with MD! Interesting discussions are going around about using UML or Domain-Specific Languages (DSL), triggered by some rumors of Microsoft Oslo. Methods & Tools recently published an article on the UML vs. DSL topic in which the authors conclude:

So what is the outlook for the industry? It’s our belief that as a basis for modelling for code generation, UML tools – in their current form – will gradually lose “market share” to DSLs: DSLs can be more direct, appealing and easier to use for a wider range of users. However, UML vendors, with their strong background in code generation approaches, can compete by adding a non-UML modelling and meta-modelling ’surface’. Combined with their tool’s existing UML features, this would make an attractive combination product for many companies.

I’m not going to add a view to this discussion, I want to start another discussion: why do we still generate code? In the quote above they talk about ‘modeling for code generation’, and that’s exactly what a lot of the current model-driven approaches are doing: transforming higher level models into lower level models until the model is expressed with source code.

In a panel discussion on the past & future of MDD at the recent MoDELS ‘08 conference in Toulouse, some of the panel members did touch this subject. In short they did state that if you specify a system using some language, which will be transformed in some other executable language, there often is a difference in computational models between these languages. Imagine, for example, the following scenario:

Model A -> Model B -> Source code

In most cases a difference exists between the underlying computational model of A, B and the source code, at least between two of them. In debugging such a system you need to understand all computational models AND the transformations between them. That’s quite difficult, in fact, it can be more difficult than debugging a system just written directly using the source code.

If we directly execute the model we can debug at the model level. What we need is a language which means something by itself, without a lot of transformations. One of the panel members even compared a visual model transformed into code with C macro’s. That’s maybe a bit overdone, but you get the picture.

So why not just execute the model directly, without complex transformations, thereby enabling debugging at the model level?


Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog
Derek Roos

About Derek Roos

As chief executive officer, Derek leads a pioneering team of software industry experts with the mission to bridge the gap between business and IT, making business application development dramatically easier, faster and collaborative. As a result, the company is achieving tremendous global growth and disrupting the way many of the world’s leading companies are innovating and differentiating. Derek earned a Master of Science degree in Business Administration from Erasmus University, Rotterdam. He is a highly sought speaker at IT conferences and is guest lecturer at several universities. Derek has received the Ernst & Young Emerging Entrepreneur of the Year 2012 Award. Keep in touch at @MendixCEO.