Runtime vs. Design/Compile Time
Chris asks:
At what point with code gen / templating do you start to think about doing all this codegen at runtime instead of compile time?
And if we were to be doing it at runtime would be be better served by using a dynamic language such as ruby to program in?
That's a good point. In a perfect world, there would be no need for code generation. We would write nothing but business/domain specific code and everything else would just happen. But for well over twenty years we've been aiming for that perfect world and we seem only a few baby steps closer than in 1987.
In an imperfect world, we have two basic choices, manage an architecture and run a lot of code at design time or manage an architecture and run a lot of code at runtime. Both require a fair amount of configuration.
And both can offer the real long term benefit of switching away from coding code – which is transitory and dying before you even finish coding. We want to switch away from coding code and toward creating metadata which is a true business representation. Of course metadata changes. But it changes at the speed the business changes – not due to artificial technology shifts.
For my effort – I want the extra code run at design time to offer the best possible runtime behavior, including performance. I can extend an architecture I’m expressing in templates far easier than I can extend an architecture I am expressing via an OR/M tool. I also want to debug directly into code specific to the problem at hand – I want to debug through generated code, not an OR/M engine.
The next round of effort at making plumbing simpler from Microsoft is also code generation – Entity Framework. When someone gets the plumbing correct and we truly never need to care, we can turn off the code gen and go direct to whatever structure, however its’ done and completely ignore the problems code gen is primarily used for today. In the long term, we shouldn’t care about anything except the business problem we’re solving.
Dynamic languages certainly change the architecture. I'm looking forward to exploring them as the overall knowledge base expands. But we've been sitting with a pretty dynamic language in our laps for many years, the majority of us have programmed in it, and with the exception of precisely one person - everyone I know varies between mild distaste and downright hatred for it. I think a lot of Javascript's problems have been related to debugging and platform issues, and I realize that there are differences between Ruby/Python and Javascript. However, if we didn't fall in love with the dynamic aspects of Javascript in the last ten years, I remain slightly skeptical about dynamic languages in the next few years. Some of the differences, and our attitudes and skills may change as a result, are that the new languages have a broader platform base and we're increasing our understanding of how to actually use them as opposed to hacking them enough to solve some trivial website detail.
But at the core, the technique for expressing metadata into a working application is not half as important as metadata at the core of the application, however its expressed.