DHH is implicitly arguing against design of software.
Rails, as a brand, advocates YAGNI over design. Everything must fit into the tight containers of model/controller/view, or You're Doing It Wrong. You have to remember that Rails was created as the anti-J2EE where High Design was the order of the day. Given these leanings, DHH is extremely sensitive to letting other abstractions sneak in. He doesn't want to pollute the idea of simple design in Rails.
Rails tries to squeak by as Good Enough (like everything else web-based) design for many apps, and it succeeds there. Problems arise when you start developing a sense for design that exceeds the myopic view of Rails.
As much as Rails is made for programmer-happiness, I find it really dull. I get the feeling I'm more filling holes in DHH's playground than actually writing software. But it makes sense; as a tool, it's designed to remove lots of choice to prevent the 'unspeakable horrors' of people putting code wherever the want.
In a way, it's like Java: by taking choices off the table, you can guide newer developers to not create abominations. But it also hinders more experienced developers from creating software with abstractions/architecture that fits like a glove. Worse, it also indoctrinates inexperienced developers to systematically denigrate design and architecture because they've been trained to outsource it to a framework written by 'really smart' people. (The intellectual deference at work here is staggering; I can only assume heavy marketing helps.)
Rails, as a brand, advocates YAGNI over design. Everything must fit into the tight containers of model/controller/view, or You're Doing It Wrong. You have to remember that Rails was created as the anti-J2EE where High Design was the order of the day. Given these leanings, DHH is extremely sensitive to letting other abstractions sneak in. He doesn't want to pollute the idea of simple design in Rails.
Rails tries to squeak by as Good Enough (like everything else web-based) design for many apps, and it succeeds there. Problems arise when you start developing a sense for design that exceeds the myopic view of Rails.
As much as Rails is made for programmer-happiness, I find it really dull. I get the feeling I'm more filling holes in DHH's playground than actually writing software. But it makes sense; as a tool, it's designed to remove lots of choice to prevent the 'unspeakable horrors' of people putting code wherever the want.
In a way, it's like Java: by taking choices off the table, you can guide newer developers to not create abominations. But it also hinders more experienced developers from creating software with abstractions/architecture that fits like a glove. Worse, it also indoctrinates inexperienced developers to systematically denigrate design and architecture because they've been trained to outsource it to a framework written by 'really smart' people. (The intellectual deference at work here is staggering; I can only assume heavy marketing helps.)