Friday, November 09, 2007
Models @ Runtime
Talking with Daniel Görlich during the MDUCDE 2007, he told me about the new workshop he was organizing in the context of MODELS, "Model Driven Development of Advanced User Interfaces". Digging into the conference, I found this other workshop that also sounds interesting: Models @ Runtime. For me, it's funny because every time I present Himalia, the question about code generation -vs- runtime interpretation is on the table.
What I actually think is that it shouldn't be a public discussion. The user need to obtain good response times, fair processor consumption, etc. but how you provide that shouldn't be his problem. For example, I don't care if SQL Server or Oracle are generating specific code for each database definition or if they are interpreting each DB model in each query. And that's good, it should behaves as a black box for me.
I think there are basically 4 things to take into account:
1. It is really one faster than the other one? People would usually think that the interpretation strategy is slower, but I think it highly depends on the quality of the generated code versus the quality of the runtime and the performance advantages you could take of having the model live @ runtime (for example, DBMS use optimization techniques as learning from the queries at runtime to obtain better response times).
2. In the resources consumption field I think interpretation is better, because you don't need to replicate everything each time, and so, you can let the underlying layers do their optimization work in a better way.
3. Extensibility/Flexibility is the only field -as far as I can see- where generating code could be the better approach. In the DSL Tools book there is a very interesting discussion about what they called the "Customization Pit" and what kind of things you need to take into account when you support code-generation scenarios. Basically, if you are not providing the right hooks in your high-abstraction language, you should provide the ability to inject the customization somewhere in the process, and so, code-generation and partial classes could be the answer if you don't know which customization scenarios would you need to provide.
4. Before of partial classes, maintainability was a big problem for code-generation tools. Nowadays I think there is no big difference between both approaches.
Finally, sometimes, you just need the model live @ runtime, and so, if you decide to generate code you are at least duplicating the effort. For example, you may need it to modify it, to learn from it, adapt it, etc.
With Himalia, I followed the runtime approach. Why? Because I think that in the long run, having the model live @ runtime will be far better in order to: let the end-user modify his user interface, learn from the model, etc. Obviously, as I don't want to be hoisted by my own petard, I have to dig very well into the customization scenarios and support the required hooks.
Luckily, this is the first time in a long time I found many people converging into this point, as more and more frameworks are being interpreted, and now, there is a conference about the topic :)
Labels: Conference, DSL Tools, Himalia, MDUCDE, Runtime
The CLR always JITs everything at startup.
Depending on the case, on approach has better performance than the other.
There's a very nice example of this with the Ruby language in which you have both code generation (metaprogramming) and runtime interpretation.
From the tooling point of view, I think the dichotomy is still alive.
Links to this post:
<< Home
