|
|
Re: Code Generation: The Real Lesson of Rails
|
Posted: Mar 28, 2006 8:03 AM
|
|
Ya know, ive seen the code generation angle pushed on multiple fronts over the years, and its an excellent idea, best realized in a compiler.
Once you step outside the rigid confines of a formal programming language, code generation largely falters.
Oh, well, you do find crusty old Lisp programmers doing magic with defmacro, but its best described as a dangerous art, and kept away from minors.
I mean, lets face it, how many people have you worked with whose hand made code you trust, let alone trusting their code generators.
One of the problems that Bill suggests code generation can solve is creating static types that map nicely to database tables. Now, database tables, as we all know, are pretty much dynamic types. You can add or remove columns to your hearts content with them, and at runtime! What fun! So Bill neatly solves his problem by generating new type declarations which are then compiled into his statically typed program. He probably also whacks a bunch of boiler plate code into his generated types. But what happenss when someone changes the database, as database admins are wont to do? Well, theoretically, you'd have to emit new generated code, and compile and re-link everything, right there on the spot, which will go very smoothly unless you have something in your actual handwritten code that depends on something in the database schema that has changed. Hmm, maybe making your static code depend on your dynamic database isnt such a good idea.
Hmm, oh, but why doesnt he just stick with dynamic types all the way through his code? Why not simply have a dynamic record type, whose columns are accessed by string names, just as in the database. Oh, but then, thats pretty much what Ruby does, and pretty much also what any Python database mapping layer does too.
If you worked at Microsoft, you'd be worrying about code completion and filling little dropdowns with helpful lists of words. Well, why not have your dropdown code go off to the database directly and query the schema to fill in the list
Maybe all this dynamic stuff is too slow for you, in which case you shouldn't be using a frikking relational database in the first place.
So far the only people to propose "code generation" that seems to work are the AOP crowd, who treat the concept with respect, and do it with a very light touch. They must have been paying attention they day they were taught that self-modifying code is bad form.
|
|
Previous Topic
