Grails, Rails, and Java

I recently had an opportunity to work with Grails, Rails, and Java to solve some similar internal business problems. Dynamic languages are great productivity enhancers for a very small team of highly competent experts in the field. However, in the hands of an average programmer without rigorous guidance and careful review they should be classified as weapons of mass destruction.

While I haven't yet tried this with Rails, I did make a recommendation (after using it myself) that we switch some of our simpler new CRUD applications to use grails. Heck, why screw around manually wiring in spring/hibernate/etc when you can use grails and get all kinds of neat things for free?

The first problem we're struggling with in grails is that there are some cool and super ways to get things done, but because we can always revert to java, most people just do it the "java way". This means we've forsaken the safety of compile time checking and gained ... nothing.

The second problem is that, even if one decides to forage into the groovy/grails way of doing things, there is more than one way to do it^4 and our code begins to look a lot like hacked together perl modules. The newness of the language is a pitfall for folks who absolutly require it to have been done before

Comments

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

MACH TEN Addendum: for companies wanting to use MACH platforms