Ideas for Improving the Ruby Language in 2016

This article was peer reviewed by James Hibbard and Adam Roberts. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

Happy 2016, y’all! Just like many of you (I’m guessing), I always feel a sense of tabula rasa after the New Year. Anything is possible! It’s a time to make resolutions and goals for the coming year, a time to think about how I am going to improve. After writing my 2015 retrospective piece, I had the genius idea of writing a 2016 planning piece for Ruby. As I was piecing together the things I think Ruby should aim for, I realized that my opinion on the subject is far too narrow. Plus, I am not an expert in the vein of some more well-known Rubyists. I am Joe Schmoe Rubyist. I work with it daily, I’ve been doing so for a long time, but there are others that are far more qualified and still others who have other points-of-view.

So, I asked the community, hoping to get a good representation of what Rubyists think 2016 should be for the language. Here is what I got back:

tumbleweeds rolling by

Hmph. OK, I thought, I’ll try another community. Surely Twitter has some opinions. Here’s what I got back:

crickets chirping

Hmph. OK, I thought, third time’s a charm. I bet the SitePoint Ruby newsletter will generate something. Here’s what I got back:

sound of wind blowing

OK, fine. I guess the question isn’t as interesting as I thought. Or, maybe my fellow Rubyists simply don’t want to do my job for me. I know have no choice but to subject you to my thoughts on Ruby in 2016. Maybe my opinions will be so offensive/inspiring that some other thoughts will be generated in the comments.

Diversity

Let me be honest here. I am not one of those people that trumpets the lack of diversity in our industry. I read about it, but I don’t really do anything. Diversity is one of those polarizing subjects that I often avoid because I am white and male and so I don’t have a problem. I empathize (as much as I can) with others, then I get back to work. I shake my head at stories of harassment and I get back to work. I pass along a link to a great article on diversity written by someone who is affected by it, and I get back to work. I assuage any guilt about being born with the white spoon in my mouth by not making it worse. Then, I meet someone or I read something that tells me I am part of the problem. A BIG part of it. I get angry and defensive and…get back to work.

It took me a long, long time to realize the only thing I really know about diversity: I don’t know, nor can I understand, how it affects others. I can say “Wow, that must suck,” but I can’t KNOW. As such, telling someone to just “work hard” and everything will be fine is not fair. Getting upset when someone else gets upset and my using “Guys” as a general term in a Slack channel is not fair. I can’t be in their shoes, so I can’t understand the problem.

That’s great, Glenn. You stated the problem, but what can we do about it from the perspective of a programming language?

Well, the short answer is, I don’t know. I went looking around the web and I might have found some places to start. Rather than paste 1,000 links on diversity, I think I’ll mimic the five points from this article on strategies for a company to promote diversity.

1. Founders and Leaders, Get Involved

We all know who the leaders of Ruby are, so I don’t want to “name names.” Maybe it’s as little as requiring conferences to have a Code of Conduct in order to be sanctioned by the “language.” Maybe it’s well-known speakers refusing to speak unless a CoC is in place. I think a diversity policy could be something Ruby Together could create and maintain. The point is, we have leaders and well-known people in the language. Getting these folks involved goes a long way toward bringing diversity to the front of the class.

2. Collect Better Data

In order to improve in any area, there needs to be a way to measure results. How can we measure improvement in diversity. Again, I think the conferences are a great place to start. Create exit surveys that are quick and ask questions around the issues. There are no shortages of people that could come up with the questions so the data collected are meaningful.

3. Expand Your Network

From what I can tell, much of the reason that diversity is the problem that it is comes from opportunity. Or, maybe, it comes from the lack of opportunity. Programming requires some expensive tools: A computer, internet connection, books, time, etc. These resources are not abundant for non-English speaking and/or lower incomes kids. I focus on kids because most of the coders I know gained their passion for it as a child. While there are organizations that offer some options, I think the language could promote some more possibilities. For example, if the community could create a curriculum around Ruby that could be administered remotely (think, Google Hangout) it would allow Ruby resources to teach this curriculum from anywhere to anywhere. We could even record the “lessons” and make them available for download. Then, it’s just a matter of promotion to the schools that could use it. It’s a thought.

4. Think Deliberately About It

Hiring technical resources is hard. Hiring diverse technical resources is crazy hard. At my company, we have a repository of questions for each language which took a long time to create. We post our jobs on our website and through various hiring services. All the stuff most companies do. However, we also sponsor after hours programs like Night Shift to open up real-world learning to students and others that want to get more into digital development. Ruby needs to think deliberately about how it can “recruit” more diverse coders to its ranks.

5. Create a Culture That Supports Diversity

This one is a doozy. It is difficult to create a culture around a language, I think. Especially in today’s polyglot world of coding. However, there are steps that can be taken:

• Requiring a Code of Conduct for the language and its events
• Issue a policy that has no tolerance for harassment
• Exalt those that reach out and create opportunity for people to learn Ruby
• “Recruit” people from various backgrounds to help create this policy and culture

That’s it. I think improving diversity in Ruby is a big goal for 2016. I know I said it doesn’t affect me, but I do have three girls. I’d love to think that, if they choose to go down the programming/technology path, the world that greets them is one of support and respect.

Improve the Language

Duh. The “frozen string” stuff coming in 2.3 and 3.0 are examples of coming improvements. I like Ruby exploring the functional landscape for improvements and additions to the language. This should continue. Also, the concurrency issue hangs over Ruby like a spectre. I’ve said it before and I’ll say it again: MRI needs a better answer than the GIL. However, I am also not smart enough to create that answer, but I know there are folks out there who are.

What about changes that aren’t already in the pipeline? Ruby needs to stay true to its roots and continue to keep developers happy, but now? Last year, Adam Hawkins wrote a wonderful post on the “next version” of the Ruby community. It is well thought out and contains many points on how we can change our coding approach to create better artifacts. Maybe Ruby should look at the tenets in that article and start crafting the language to support, nay, encourage their adoption. These tenets are things like “Prefer Simplicity Over Convenience”, “Prefer Smaller Libraries”, and “Minimize and audit your dependencies”. There are things we should be doing, but sometimes Ruby makes it too easy to write pretty code or use 75 gems that will eventually lead us into Dependency Hell.

I would love to see some tools in core that, for example, look through my dependencies and tell me when I have too many. Pulling in something like Rubocop and putting the language behind it is another idea. Go has gofmt, which most Go developers will tell you is a Godsend (once you get used to it). Finally, I don’t know of any developers that like Monkey Patching. A language-level constraint that makes monkey patching more explicit and yells at you to let you know it’s happening might be something to consider. Removing the ability to monkey patch is probably overkill, but it has bitten us all and can absolutely discourage new Rubyists.

How about looking at the changes in other established languages for ideas? I really like much of the ES2016 stuff going on in the javascript world. Things like Destructuring Assignment and Decorators are great productivity boosts without obfuscating the language.

There have to be some language geeks out there that have more and better language level suggestions. I’d love to hear them.

Here’s to a Great 2016

Regardless of where the language goes, I know 2016 will be a great year for Ruby. It continues to be a language that makes programmers happy, and that is no small feat. I am excited about another year with Ruby and watching it change in the ever-changing technology landscape.

Please chime in with comments below if you disagree with me or think I forgot something. I know I did, so set me straight.