The text below was first posted on the Catalyst mailing list. It is an analyzis of value of the code generation technique that was popularized as 'scaffolding' by Ruby on Rails. It describes what makes the scaffolding so efficient in converting newcommers into avid users of the framework.
I would like you to imagine you in the position of a developer that has some idea for a web project, thinking about trying a new web programming framework. There are many to choose from, or you can also go the simple way and use CGI.pm or develop something for his own - how would you decide? Every framework is lots of code, lots of documentation so it's not an easy task. After reading those mountains of manuals you can discover that some limitations make the framework not really fitting to your project (some related thoughts in http://www.artima.com/weblogs/viewpost.jsp?thread=8826). This is that risk that scaffolding mitigates - you generate your application with minimal effort and you have a working example tailored to your database schema. You don't need to think if a example from the manual can be adopted to your data structures - you have it adopted automatically. This is the first advantage of scaffolding - easy evaluation.
The other important advantage is that it helps in the learning process. You get a non trivial working example. And again this example is based on your database schema - from the starting point you at once know much about the program. You don't need to internalize the arbitrary business rules of some unfamiliar application - the business rules are yours - so at once you can start and play with it. And a good scaffolding will give you much space for simple but meaningful modifications to tweak and play with.
Of course there are also disadvantages to code generation. It is impossible to come with a good schema to update the generated code when you release a new version of the generator and we don't want the programmers who use the scaffolding to be stuck forever to the version that they used the first time. One solution can be to limit the code generator to really most trivial part and move all other logic into traditional libraries that just happen to cooperate with the generated code - and this is what I try to do with InstantCRUD.
Subscribe to:
Post Comments (Atom)
1 comment:
Agreed. It's a good way for people to learn a complex framework. They can define their data-model, do the code-gen and then see how this framework handles that model.
And allowing the code-gen to produce common variations (as you said in your email) adds a lot too.
I recently watched a couple of short Seaside screencasts, and I have to admit, they startled me, possibly more than the original Rails screencast did.
For the first time I *got* the idea of a continuations based server. I realized that for web-apps it takes you to a new level. You abstract away from worrying about the http protocol and wiring together all the different forms and and action handlers. This wiring goes *inside* the language, exactly the same way that garbage collection hides all the memory management stuff.
With a continuations based server, it becomes possible to use the abstractions of your programming language "on top" of your web-app.
As I understand, the golden rule of code-generation is to make sure that either you do it once and then throw away your input data and just work with the output of the code-gen, or to make sure that the output is ephemeral, and rerun the code-gen whenever you update it.
The reason is that trying to work with generated code in such a way that you can also regenerate is a nightmare. The second of these modes is essentially code-generation as *compilation* of a higher level language. And obviously you recompile whenever your source changes.
However, with web-apps, once you have continuations, I suspect you can hide your whole web-specific level away. You can start thinking of writing a domain-specific language which is essentially "interpretted" by the rest of the code.
Post a Comment