Less Feature-Rich, More Fun

Ruby was created in 1993 and has come a long way. The preferred style of coding has changed quite a lot and solid best practice has emerged (though, as always, one size does not fit all). At the same time, Ruby's tool support could be better, the language is still too complex. Maybe, the time has come to remove some features from Ruby.

Which is always hard, because it will break existing code.¹ But it can still be worth it:

What follows are some opinionated examples of what could be removed from Ruby without breaking too much code (hopefully).

Ten Ruby Features which Could Be Removed Without Too Much Trouble (More or Less)

1. for and in Keywords

For loops are rarely used in favor of semantically almost similar alternatives like Array#each or Integer#times. They are even a little slower than calling each directly. Also see: The Evils of the For Loop

2. ? Character Literals

The question mark allows you to create single-letter strings. This was indeed useful when writing code that should work for both, Ruby 1.8 and Ruby 1.9:

"Idiosyncratic"[0] == ?I

While the return value in Ruby 1.9+ is "I" on both sides, in Ruby 1.8 it was 73 on both sides, so it would still return true. Support for Ruby 1.8 ended in 2013, so there is no benefit of the ? syntax anymore.

3. @@ Class Hierarchy Variables

You should not use class variables! They will confuse almost every newcomer and should be removed from the language. Some alternatives:

To be fair: Removing class variables would break more code than any of the other suggestions on this page. Too big to remove.

4. then Keyword

If statements usually separate the condition from the body using a newline or ;:

if true
  p 42
else
  p 43
end

However, you can optionally use the then keyword:

if true then
  p 42
else
  p 43
end

There exist two case where then makes sense. One is one-liners:

if true then p 42 else p 43 end

But even they look better with the ternary operator (?:)

p true ? 42 : 43

The other is single-line when statements:

case
when true  then 42
when false then 43
end

Going with ;, it would still be possible to write single-line whens without then:

case
when true;  42
when false; 43
end

All in all: then is superfluous.

5. TRUE, FALSE, NIL constants

There are keywords for true, false, and nil. They all have a predefined associated constant, which can be redefined: TRUE, FALSE, NIL = nil, true, false. There is no reason to keep them around.

Update: Removed in Ruby 3.0

6. Implicit Creation of Local Variables via Regex Matching

Accessing the last regex match: There is no need for =~ to be able to create local variables, but only if both operands are in the right order. Using $~[:group_name] instead is more explicit and still very concise.

7. and, or, not Keywords

The boolean operators with lower precedence are nice in some situations, for example, using or to raise an exception when an assignment value is nil:

a = dangerous_operation or raise "dangerous operation failed"

But is it a strong enough reason to keep the keywords in the language? They already have created lots of confusion for Ruby learners.

8. Secret CLI Options like -s and -x

When is the last time you used $ ruby -s or $ ruby -x?

9. Symbols

Semantically, symbols and frozen strings are very similar. Symbols should become a shorthand syntax for frozen strings!

10. Flip Flops

This blog covers a lot of Ruby's lesser-known features. It does not even have an episode about Ruby's Flip Flops.

¹ Maybe, we can have strict/quirks modes via a magic comments? More complexity, though.

More Idiosyncratic Ruby