Writing tip: When the first paragraph of your essay is an extensive apology for the poorly worded title... your title is poorly worded.<p>If you're gonna linkbait do it like you mean it. Otherwise the effect is that of Darth Vader saying "I beg your pardon".
Absolutely agreed. So much of what makes Rails "easier" than other frameworks is based on a disregard for established best-practices -- particularly with regard to encapsulation and data-hiding. Monkey-patching is but one example.<p>Another is rails' attitude toward private data. Every DB field on an ActiveRecord object is world-writable, whether you like it or not. That's fine for prototyping, and works adequately well when you have a small team of developers who never get rushed or sloppy, but is a <i>terrible</i> idea for long-term code stability.<p>Now, you can hack around this and make attributes private-ish, but it's not easy, and as best as I can tell, nobody in the rails community actually does it on a regular basis. This blows my mind. Yes, sometimes you want the ability to rapidly hack up a prototype, but if your framework precludes the ability to turn that prototype into a robust model with minimal effort, then I think your framework is flawed.<p>/flame-proof suit <i>on</i>/
From the article: Emacs Lisp, the language it is written in, is every bit as dynamic as Ruby.<p>Warning! Author thinks in Blub ( <a href="http://www.paulgraham.com/avg.html" rel="nofollow">http://www.paulgraham.com/avg.html</a> ).<p>More seriously, Ruby's apparent class patching combinatorial explosion of bugs makes a very good case for aspect oriented programming ( <a href="http://video.google.com/videoplay?docid=8566923311315412414&q=engedu" rel="nofollow">http://video.google.com/videoplay?docid=8566923311315412414&...</a> ).