Of course, this cuts both ways. The Ruby community is infamous for being, for lack of a better word, ADD when it comes to frameworks and tools. What's cool this month is un-cool the next, when someone else comes along and re-invents the wheel with different names & syntax. Going back and trying to reconjure up some old Rails code I wrote a few years ago is basically impossible, as the plates have shifted underneath it so much as to make it a huge project in itself to bring it up to the present day toolchains.
Beyond this, I see communities obsessed with tools and frameworks as distracted. The hard problems are those of algorithms, data structures, design, and architecture. Most of the things that we see a lot of programmers spending their time thinking about, writing about, and writing code for fall under a class of problems that, while important and necessary, often seem to me as those under that oft cited line in most academic papers: "a simple matter of programming, left to the reader."
This is a very shallow analysis of a fast-moving community, but I can sympathize how it's the easiest way to make yourself content with using the same tools as you did three years ago. If you feel like you're getting stuff done to the best of your abilities with your current toolset, enjoy!
The Ruby and Rails community is lead by individuals who are never happy with the status quo. There are always things that bugs me about development. As soon as I solve one problem, the next in line gets promoted and I work on that. I find that incredibly rewarding.
It does come with the cost of blink-and-you've-missed-the-bleeding-edge. Which I understand that not everyone has the mental bandwidth (not as a sign of intelligence, but as one of priorities) to keep up with. That's OK. You'll still be better off with just taking a snapshot of the state of the art every 9-12 months than just tuning out.
Also, you're setting up a false dichotomy between caring about the tools and the domain. The vast majority of developers I've found that can't help constantly improving their toolset is the same kind that can't help improving their understanding of their domain. In fact, one often leads to the other. I've created lots of Rails features that were directly related to a deeper understanding of the project domain, for example.
I love Ruby. I love Rails. I don't love that Rails 2.2.2 doesn't work well with the version of Ruby Gems 1.3.6, which I have to have on my machine for my Rails 2.3.4 projects. Can I just upgrade the 2.2.2 project? No because it's not mine...it's a client's project. etc... This happens to me all the time.
The problem isn't mental bandwidth. It's more along the lines of the "Consistency-Atomicity-Partition Tolerance" debate related to databases and the noSQL movement. Perhaps it's the "Creativity-Velocity-Supportability" triangle - Ruby/Rails leans toward the "Creativity/Velocity" - it's fun to use, the community is very creative and the framework moves fast. It's harder to support old projects as time goes by because the framework moves on and old projects break.
I'm consciously choosing the higher supportability cost of older code because of the fact that I love writing code with Ruby and Rails. It's still a cost I have to be aware of when I start a new Rails project.
EDIT: I reread the comment and I retract "This is a subtle ad-hominem attack on someone making a very legitimate point about the community."
When I first read it, I thought that he meant "mental bandwidth" and "shallow" as attacks and i can see he wasn't implying it that way...
This is a subtle ad-hominem attack on someone making a very legitimate point about the community.
I think you've got it backwards; DHH gave a very legitimate response to someone making a subtle ad-hominem attack on the Ruby community.
Instead of addressing the rapid evolution of the Ruby community on its merits (or lack thereof), the phenomenon is reduced to "ADD," "distraction," and an obsession with coolness.
There couldn't possibly be any merit to, for instance, embracing Git or REST: we're all just trying to be cool. "Very shallow analysis of a fast-moving community" is right on target IMO.
Agreed. I re-read it and agree DHH's response is legit. However, I don't see the original comment as an attack on the community as much as a (warranted) critique of the community being over-focused-on and at times distracted-by, 'cool'.
Honestly have rails 2.2.2 and old rubygem, along with rails 2.3.4 and rubygem 1.36 has never been easier. Thanks goes to the RVM project for simplifying keeping around different stacks of Ruby.
That's not what ad hominem means. Ad hominem is when you disagree with an idea because of who supports it. For example, "gun control is a bad idea because Hitler believed in it".
> Ad-hominem is where you use qualities of the arguer as disproof of the argument.
Right, which is what he didn't do. "I don't like Rails because DHH has an ugly hairdo" would have been an ad hominem. In this case, he is disagreeing with the idea itself.
No, that would have merely been an ill-informed opinion and a non-sequitor. One can feel however one wants about a subject and for any reason and still not commit a logical fallacy because feelings are a-logical. For an actual fallacy, we need actual premises: "Ruby is good," "Rails is bad," etc.
An ad-hominem is even more specific. The premise must be disputed because of the arguer. So, if DHH makes statements about Ruby or Rails, and one argues that those statements are false because of DHH's hairdo, then that would be an ad-hominem.
Thank you. As a Ruby on Rails programmer I couldn't agree more. Rails 3.0 will bring some maturity... programming to interfaces and APIs rather than implementations. I believe Javaland "got that" a long time ago.
Agreed. Rails 3 seems to be shaping up to be the "revenge of the grown-ups". I see it as potentially being as paradigm shifting as the initial release of Rails, but not as in-your-face.
When Rails came out, it reminded us that programming can be fun. Rails 3 will shows us that not only can it be fun, but it doesn't have to come at the cost of stable interfaces, reusable code, and the ability to not have to go back and refactor your entire project every 6 months.
I think it's awesome that you're excited for Rails 3. I'm incredibly excited for it. Lots of great stuff happening.
But. (And that's a big but). I think you might overestimate the philosophical changes that are going on here. Seeing pipe dreams and unicorns where there are simply just incrementally improved ideas and work horses.
The rate of improvement in the Rails camp is not going to change because of anything fundamental to Rails 3. It might change because we're running out of big problems to deal with, but I also somewhat doubt that.
So that means that yes, you will have to change your application every 6 months, if you want to keep up with the latest and greatest. But you don't have to. You never had to. A Rails 2.3 application, for example, could have been chugging along just fine for the last 12 months (2.3.0 released March '09).
If only the language itself was on the same solid footing! I love Ruby on Rails but I see most of the uncertainty coming from broken Ruby 1.8.7 and 1.9 builds -- Rails changes just add to the mess.
I agree with this completely. I just wanted to add though that had I stayed with Oracle and PHP / Java, I would not know the things I know now, nor would I have had the opportunities that I found because of those. Ruby (the community) has challenged me time and time again not to dismiss something just because it's new or different. I say that because I still talk to coworkers and former coworkers who are still doing what I did. They don't know about NoSQL, they don't know about load balancing, or metaprogramming, or evented Javascript, or any of the things I've had to become aware of to do my job. (Or HAML and SASS which are just fun and awesome).
I see far too many people getting comfortable and then becoming dangerously close to being out of date.
I don't like the distractions of "new shiny" every week, but the stagnation of a community scares me even more. So I strike a balance.
What I would like to see is more involvement from people who claim to know what they're doing to join our Rails Mentors project (http://railsmentors.org/) Then they can teach people, instead of waving hands about NoSQL and leaving it up to "an exercise for the reader."
(Disclosure: I am the coordinator of the Rails Mentors project. It's non profit and part of RailsBridge (railsbridge.org)
I only did a tiny bit of work with Rails 1.2, and basically got serious during the 2.3 days... but is most of your old code really not compatible? I specifically remember watching a presentation by DHH where he talked about how old Rails code he looked over _looked_ a bit dated, but still worked just as well. He mentioned this specifically with the new RESTful focus that came along, many people were going up to him and asking "I have to re-write my entire app to be RESTful!" and that's just not the case.
There's still a bit of social pressure to "keep up with the Jonses", though, I'd agree with that. But it doesn't mean you have to do it.
There are definitely things that broke along the way in Rails. However, the overall problem is that the 2 or 3 dozen gems or so that were coupled with this project of mine all had incremental releases that broke existing APIs. And new dependencies were introduced. And so on. Basically bringing an old project up to the status quo was an exercise in frustration, so I just worked with my old gems, bugs and all, since it was less scary to do so since my test happily passed in their frozen-in-time world.
Note my post here was partially devil's advocate, since, as bphogan said above, having a vibrant community inventing new things (with a lot of extraneous wheel-inventions accruing along the way :)) is infinitely more desirable than a dead one, set in their ways and so on. I just wanted to throw up a counterpoint that this enthusiasm for the churn needs to be tempered.
I think basically the Ruby community is what you get when developers are given a fun to use language and throw caution to the wind and just build. This is great, but it's time to tilt back towards future-proofing a bit, as the Rails 3 initiative has shown us. It kind of reminds me of the typical successful project: lots of initial, quickly built prototypes created not to sell but to learn, followed by one or two more solid, grounded, mature and thought through production releases that are meant to last years, not months.
Yeah, I generally have gems locked into a particular version, and try to only update when I actually have to. I'm also still using ree, I plan on just doing the 1.9.2 move at the same time as the Rails 3 move.
> I just wanted to throw up a counterpoint that this enthusiasm for the churn needs to be tempered.
I think this is a valid point, but I also really enjoyed David's comment above. This 'never being content' aspect is one of the things that I really _like_ about Rails, and probably why the community gets a reputation for being a bunch of angsty teenagers. It's important not to get rid of that fire and desire to make things better.
Beyond this, I see communities obsessed with tools and frameworks as distracted. The hard problems are those of algorithms, data structures, design, and architecture. Most of the things that we see a lot of programmers spending their time thinking about, writing about, and writing code for fall under a class of problems that, while important and necessary, often seem to me as those under that oft cited line in most academic papers: "a simple matter of programming, left to the reader."