Recently I reviewed a book about development with Rails. I did the exercises and I started playing with this framework.
Another thing that caught my attention is the use of the command line to launch a code generator. You achieve higher expressiveness through this commands. Rails always try to get the sense out of your input, so if you crate a migration and give it a meaningful name, let’s say:
rails generate migration AddDetailsToProducts
rails will understand from the name that the migration is just about adding a column named Details to table Products and the column will be a string (the default type). The problem is that those commands are used to generate things, and so the higher level view is lost. You type:
rails generate scaffold Orders
and rails generate a lot of files (model, views, controllers, tests, etc.). You then start customizing parts of those files. Ideally you would like to see you system as a “scaffold” plus your modifications while instead you see a lot of files and you don’t know which ones you touched and which ones are instead purely a product of the code generator. So code generation, when you are supposed to put your hands on the generated code, is an hardy but dirty way to achieve a limited part of the benefits of an higher abstraction (only when you build but not when you maintain).
It would be nice to have both the abstract vision (the generation command plus a description of the customizations) and the “explicit” vision (the generated code with the customizations plugged in). Maybe this is something to work on in the future.