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:
- People new to Ruby start with learning the right thing, instead of having to learnthe best practice later ("avoid for loops")
- The language gets simpler, which means: better tool support!
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)
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
? 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" == ?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.
@@ 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.
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
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
case when true then 42 when false then 43 end
;, it would still be possible to write single-line
case when true; 42 when false; 43 end
All in all:
then is superfluous.
There are keywords for
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.
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.
The boolean operators with lower precedence are nice in some situations, for example, using
or to raise an exception when an assignment value is
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
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.