This post originated from an RSS feed registered with Ruby Buzz by Obie Fernandez. Original Post: Abstracting Away the Gruntwork Feed Title: Obie On Rails (Has It Been 9 Years Already?) Feed URL: http://jroller.com/obie/feed/entries/rss Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Obie Fernandez Latest Posts From Obie On Rails (Has It Been 9 Years Already?)

I found the following commentary of interest to Rubyists, buried in a long post on lesscode.org about PHP versus Java programmers...

The overall design of large Java systems will tend to be more convoluted than that of almost any system written in a dynamic language, simply because the contortions forced by Java require larger overall designs.

Java buries the intention of code under a thick layer of implementation details and typing bureaucracy. Programmers are drilled to execute the requisite gruntwork in repeatable, predictable ways. Moreover, doing so conditions them to design their own system to cater to these reflexes. A maintainance programmer who comes in later will therefore easily be able to make changes to the mortar of an application. Unfortunately, that does not ensure good high-level designs nor does it translate to easy refactoring of convoluted architecture.

Dynamic languages abstract away huge swathes of gruntwork and require less structure. This means small systems have small implementations, which directly translates to better maintainability. The price is a loss of exemplary structure and of conditioning, which requires better innate architectural skills and stronger discipline when building larger designs; neither are strong points of the average programmer. However, designs in such languages aren?t frequently large, because the language does not require large architecture for modestly sized systems ? which the majority are.

At times I've been the maintenance programmer, relying on my trusty IntelliJ refactorings to confidently make changes to existing code. I've also been stuck refactoring code that I didn't write on projects (that were actually rewrites in disguise) so I understand the pain of trying to change a convoluted architecture. Case in point, about 18 months ago I found myself forced to try remoting the GUI of a large Java AWT-based app which was written without any layering or separation of concerns. P A I N F U L !

I'm actually quite anxiously hoping for widespread adoption of Rails by the unwashed masses of average programmers out there. They will write less (however shitty) code and the architecture of their systems will improve dramatically due to Rails' severe design constraints.