7 ms·

This article is spot on. It's a tribute to Rails' genius that so many people view it as a threat. You still see people who seem genuinely afraid to let go of t

This article is spot on. It's a tribute to Rails' genius that so many people view it as a threat. You still see people who seem genuinely afraid to let go of their massive, overly complex frameworks, or optimizing every little bit of their PHP app. People afraid of relinquishing the slightest bit of control for convention. What I actually see, when I hear developers decrying this stuff, is geeks afraid that they're going to lose their Genius cards now that there's an easier way. The fact is, Rails doesn't reduce the amount of hard thinking required to write a reasonably complicated web app, it reduces the amount of boring boiler plate code. For heavy lifting Rails still gives you the tools you need, there's a reason Rails Metal and find_by_sql exist. There's a reason most of the core parts of Rails are interchangeable (esp. with the upcoming Rails 3). Solving any worthwhile problem generally requires real work. Rails doesn't change this. The brilliance that Rails brings to the table is balance. Many of the design decisions of Rails just hit the sweet spot for a large category of apps, and remove so many of the pain points in development.

dasil003 17y ago
I sort of agree, but you're coming off a little over-excited there, and I say that as a 5-year Rails developer. The thing about Rails is that it represents the maturation of web development. It's not anything amazing per se, just a clever roll up of the best practices that emerged from the decade of Perl, Java, PHP development that preceded it. Ruby is the secret sauce that makes things just feel so slick. I don't mean to minimize the initial innovation, it's just that Rails is no longer very unique. A lot of frameworks have largely caught up even if written in less flexible languages, and long term I see opportunities for new frameworks to leapfrog Rails. The biggest liability for Rails is the Ruby runtime. Yes progress is being made here, but it's still a pretty sad state of affairs with regards to memory leaks and performance. I bang my head up against this every few months and it really hurts. Another issue is the need to handle more complex applications. Frameworks like Seaside allow you to set up complex stateful apps in a more robust way than will probably ever be technically possible in Rails (again due to limitations with Continuations in the Ruby runtime). A related issue is the question of what dark places we will end up in over a couple decades of large code bases running under Ruby with no warnings. I think it's pretty clear by now that Java is an unnecessary straitjacket, but do-whatever-the-fuck-you-want-with-no-warnings-whatsoever Ruby environment is not necessarily the most conducive to long term stability. I'll take it over Java any day, but I still have my doubts. Finally, there is the issue of increased ajax-ification of apps. Rails was a leader here early on insomuch as it provided proof of concept that Ajax could be done easily without a cross-browser-DHTML-guru certification, but 5 years later the Prototype + Rails helpers paradigm is quite dated. Ajax has huge potential for simplifying back-end code and making web apps inherently more scalable and performant. This is one area where Rails could re-invent itself, but a mature framework like Rails is going to have a disadvantage against a fresh approach starting from first principles. In short, I think the competition has openings.
- patio11 17y ago
  I love Rails to death and do Big Freaking Enterprise Web App Development in Java all day. A lot of what people identify as pathological is an evolutionary advantage in BFEWAD. Straight-jacketing the programmer is often a good thing because on a team of 100 programmers in three continents (you might think I exaggerate), including (by my last count) 12 programmers who have less than 3 months of professional experience, we want to make sure the damage done by the least skilled programmer on his worst day is strictly contained. I don't know if Rails scales to that sort of development, to be honest. The least skilled developer, touching one part of one class at the periphery of the project, is essentially one line of code away from blowing up the entire project. I should know: since I'm the sole Rails programmer at my business, I am by definition the least skilled programmer. And since I've managed to corrupt the results of my analytics code by making a one-line ill-considered addition to my printing code (which are kept in wildly divergent classes in different packages and namespaced from each other), just because it was not obvious I was altering the global state of the interpreter. That sort of bug has never happened to me in Java. A lot of techniques which are considered kosher in the Rails community don't scale to large distributed teams really well. Monkey patching is the obvious example -- if you have two developers who have different understandings of what Array#pack is supposed to do, you're going to run into HELLACIOUS, difficult to debug bugs. If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.
  - tptacek 17y ago
    But who would ever monkeypatch Array#pack? I think you're generally pretty safe as long as you stay away from the core library methods. It's the attempts to transparently extend well-known methods that I think tend to blow up on people.
    - patio11 17y ago
      a) I don't trust the least-skilled programmer in my company to tie his own shoelaces without supervision, as he might accidentally hang someone. b) You will eventually generate a namespace collision based on the birthday paradox alone, no matter whether programmers avoid the core methods or not, if they are working in the same classes. The Ruby community encourages people to have fun with String, Number, etc because it results in easy to write DSLs. c) array = [] array.methods.size => 127 require 'activesupport' => true array.methods.size => 185 Those added methods include, among others: sum, to, split, blank?, rand, load, to_xml, to_json... and numerous other things some intrepid developer might decide their own arrays could benefit from. Edit: The code sample didn't demonstrate what I wanted it to demonstrate, so I changed it to one that did, although it demonstrated something related anyhow.

dasil003 17y ago

I sort of agree, but you're coming off a little over-excited there, and I say that as a 5-year Rails developer. The thing about Rails is that it represents the maturation of web development. It's not anything amazing per se, just a clever roll up of the best practices that emerged from the decade of Perl, Java, PHP development that preceded it. Ruby is the secret sauce that makes things just feel so slick. I don't mean to minimize the initial innovation, it's just that Rails is no longer very unique. A lot of frameworks have largely caught up even if written in less flexible languages, and long term I see opportunities for new frameworks to leapfrog Rails. The biggest liability for Rails is the Ruby runtime. Yes progress is being made here, but it's still a pretty sad state of affairs with regards to memory leaks and performance. I bang my head up against this every few months and it really hurts. Another issue is the need to handle more complex applications. Frameworks like Seaside allow you to set up complex stateful apps in a more robust way than will probably ever be technically possible in Rails (again due to limitations with Continuations in the Ruby runtime). A related issue is the question of what dark places we will end up in over a couple decades of large code bases running under Ruby with no warnings. I think it's pretty clear by now that Java is an unnecessary straitjacket, but do-whatever-the-fuck-you-want-with-no-warnings-whatsoever Ruby environment is not necessarily the most conducive to long term stability. I'll take it over Java any day, but I still have my doubts. Finally, there is the issue of increased ajax-ification of apps. Rails was a leader here early on insomuch as it provided proof of concept that Ajax could be done easily without a cross-browser-DHTML-guru certification, but 5 years later the Prototype + Rails helpers paradigm is quite dated. Ajax has huge potential for simplifying back-end code and making web apps inherently more scalable and performant. This is one area where Rails could re-invent itself, but a mature framework like Rails is going to have a disadvantage against a fresh approach starting from first principles. In short, I think the competition has openings.

patio11 17y ago
I love Rails to death and do Big Freaking Enterprise Web App Development in Java all day. A lot of what people identify as pathological is an evolutionary advantage in BFEWAD. Straight-jacketing the programmer is often a good thing because on a team of 100 programmers in three continents (you might think I exaggerate), including (by my last count) 12 programmers who have less than 3 months of professional experience, we want to make sure the damage done by the least skilled programmer on his worst day is strictly contained. I don't know if Rails scales to that sort of development, to be honest. The least skilled developer, touching one part of one class at the periphery of the project, is essentially one line of code away from blowing up the entire project. I should know: since I'm the sole Rails programmer at my business, I am by definition the least skilled programmer. And since I've managed to corrupt the results of my analytics code by making a one-line ill-considered addition to my printing code (which are kept in wildly divergent classes in different packages and namespaced from each other), just because it was not obvious I was altering the global state of the interpreter. That sort of bug has never happened to me in Java. A lot of techniques which are considered kosher in the Rails community don't scale to large distributed teams really well. Monkey patching is the obvious example -- if you have two developers who have different understandings of what Array#pack is supposed to do, you're going to run into HELLACIOUS, difficult to debug bugs. If you do not quickly clue into the fact that Array#pack was redefined in a file you've never seen before that was committed last Tuesday by your most junior developer in the Seoul office, enjoy spending the next several days going over code you swear looks right looking for the error.
- tptacek 17y ago
  But who would ever monkeypatch Array#pack? I think you're generally pretty safe as long as you stay away from the core library methods. It's the attempts to transparently extend well-known methods that I think tend to blow up on people.
  - patio11 17y ago
    a) I don't trust the least-skilled programmer in my company to tie his own shoelaces without supervision, as he might accidentally hang someone. b) You will eventually generate a namespace collision based on the birthday paradox alone, no matter whether programmers avoid the core methods or not, if they are working in the same classes. The Ruby community encourages people to have fun with String, Number, etc because it results in easy to write DSLs. c) array = [] array.methods.size => 127 require 'activesupport' => true array.methods.size => 185 Those added methods include, among others: sum, to, split, blank?, rand, load, to_xml, to_json... and numerous other things some intrepid developer might decide their own arrays could benefit from. Edit: The code sample didn't demonstrate what I wanted it to demonstrate, so I changed it to one that did, although it demonstrated something related anyhow.