Thursday, November 27, 2008

Musing about Code Generation, MDSD and DSLs

Disclaimer: I am a developer of business applications. The following view is certainly shaped by my experiences in trenches of enterprise IT. I am aware, that there are other domains of software development. Especially in industrial and/or embedded systems development the world might look different.


http://www.trinity3d.com/images/gnomon/digital_sculpting_human/example1.jpg I have blogged about MDSD and code generation before: Code Generation vs. Code Synthesis, Sunday Morning on InfoQ, Part 2 and Generic and generated - an oxymoron?.

I think MDSD is still too much tied to code generation.

Code generation is only useful, when your code contains a lot of noise and/or is very repetitive. In other words, when your code can not mainly focus on the essential complexity, but is polluted with accidental complexity.

In my opinion the trend in current platforms and frameworks is exactly to remove accidental complexity and letting the application code focus on essential complexity.

So these new platforms/frameworks take a lot of the wind out of the sails of the MDSD movement.

DSLs (textual ones) are another trend that tries to enable the sole focus on essential complexity. While DSLs can be used as source for code generation, they are not primarily tied to code generation. DSLs (especially internal DSLs) basically let it open to be interpreted/executed at runtime. [runtime code generation is somewhere in between].

So even if DSLs are often mentioned together with MDSD, I think they are really an alternative to MDSD. And given the current hype, they also take the momentum out of the MDSD movement.

If you have reached the goal of ultimately removing accidental complexity out of your code (I know this is fictitious), then you have arrived at a textual model of your business problem. This cannot be further simplified!

Nice boxes and diagrams do not offer another simplification or elevation of the abstraction level! They may be good for visualization, but even that is questionable. A picture is not always the best representation to grasp complexity!

Further more, the current state of the tooling involved in MDSD adds another level of accidental complexity (think: synchronization, diffing/merging, refactoring ...) which basically nullifies the ultimate goal of simplification!

Look at the following ActiveRecord model, as an illustration of my theory:
class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end
I dont think that this can be any more simplified. Also any graphical representation with boxes and lines would be no simplification, and would not offer any more convenience (think about layouting, refactoring, searching, diffing ...).

No comments:

Post a Comment

Related Posts Plugin for WordPress, Blogger...