Does Ruby Suffer From An Overabundance Of Choice?

By Peter Cooper

In "So You Want To Be a Ruby Dev" Kevin W Gisi presents a tongue in cheek narrative of a new Ruby developer being guided through the choices they have to make. (It's being discussed on Hacker News too - some good comments there.)

He asks a lot of questions: Which Ruby implementation to use? Which Web framework? Which Gems? Which version of Rails should you use? Which database adapter? And he caps it off with a conclusion of sorts:

Remember when Ruby and Rails was about getting stuff done? Note: New developers, Ruby is still a great place to be - even if there is an overabundance of choice at the moment.

Kevin W Gisi

I like Kevin and I saw merit in his satirical tale (for without any merit something is not satire), but right away my gut felt his conclusion was bogus. I wondered.. is there another problem here or does Ruby really suffer from an overabundance of choice?

If we're talking about the number of tools, implementations, or libraries, no. Abundance is Ruby's strength. It's the TIMTOWTDI (There Is More Than One Way To Do It) philosophy Ruby inherited from Perl, in contrast to Python's preference for only one obvious way to complete an operation. It's Ruby canon that Matz designed Ruby to be a fun programming language for himself but, also, a language flexible enough to adapt to other people's fancies and preferences. Rather than all of us reading from the same hymn sheets, we can bend, bolt onto, and monkey patch Ruby to fit our own personal or team preferences. This approach has its (much discussed) failings, but it's a philosophy nonetheless.

The overabundance is in the options we present

Still, I detected truth in Kevin's narrative. I realized, though, that it's not that Ruby is no longer about "getting stuff done" or that there's an "overabundance of choice" in libraries or tools. The problem is that Ruby's documentation, main advocacy sites, and even most sites for popular Ruby libraries (with one major exception - coming later) try too hard to demonstrate freedom, flexibility and choice from the get go without giving an opinionated, direct instructional approach for newcomers.

Let's take a cheap example (cheap, because the official Ruby site is really good, it could just be even better!) Consider the first thing some budding Rubyists will check out: the official Ruby download page. The first paragraph asks you to read Ruby's license before moving on to Ruby's source code and then Ruby on Windows. Instructions for Linux and OS X (the latter of which is out of date) are way down the page. Compare and contrast with python.org's approach - python.org's not perfect, but the link you want is almost guaranteed to be above the fold.

We need to be more specific in our READMEs and Web sites where we can and think about what a smart newcomer would want to see. We need "Getting Started" or "For Newcomers" pages that tell people exactly what to do without bending over backwards to cover edge cases or show off esoteric features. Tours that don't take diversions. Download X. Type Y. Run code Z. Instructing, rather than showing a smorgasbord of options, from which a new, confused user would choose none. Rather than offer 5 vaguely different alternatives on a "How To Install" page, give the simplest, most generic route, then discuss the alternatives for "advanced users."

Books are great at this sort of direction. Take almost any instructional Ruby book and even if it's out of date or not doing things "the accepted way", it will take a position and stick to it. Novices can follow along and make smarter judgements later. Let's bring that to our own work too, where we can (and I'm certainly aware there are people who do do this already - that's great!). I'll be going through my own libraries and future blog posts to keep an eye out for this and figure out how a newcomer might perceive them. Satish Talim's RubyLearning blog and courses have proven there's a gigantic population of people who consider themselves Ruby "newbies" reading what we write - it would be great if any of them could have a defined route to try out almost any library they stumble across.

Rails gets it right

Rails has been good at the instructional approach over the years. The "type this, type that, start a server, and bam, you've got an app" approach has been instrumental in the boom of Rails' popularity. Things like the "build a blog system in 15 minutes" screencasts were huge hits. Even complete non Rubyists could follow the same moves precisely and get the same results which they could then play around with further. Imagine if every good Ruby library had similar resources? (And if Railscasts has done a video for your library or tool and you're not making it a centerpiece of your site or README, sort that out!)

It's easy to forget that when we write about Ruby, the jargon and "do what you like" approach we frequently celebrate can seem alien to even the most intelligent newcomers who may well be used to more structured, directed "do X, then Y, just because" environments. We should provide hard and fast answers for those people, even if we run the risk of being a little wrong from time to time, without jeopardizing the richness of the number of tools, libraries, or implementations that exist.

Update 1: And I'm acutely aware now that Ruby Inside itself is not living up to the ideals professed here. I intend to resolve that. I only came up with this right now ;-)

Update 2: To be fair to Kevin, it seems he shares most of these opinions and that, perhaps, this line of thinking was his ultimate intention, judging by his tweets since he wrote the article.