Talks
Why Hasn't Ruby Won?
Summarized using AI
Why Hasn't Ruby Won?
by Sarah MeiThe video titled "Why Hasn't Ruby Won?" presented by Sarah Mei at GoGaRuCo 2013 explores the challenges faced by the Ruby programming language in gaining widespread popularity despite its passionate community.
Key Points Discussed:
- Ruby’s Popular Perception: Sarah Mei highlights the paradox where Ruby is loved by its users, yet there are many who have tried it and moved on, often voicing their frustrations on platforms like Hacker News.
- Criticism on Hacker News: She notes that Ruby has frequently been criticized and debated on Hacker News, where many articles, both negative and neutral, attract negative comments and misunderstandings about Ruby’s capabilities.
- Influence of Expectation: The speaker discusses how developers come with ingrained expectations from the languages they currently use, affecting their evaluation of Ruby.
- Project and Community Factors: Mei emphasizes a shift in focus from purely technical comparisons to how social and community factors influence a developer’s decision to adopt a programming language.
- Evaluating Code and Libraries: By examining how developers evaluate libraries (or gems), Mei finds that there is a balance between technical data (features and functionality) and social data (activity, popularity, and familiarity with code).
- Categories of Evaluation: Mei classifies evaluation into four main categories:
- Interface: The features and functionality of a gem.
- Activity: How often the gem is updated and how responsive the maintainer is.
- Popularity: How widely used a gem is and community support.
- Familiarity: Personal comfort with the library's syntax and style, which often stems from broader social perceptions rather than explicit technical measurements.
Significant Examples:
- Sarah Mei shares anecdotes, such as her own experience transitioning from Java to Ruby, highlighting difficulties faced by developers when approaching a new language.
- She discusses how the evaluation of libraries involves checking GitHub activity, reading documentation, and looking at community discussions—demonstrating the interplay of technical and social factors.
Conclusions and Takeaways:
Mei concludes that decisions about programming languages, including Ruby, are fundamentally driven by social influences rather than just technical merits, such as performance or features. The Ruby community’s characteristics, such as its congenial yet critical nature, play a crucial role in shaping opinions and decisions. Additionally, emphasizing better visibility into social data related to tech evaluation could help mitigate misconceptions and promote Ruby more effectively.
Overall, the talk calls for a deeper understanding of the social dynamics at play when developers choose programming languages, hoping to stimulate broader conversations about Ruby’s evolution and community engagement.
00:00:20.220
We're in the home stretch here. This is the last talk of the day. I met Sarah Mei at the first Golden Gate Ruby Conference, the one in the funky Swedish American Hall with the really uncomfortable chairs and the thrones. Sarah's been at every GoGaRuCo since then. She's spoken at a bunch of them and at other places, and it's been great watching her go from a new inexperienced speaker to someone who consistently knocks it out of the park.
00:00:54.920
With that buildup, I give you Sarah Mei.
00:01:05.040
Sorry, I forgot to say, hang out at the end. We're going to have a couple of party announcements and things like that to get you going on the rest of your evening when we're done. So don't run out the door right away. Thanks. Good afternoon.
00:01:20.520
Let's see if this works. Oh, it does—awesome! So, it's the end of the first day. How's the first day been? Yeah! I am impressed that you guys are still awake after all the stuff that's been going into your brains because I'm almost not awake.
00:01:33.479
I’m Sarah Mei, and no pressure from Josh's introduction. Here we go. This is my company, the Ministry of Velocity. We're a small consulting shop here in San Francisco. We just got going last month, actually. My logo is new, and I'm very excited about it. I have shiny new business cards too, and I think I've already made several of you take one.
00:01:55.920
We work on Rails, JavaScript, iOS, and assorted other things. We help you go fast—that’s the idea. If you're looking for that kind of thing, come find me, and I will happily give you a business card because I love them so much.
00:02:18.120
I’m also one of the founders of RailsBridge. You may know RailsBridge from programs like the RailsBridge workshops for women, which have taught Ruby and Rails to thousands of women in over 100 events. What you may not know is that we're also starting an initiative to reach out to communities of color. We did a joint event with the Black Founders group here in San Francisco a few months ago, and we're looking to do more events like that as we continue to work on the gender gap.
00:03:06.360
Has anyone in the audience been a student at RailsBridge? Yay! Anyone been a teacher? Who's been both? Alright, this is awesome.
00:03:15.120
I started this talk off with a question, and it's kind of an odd one, so let me explain a little bit about what I mean. You all use Ruby every day, and you love it. I'm not even going to ask for a show of hands because I know you do, otherwise you wouldn’t be here.
00:03:31.680
But for every one of you, there are a hundred people out there who have tried Ruby and discarded it. Most of them seem to post a lot on Hacker News.
00:03:39.000
Ever since Rails hit 1.0, Ruby has been one of the favorite whipping boys of Hacker News. Just witness a few of the articles that have made it to the front page of Hacker News in the last few years.
00:03:54.180
A bunch of the articles on this list are FUD—Fear, Uncertainty, and Doubt—about Ruby, and those are really popular. But even the ones that are neutral or positive about Ruby, especially the ones that are positive, attract really horrible comments about Ruby and what it's good for.
00:04:13.980
Now, everyone knows not to read comments on Hacker News, right? You never read the comments; they're a cesspool. I was going to get some screenshots of comments, but I felt too dirty just going in and looking around. I need to shower anyway.
00:04:29.460
It's not just folks in other communities that disparage Ruby; we in the Ruby community poke outward as well. We’re constantly taking jabs at people who use other lesser languages. We figure they must work somewhere like here, right? Like they do Java or Python or PHP. Oh my God, those people! Yet, I'm certainly guilty of that myself.
00:05:00.600
Why can't we save them with Ruby? I have a friend who's been trying to switch from PHP to something that pays better, of course. So I've given her the pitch for Ruby.
00:05:11.220
But it's been interesting to watch her thought process as she navigates through this process of switching languages. I started wondering if there was something that we could learn from her thought process because when you ask developers to evaluate languages, what often happens is they come into it with a bunch of subconscious expectations based on their current language.
00:05:36.240
I mean, when I switched to Ruby from Java, I wrote Ruby code that looked like Java code for pretty much the entire first month. I used for-loops; okay, that's how bad it was. But there are lots of other things beyond the actual code that people consider when they're evaluating a language.
00:05:50.220
For example, no one starts projects in Smalltalk anymore. This is an amazing picture, and it's not because Smalltalk isn't wonderful to work with; it is. But just try posting a Smalltalk question on Stack Overflow and see how long it takes to get answered. Good luck trying to hire a senior Smalltalk developer; they're even harder to find than senior Ruby developers.
00:06:13.500
The number of people who use a given language and how active they are in public has a huge effect on people's decisions around languages. I wanted to understand better what the non-technical influences on people's decisions were because I had a hunch that those influenced people's decisions more heavily than features, performance, or other technical details of a language.
00:06:22.140
Basically, I think people's decisions about programming languages are based largely on social factors rather than technical ones. But at this point, I had like a sample size of one, right? My PHP friend. So I figured that I could understand this better by looking at it at a smaller scale where I could collect more data points.
00:06:56.520
While I don't know a lot of people who are making the language decision, I know lots of developers who make similar but smaller scale decisions all the time. Programming is constant technical decision-making; it operates at different scales every day.
00:07:01.680
When we're working on a project, we make hundreds of micro-decisions about where code will go and how to test it. At a larger scale, and slightly less frequently, we make decisions about which gems to use. At an even larger scale and even less frequently, we make decisions about when it's time to switch frameworks. Finally, at the largest scale and even less frequently, we make decisions about when to switch languages.
00:07:15.900
While I don't know anyone who makes the language or framework trade-off regularly, I know lots of people who look at gems all the time. I started by asking a bunch of my colleagues to describe how they evaluate gems with similar functionality. It turns out everyone starts in pretty much the same place.
00:07:31.200
They begin by looking at the interface of the gem, the features, the functionality, and the usage of the code. This information is easy to find; it's usually in the README on GitHub. For instance, let's say you're looking for a gem to make HTTP requests.
00:07:44.520
A quick Google search turns up HTTP Party and Faraday. Assuming you don't discard HTTP Party because you can't pronounce it, you look at the README for each project and skip to the usage. This is what you find: HTTP Party has class methods that you can call directly or it has a module that you can mix into your own class, while Faraday takes a different approach and gives you a connection object that you can use to make calls.
00:08:02.700
This information by itself is not enough for most people to make a decision—just like the features of a language aren't enough to tell you if it's worth using. The features of a gem aren't enough either.
00:08:07.560
So I asked people to enumerate everything they do to evaluate a gem. Here's what I got: They look at the README on GitHub; they look at the date of the last commit on GitHub; they look at how many issues there are and how old they are; they examine the comments on the issues and pull requests to see if the maintainer is a jerk.
00:08:27.840
They explore the number of blog posts they can find when filtering on Google to the most recent year; they check Ruby Toolbox to figure out the relative download popularity; they look at RubyGems to check their release schedule and how often they release; they check Stack Overflow to see how many questions there are and how many are unanswered; they ask people they know from work, they ask Twitter, they visit Hacker News and read it; they consult other developers, they look for official documentation, books, screencasts, and podcasts; they evaluate the code directly; at times they even evaluate the tests; and sometimes they just try it out or build a sample app to see what it does.
00:08:48.840
This is quite a long list. It's not exhaustive; I could put more stuff on here. I want to point out a few interesting features of this list. The first is that different people rank these differently. I usually poke around on GitHub first to establish that it has a reasonable interface and reasonable activity, and the next thing I usually do is ask my co-workers for input.
00:09:04.799
But one of the people I talked to works at a company where displaying ignorance is not good for his career, so he never asks his co-workers for input on anything. He basically pokes around on GitHub and then goes straight to the documentation and tutorials.
00:09:33.240
The second thing is that we rarely do all these things for a given evaluation. Maybe we do if we're weighing Rails versus Sinatra, but if it's like HTTP Party versus Faraday, we probably don’t do all of them. The last observation is that this list changes as our community changes.
00:09:55.740
For example, before Rails, a lot of discussions about Ruby libraries took place on the official English language Ruby mailing list, but today it wouldn’t occur to any of us to post there if we’re trying to pick an HTTP gem.
00:10:20.520
The way we collect and use this data is complicated. We weigh things differently at different times; different people consider different subsets of these things. Is there anything we can pull out of this? Most of the data is not technical; it's social. It's about the people involved—information about the maintainers and the users of a project.
00:10:34.560
There is some technical data. Let's pull that out first. Here's what everyone starts off with: they look directly at the features and functionality of the gem, not the internals—just the external interface for now.
00:10:49.320
Then there’s information about the activity of a project: how often it's updated, how likely one is to get help from the maintainer, or get a pull request merged. We can separate this out nicely.
00:11:08.520
What’s left is a big chunk of information about the project's popularity among developers. Have any of my co-workers used it? How easy will it be to find help when I run into a problem? How likely is it that someone else has already fixed a bug by the time I encounter it? We’ll chart that out.
00:11:28.200
We’re left with a couple of outliers: evaluating the code and evaluating the tests. These don't fit in with the other groups we established.
00:11:37.800
The first three categories—interface, activity, and popularity—are straightforward. There are well-known sources of data for this information. But the left-overs we have are a bit fuzzier.
00:11:47.220
It's about familiarity: Is this idiomatic Ruby? Does the maintainer share my testing strategy? How much does this code match up with what I would write if I were going to roll my own? How does this code feel like other code I've seen? Let’s call this familiarity.
00:12:02.640
So those are the broad categories of data we consider when evaluating a gem. Interestingly, only one of these categories is technical data—the interface. All other three categories have social components. Popularity and activity are almost purely social, and familiarity is partially a technical judgment and partially a social one.
00:12:09.240
Certainly, by volume, we consider more social data than technical data. What happens fairly often in Ruby is that you have two gems that both have sufficient interfaces; they allow you to perform GET requests and POST requests.
00:12:30.660
They are about as popular as each other and about as active, so the final judgment really comes down to whether or not the code feels good.
00:12:58.680
Familiarity is an intuitive judgment, but that doesn't mean we can't follow the thought process that someone uses when evaluating a particular code. HTTP Party has class methods or a module you can mix in, while Faraday gives you a connection object. Here's a thought process that one of my colleagues described to me: 'I don’t like mixing helper methods into objects. Why?'
Explore all talks recorded at GoGaRuCo 2013
+10