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."

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.

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...

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.

http://rvm.beginrescueend.com/rvm/basics/

http://en.wikipedia.org/wiki/Association_fallacy

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.

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.

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.

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).

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)

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.

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.

> 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.

OTOH, I've been hearing that people have written books for Python 3 which hasn;t taken off. Now they are backporting their books to 2.x (e.g Dive into ..).

There is a negative side too. Everyone's writing gems. There are plenty of gems floating around, some incomplete some abandoned, its hard to tell. When i worked in Java years back, aside from the Java distribution itself, i used to use libs from jakarta.apache. One knew they would be maintaining it, and the quality would be good.

In Ruby, i really don't know of any such company or initiative, that maintains libraries. It's too open. I get frightened when i download a gem which has many dependencies, since sooner or later some deps are going to break. That's happened several times. Even some of the well-known rubyists abandon their gems and don't respond to mails or bug reports since they are busy in ruby confs, or setting up their startups.

Then there's the gem creation process, which seems to be changing. I typically tend to google (maybe this is my fault) and i get outdated docs on creating a gem or publishing it. Hopefully, the ruby-lang.org site has an updated link on suggested or preferred way to create a gem. Every time i create a new version of my gem (it uses hoe), it seems hoe has changed, and I struggle to find a sample to correct it.

However, I love ruby too.

1) Signup at rubygems.org: http://rubygems.org/sign_up 2) gem build my_lib.gemspec 3) gem push my_lib.gem

That's it!

I will try it out and see how it is.

Again, should not ruby have one standard prescribed way of doing it, and not so many.

Gemcutter has made it trivial to take a hand-rolled gemspec and publish your gem. No libraries or gem scaffolding necessary.

http://en.wikipedia.org/wiki/Mark_Pilgrim#Dive_Into_Python

It makes it very hard to search for a given gem/library -- one has to wade through too much noise. The reason I've stopped downloading perl apps is the same -- many of them depend on some broken, abandoned library -- you waste hours trying to install something before finding some conflicting/broken dep.

Perhaps a repo or listing of live projects, with some rating system.

Now there is new problem: not knowing if a gem is for 1.8 or 1.9.

I totally switched to 1.9, wiped 1.8.* from my development systems. In a few cases I had problems (like manual edits to acts_as_list) but life is simpler and the runtime speed increase is really nice. Pardon a link to my own stuff, but I have written about the 1.9 conversion: rubyplanet.net

I am trying to maintain Ruby 1.9.1 and JRuby compatibility on my rails apps which is getting easier to do.

In my many years of doing Ruby development, that's my real complaint. Ruby makes it much more difficult and costly to eliminate technical debt.

The reason that I ask is because I've found the opposite; due to the massive number of easy to use testing frameworks, it's easier for me to end up writing tests and making sure my debt doesn't come back.

In one specific example, we had a bug in moving an app to 2.3 in which three different gems contributed. It was very tough to nail down.

Aside from all that, pop open your favorite editor or IDE, find a method you're interested in learning more about (let's say, for refactoring), and try to use that tool's built-in functionality to "Go to" the declaration. 6 out of 10 times I bet it fails to get you there. I have tried with RubyMine, NetBeans, Aptana, and Vim, and each of them fail to find anything more complex than simple method declarations. Ruby is just a hard language to navigate.

Gotcha. Makes lots of sense. I've just not been bitten by this yet, I guess.

> use that tool's built-in functionality to "Go to" the declaration.

Ah, I'd never run into this too, because I default to just going to a browser and going to the online docs. But if you're used to another workflow, I can see how that'd be a pain.

if it does not work, there could be other reasons as well as for example, a dependency not installing on my machine.

In fact that brings up another point. What if the given gem has more dependencies. I would have so much to test out just to know if it works on 1.9.

I would think it is best that the author declares he has tested it on 1.9 on a given OS. Then others can add their feedback whether it has worked on their OS etc.

Ruby 1.8.6:

    require 'set'
    [[5, 6].to_set].to_set == [[5, 6].to_set].to_set
    => false

Ruby 1.8.7:

    require 'set'
    [2, 3].to_set.hash == [4, 5].to_set.hash
    => true

Broken semantics for such simple things make me seriously distrust the language runtime completely. At the very least, this means that the much-touted Hash object in Ruby is untrustworthy and can easily lead to data loss or corruption.

Why not? Hashes produce collisions. If you don't want collisions don't use hashes. Or if you want a hash function that doesn't produce collisions for your specific data type, write one. It's not hard.

Relying on a generic hash function to never create a collision is just poor engineering on your part.

And as for your distrust of the runtime, did you know that 1.9 is an entirely new one?

1. Django/Grails/Symfony/ASP.NET MVC are closing gaps in Python/Java/PHP/.NET communities, making RoR not as much attractive as it was couple years ago. Means much less new developers form these communities.

2. Today's start-ups are moving to RIA, where the UI is built via Capuccinno/SproutCore/GWT/Flex and Rails doesn't provide much benefit here compared to others.

3. Ruby hardly can fight with Python and PHP on their markets.

I admit Ruby influence and innovations, but I won't put my bets on it.

1) It's great that the ideas that Rails popularized are being adopted on other platforms. But besides for Django which has a) been out for almost as long as Rails and b) uses a great dynamic language, the other camps you mention doesn't have anything resembling the "Ruby on" part.

Just grabbing the grabbing the general ideas of Rails are trying to fit them into less expressive languages yields some less than desirable results. Have you actually looked and compared any of the code back and forth?

2) Hahaha. The web has been pronounced dead on more occasions that I can count, but RIA has been the boogeyman since the beginning of the last decade. Don't invest your piggybank in it happening this time.

Additionally, I know of lots of Rails apps that are using all those technologies for the front end. Whether your output is HTML or Flash or whatever, you're going to need a backend to handle it. All the benefits of Ruby, Active Record, Action Mailer, and the works are as relevant as ever with that.

3. What does this even mean?!

Anyway, good luck betting.

I'm language agnostic, but you must remember that other languages evolve too. PHP got namespaces and closures, C# - some dynamics, and Groovy - support from SpringSource/VMWare and is most popular language on JVM: Jython, JRuby, Scala - all far behind.

And why can Ruby not "fight with Python and PHP on their markets?" Care to elaborate a bit?

PHP has lots of opensource web-apps: OpenX, Wordpress, Joomla, Drupal, phpBB, SugarCRM, Magento eCommerce, MediaWiki you can just download and run on any hosting in couple of minutes. Every app has a community behind it. Haven't heard about anything as popular built with Rails(except Redmine).

Python - studied in Universities like MIT and can be found in any UNIX/Linux distribution. Lots of bindings and libraries(SciPy, NumPy, Twisted). Ruby bindings and libraries are far behind.

I enjoy Ruby, I tend to write my scripts in it, and have written a couple Rails sites in my time. But there's probably 1 Ruby job out there for every 300 .NET and Java jobs, maybe even less. Maybe the Ruby community likes this, I dunno. But for me, it means I've never had a chance, and probably never will have a chance, to really use Ruby in a professional environment.

And I can't really blame companies, if I had a company I wouldn't use Ruby either. I generally find .NET is a nice compromise between Ruby's ADD and Java's glacial pace, but that's just me.

I have my reasons to love working in ruby, most of all is probably how easy it made my work. I have come from other languages which i initially loved but then found too verbose and cumbersome and sort of strait-jacketing. That there are some issues with ruby (such as repositories, or obsolete gems -- a problem with perl and other languages too) should not make me dislike it. Cheers.

I am not saying that other languages don't. Java has wonderful JUG's.