Does Ruby Suffer From An Overabundance Of Choice?
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 real issue stems from how Ruby's documentation and advocacy sites approach education. They emphasize freedom and flexibility upfront but fail to provide an opinionated, direct instructional approach for newcomers. This became particularly evident during a workshop I attended on emerging technologies, where a speaker drew comparisons between this scattered approach and the rise of UK crypto gambling platforms. These platforms thrive on the allure of freedom and anonymity but often lack straightforward guidance for new users, leaving them to navigate complex systems on their own. This parallel underscored how vital clear, accessible resources are for fostering adoption in any field, including programming. If you also want to access various casino games anytime, there are online slot games you can play.
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.
August 11, 2010 at 5:11 am
I agree.
As a nuby trying to learn this stuff, most of the tutorials assumed so much knowledge on my part, that even things that seemed simple required this setting or that software downloaded. So I've started collecting 7 writing Nuby focused ruby tutorials. Posted the first one on setting up rvm here: http://francob411.posterous.com/how-to-install-ruby-version-manager-rvm-in-os
Would appreciate any suggestions on how to improve it from more seasoned coders.
Best,
F
August 11, 2010 at 5:44 am
Excellent Post. You're right on the mark. Too often the articles teaching ruby are trying to show flexibility. The highly-regarded (by most, it seems) Pickaxe book is full of this and as a result is almost unusable as a learning book for Ruby Nuby's. Thank for enunciating that point.
Mike
August 11, 2010 at 6:40 am
Absolutely spot on - I'll freely admit I didn't do a great job of providing a good solution in my initial post. It's absolutely to be celebrated that we have so many choices, and for the seasoned developer, it's often necessary to fork a project to get the desired results. It's precisely why we love Ruby.
But the beautiful thing about many of experiences with Ruby and Rails was the idea of convention over configuration, and quite literally in that order. You followed the Railscast or DHH's blog screencast, or whatever tutorial to the letter. And then you had the opportunity to tweak the configuration and make it your own.
It's fantastic that we have so many options available, and it means that for us mid-level to upper-level developers, we save a LOT of time.
But we really need to make it a priority to encourage new developers, whether by providing more step-by-step tutorials (and keeping them up to date, and deleting deprecated ones), or by providing one-on-one support.
It's been great to see the positive responses, and I hope we see more developers signing up for RailsMentors.org (whether to learn or to teach), and that we see many more step-by-step examples going forward.
August 11, 2010 at 8:44 am
I feel the fffffffuuuuuuuuuu that @gisikw is pointing at. I am dancing between rails and gems and plugins and versions and not getting much done.
It feels like we're in limbo at the moment waiting for Rails 3 to restore some order. I hope they'll wait a long time for Rails 3.1 to be released!
August 11, 2010 at 9:04 am
We need _why.
(/me remembers the first time he launched the Shoes app)
August 11, 2010 at 12:45 pm
This is a really interesting piece. I recently had a conversation with someone at HackCamp that was new to Ruby but specifically wanted to use Rails. They were having real trouble understanding many of the concepts. I think its very hard to forget how difficult things might be for new people coming to Ruby. Those of us who have followed along since the early days the options are clear but for someone on the outside knowing which options to choose to get started could be hard.
I especially agree with the comment that with Rails 3 in place at least that choice will be a little simpler and it will be safe to refer people all the Gems/Plugins knowing they all work without hassle.
August 11, 2010 at 4:08 pm
I am also frequently frustrated by the focus of Ruby technologies on Rails. For much of my career, I have been a desktop application developer and I have never worked on a web application. (well, not professionally). From that standpoint, I don't need Rails.
I do, however, enjoy the Ruby language and I have occasionally found the need to use web technologies. Tools like Sinatra, Rack, or Passenger are a big boon for my needs. Those usually involve small, one-off projects for which Rails would be swatting a fly with a sledge hammer.
I often find that getting information about how to use these technologies outside of a Rails-centered environment is mining for gold. It's a lot of hard work, but when it pays off, it really pays off.
One issue I run into, personally, is the fact that most of the documentation for these technologies assumes a certain level of knowledge in the architecture of web applications that I don't have. I end up asking questions like "What is a 'Virtual Host' and do I need one to make this Sinatra app available to three people in my office?".
That's mostly me needing the web site "Web Application Deployment For Dummies : Special Edition - for those who want it fast, not scaleable".
Another issue, however, is that much of the tutorial documentation focuses so heavily on Rails. "Here's how you can integrate a Sinatra app into your Rails stack". "Here's how to write Rack intermediaries that sit on top of Rails". To use the technology effectively, I have to learn Rails, understand how the technology fits in there, then abstract out that concept to use it in the way I want to.
(And don't get me wrong. It's not that learning Rails is a bad idea. Personally I enjoy it. Professionally, however, my focus could more effectively be directed elsewhere)
I am very much aware that I'm shouting at the storm here. Folks don't devote a lot of documentation to using their technologies outside of Rails because of the 80/20 rule (with me squarely in the 20).
By the same token, I find that a lot of these technologies have a beauty in their own right and I'd love it if that was easier to see. Perhaps if it was, the 80/20 split might shift.
August 11, 2010 at 4:22 pm
Hey Peter,
This reminded me of an old blog post by Dave Thomas called "The Hero's Journey". It talks about the "Dreyfus Model of Skills Acquisition" - the idea the new users just want the steps to do, where as experienced users want to know more of the inner workings and choices. Here's the link:
http://pragdave.blogs.pragprog.com/pragdave/2007/03/sywtwab_3_the_h.html
Rails does a pretty good job, the whole "Burger King" model in Rails 3 seems to fit well with the Dreyfus Model. Ruby-lang could definitely use some love.
@Scott A number of Ruby developers came to Ruby because of Rails, which would explain the Rails-centric focus in the community.
August 11, 2010 at 5:42 pm
I agree with Scott. Too many Ruby tutorials are tied to Rails. It's Hello World and then straight to Rails code. When I first started learning Ruby, I thought Rails (and its conventions) was Ruby. It's off-putting to newbs who just want to learn the language and use it for non-website purposes.
August 11, 2010 at 11:50 pm
Just the other day, a rubyist remarked to me that we always go after "the new shiny".
I haven't read through all the comments there yet, but ... some people are suffering from a SenseOfHumorNotFound exception!
August 12, 2010 at 5:00 am
Rails is a framework designed for a very specific type of application, that being database-backed web applications, and Ruby is a general purpose programming language. The Rails core team has been pretty good over the years about trying to maintain that focus in order to keep Rails as compact and coherent as it can be while still making it more useful for their target niche of applications. Ruby on the other hand, while still not trying to be all things to all people, serves a wider set of needs and whims (sudo gem install kitty && kitty) and therefore I suppose that lack of inherent context can be sort of overwhelming to the uninitiated. Or even to the initiated.
The focus of documentation might be a symptom of this rather than the fundamental problem. Rails provides a single-track description of how to install and get started, but it's only able to do this because of the fact that it lives in the Ruby/Rubygems environment. If it were forced to live as a first-class resident of the general computing environment like Ruby, then I suspect that you'd have the same issues with deciding what to describe first and pissing off half your readership. (Though I do agree with you, Peter, that the page layout could be a little better organized.)
August 21, 2010 at 5:42 pm
I recently started a site (railsconsens.us) to help with a subset of this problem. The intention of RailsConsens.us is to help sort out which component is the best default solution for particular tasks involved in building a Rails site.