Posts

First impressions on rails – how does relate to languages?

Recently I reviewed a book about development with Rails. I did the exercises and I started playing with this framework.

As always when there are web applications involved there are a lot of technologies, abstractions and languages involved: you have the database, you have the logic (written in ruby), you have the view (so html, css, javascript).

In rails you get a pre-baked integration between all this stuff; everything is pre-wired in a nice way, some higher level languages are chosen (like SASS or CoffeeScript, which compile down to CSS and Javascript). I think we would need that, as a general achievement. We would need tools that make languages play nicely together, that make easy to talk between different languages. Here it is easy because it is pre-built, because there are best-practices already sorted out. We need tools that make it possible for every kind of applications: integration should be come for free, not being the result of a larger effort.

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.