I am pretty neutral on this Java-RoR thing, so just some thoughts.

RoR is what 4GL tools promised for the Client-Server era. Some tools kept their promise, some did not. Actually many techniques I know from the Oracle*Forms world show up in RoR. I did this long enough to see where this technology leads you and this deterrs me a bit of using RoR.

I am quite sure that 9[0-9]% of all applications perform CRUD 9[0-9]% of the time. The same is true for the IDs of the screens matching table and column names. If you name it “scaffolding” or “Block-Wizard” - it is useful and it does a huge amount of the boring work. When you say that 20% of the code takes 80% of the time you will have 80% of the code written (or guessed, interpreted by default binding…) in your runtime/framework.
What you can do with RoR is as impressing as what you could do with Forms 20 years ago. Well, Forms got extended over the following decades and it got pretty complicated. Maintenance on a Forms application got difficult also after most of the out-of the box behavior got changed by custom-code.

The point was that all the auto-magic had its price (The same is true for almost any framework written in any language). At some point the 20% of code increase their share on the coding by simply showing an exponential behavior in maintenance cost. I feel now that this is pretty normal when you rely heavily on generators/conventions that do “only” 80% of the work and let you puzzle about the rest.

This isn’t even a bad thing, although the application will finally become non-maintainable you don really not have to care. There are few systems with a lifetime of more that 10 years. And as user-requirements shift more and more quickly in unforeseeable directions, it is perhaps wiser to accept that you’ll throw this one away or limit is for a specific user-group, while you do a hack with RoR to give the clients a simplified access to your spare-parts tracking, or integrate a new system to support additional requirements instead of merging it directly into your application. There are really few systems that require an complete overview over all data (a game server) over decades (accounts at social security).

The limited data contention of ordinary applications also implicitly solves scalabilty problems (or makes the solvable): Read the rest of this entry »