There were many (mostly small) reasons why I leaned towards Ruby back then and playing with Python now made me remember a few of them. I thought it might be interesting to write a bit about those, so here we go.

Disclaimer: This is not a rant and I know that:

• the things I prefer in Ruby over Python are super subjective
• for every thing that Ruby does “better” there’s something else that Python does better

So, treat this as an amusing personal account and nothing more than that.

Built-in functions

Probably the thing about Python that bothered me the most was stuff that would normally be methods are global functions (that often call some object methods internally). I’m referring to the likes of:

• len
• sum
• pow

You can find the full list here.

I’m guessing the reason for this (as usual) is historical, but I much prefer the way Ruby does things. E.g. str.length instead of len(str) or arr.sum vs sum(arr).

The del keyword

del is a pretty weird beast as it can:

• delete variables
• list items
• dictionary items

1
2
3
4
5
6
7
8
numbers = [1, 2, 3, 4, 5]
del numbers[2]
numbers
# => [1, 2, 4, 5]

del numbers
numbers
# => NameError: name 'numbers' is not defined

Why would someone want a keyword for removing items from lists and dictionaries instead of some method is beyond me. Ruby’s arrays have methods like:

• delete (to remove some values)
• delete_at (to remove some index)

Too many statements (and functions returning None)

In Ruby almost everything is an expression (meaning that evaluating it would result in a value). In Python a lot of things are consider “statements” - something executed for their side effects only. If you haven’t used languages like Ruby or Lisp this might sound a bit strange, but if we go back to the previous section about del, we can observe that:

• There’s no obvious way to determine if del actually removed something
• In Ruby, however, most deletions result in informative results

1
2
3
4
5
6
7
8
arr = (1..10).to_a
# => [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
arr.delete(1)
# => 1
arr.delete(1)
# => nil
arr.delete_at(0)
# => 2

That’s something that I really value and I consider it one of the bigger practical advantages of Ruby over Python.

Semantic indentation

At first I thought the semantic indentation used by Python is super cool, as it reduces a bit the typing one needs to do:

1
2
3
4
if a < b:
    max = b
else:
    max = a

In hindsight, however, I quickly realized that it also:

• makes things harder for tooling, as it can’t really rearrange indented code sections
• in editors you can’t have much in terms of auto-indenting as you type (as the editor can’t know when a block finishes without you outdenting explicitly)

One more thing - 4 spaces by default seems a tad too much to me, although that’s obviously debatable.

P.S. I feel obliged to admit I’m not a big fan of do/end either and would have preferred {} instead, but it is how it is.

The bool type

I’m not a fan of Python’s bool type as for me it’s a pretty weird duck:

• bool was added only in Python 2.3
• it inherits from int
• True and False are essentially 1 and 0

I get how things ended up the way they are, but for me it’s not OK to be able to write code like True + 1. I’m also not a fan of treating empty collection literals as False, although I definitely have less issues with this than with 0 and 1.

To compare this with Ruby:

• boolean has nothing to do with numbers there
• the only things are considered logically false are false and nil

This definitely resonates better with me.

Side note: Lately I’ve been playing a lot with languages like OCaml, F# and Rust, that’s why to me it now feels extra strange to have a boolean type that works like an integer type.

Ranges

I really like the range literals in Ruby:

• 1..n (inclusive range)
• 1...n (exclusive range)

Python has the range function that kind of gets the job done, but for whatever reason it doesn’t have the option to mark something as inclusive range.

Definitely not a big deal, but one of the many small touches of Ruby’s syntax that I came to appreciate over time.

Passing self explicitly everywhere

In Python one has to pass self to instance methods explicitly, which always seemed to me like an excessive level of verbosity. Also, that’s quite uncommon in other object-oriented programming languages.

1
2
3
4
5
6
class MyClass:
    """A simple example class"""
    i = 12345

    def f(self):
        return 'hello world'

Too many underscores (e.g. __init__)

Many special methods have names surrounded with __, which I find both odd and not very easy to type. I get why this was chosen (to avoid naming conflicts), but I don’t like it regardless.

Explicit return

I really like that in Ruby the return value of a method is the value of the last expression that got evaluated in the method. There’s a return expression in Ruby, but it’s rarely needed in practice.

1
2
3
4
5
6
def fact(n)
  (1..n).reduce(:*)
end

fact 5
# => 120

In Python, by comparison, you always have to use return, otherwise your method will return None.

1
2
3
4
5
6
7
8
9
10
def fact(n):
    res = 1

    for n in range(1, n + 1):
        res *= n

    res # notice the forgotten return

fact(5)
# => None

Not a big deal in general, but as I spend a lot of time with Ruby and various functional programming languages, it’s definitely something that bothers me.

lambda verbosity

Admittedly that’s a very small one, but I would have preferred if anonymous functions were created with a keyword like fn or fun instead of lambda. In Ruby historically they were created with lambda as well, but afterwards the -> shorthand was introduced as well.

1
2
3
4
5
# classic Ruby lambda
a_lambda = lambda { puts "Hello world!" }

# lambda shorthand
s_lambda = -> { puts "I rock!" }

There’s nothing wrong with the Python syntax per se, but I think that in general for lambdas it’s better to have a more compact syntax.

Naming conventions

Ruby predicates typically have names ending in ? - e.g. even?, odd?, digit?. This makes them really easy to spot while reading some code. Python sticks to the more common convention of prefixing such methods with is_, has_, etc and that’s fine. One thing that bothers me a bit is that often there’s no space between the prefix and the rest of the name (e.g. str.isdigit()), which doesn’t read great in my opinion.

More importantly, in Ruby and Python it’s common to have destructive and non-destructive versions of some methods. E.g. - arr.sort! vs arr.sort in Ruby, and list.sort vs sorted(list) in Python.

I don’t know about you, but to me it seems that:

• Ruby encourages you to favor the non-destructive versions of the methods, unlike Python
• Ruby’s more consistent than Python

I’m guessing the reasons here are also historical.

Triple-quoted string literals

Multi-line text literals are common in many languages, but I’m not super fond of:

1
2
3
4
x = """a multi-line text
enclosed by
triple quotes
"""

Who thought that typing those would be easy?

It’s not that HEREDOCS in Ruby are great either, but I guess they are at least more common in various programming languages.

The million Python package managers

Ruby has rubygems and bundler. That’s it. Everyone uses them. Life is simple. Things are a lot more complicated in the realm of Python where several different tools have been in fashion over the years:

• easy_install
• pip
• pipx
• poetry

Now it seems that uv might replace them all. Until something replaces uv I guess…

Epilogue

And that’s a wrap. I’m guessing at this point most Rubyists reading this would probably agree with my perspective (shocking, right?) and most Pythonistas won’t. And that’s fine. I’m not trying to convince anyone that Ruby’s a better language than Python, I’m just sharing the story of how I ended up in team Ruby almost 20 years ago.

Back in the day I felt that Ruby’s syntax was more elegant and more consistent than Python’s, and today my sentiment is more or less the same. Don’t get me wrong, though - I like Python overall and enjoy using it occasionally. It just doesn’t make me as happy as Ruby does.

I’ve long written about my frustrations with Ruby, so it feels pretty good to write for once about the aspects of Ruby that I really enjoy. Keep hacking!

P.S. After writing this I realized I had already written a similar article 14 years ago, but I had totally forgotten about it! Oh, well…

Here are a few classic examples:

1
2
3
4
5
6
7
8
Float::INFINITY.infinite? # => 1

0.nonzero? # => nil
1.nonzero? # => 1

# funny enough...
0.zero? # => true
5.zero? # => false

Naming is hard and it took me a while to narrow my list of ideas to two options:

• wayward predicates
• deviant predicates

In the end I felt that “wayward predicates” was the way to go, as it sounds less deviant.²

Common vocabulary is important when discussing domain-specific topics and it makes it easier for people to refer to things within the domains. That’s why I’m writing this short article - perhaps it will be a first step to establishing a common name for a pretty common thing.

I’ve always been a believer that naming should be both informative and fun, and that’s certainly one fun name. Wayward predicates can surprise us unpleasantly every now and then, but they are also a classic example of the flexibility of Ruby and its continued resistance to sticking to narrowly defined rules and guidelines.

That’s all I have for you today. Keep hacking!

1
2
3
4
5
6
7
8
9
bundler: failed to load command: jekyll (/Users/bbatsov/.rbenv/versions/3.4.1/bin/jekyll)
<internal:/Users/bbatsov/.rbenv/versions/3.4.1/lib/ruby/3.4.0/rubygems/core_ext/kernel_require.rb>:37:in 'Kernel#require': cannot load such file -- csv (LoadError)
        from <internal:/Users/bbatsov/.rbenv/versions/3.4.1/lib/ruby/3.4.0/rubygems/core_ext/kernel_require.rb>:37:in 'Kernel#require'
        from /Users/bbatsov/.rbenv/versions/3.4.1/lib/ruby/gems/3.4.0/gems/jekyll-4.3.4/lib/jekyll.rb:28:in '<top (required)>'
        from <internal:/Users/bbatsov/.rbenv/versions/3.4.1/lib/ruby/3.4.0/rubygems/core_ext/kernel_require.rb>:37:in 'Kernel#require'
        from <internal:/Users/bbatsov/.rbenv/versions/3.4.1/lib/ruby/3.4.0/rubygems/core_ext/kernel_require.rb>:37:in 'Kernel#require'
        from /Users/bbatsov/.rbenv/versions/3.4.1/lib/ruby/gems/3.4.0/gems/jekyll-4.3.4/exe/jekyll:8:in '<top (required)>'
        from /Users/bbatsov/.rbenv/versions/3.4.1/bin/jekyll:25:in 'Kernel#load'
        from /Users/bbatsov/.rbenv/versions/3.4.1/bin/jekyll:25:in '<top (required)>'

At first I thought that updating to the latest version of Jekyll¹ with bundle update would be enough to address this problem, but it turned out that wasn’t the case.

It wasn’t hard to guess that the csv library has been removed from Ruby’s stdlib in Ruby 3.4, as the process to move non-essential libraries out of the standard library has been ongoing for years now. So, I’ve added csv to my Gemfile, did a bundle install and… got an error that base64 was missing as well… Oh, well…

At the end of the day the solution to the problem is to add these 2 lines to your Gemfile:

1
2
3
# TODO: Remove when this gets fixed in Jekyll
gem "csv"
gem "base64"

Don’t forget to run bundle install afterwards.

Eventually those libraries will be made Jekyll runtime dependencies and when a new version of Jekyll is released with this change, you can remove them from your Gemfile. I’ve noticed there’s already a Jekyll PR to address this problem, but it might be a while until it’s merged and a new release is cut. Sadly, Jekyll is pretty close to abandonware these days and every time something like this happens I’m thinking that I should probably look more closely into the alternatives.

That’s all I have for you today. Keep hacking!

1
2
3
4
5
$ bundle
Bundler 2.4.6 is running, but your lockfile was generated with 1.17.2. Installing Bundler 1.17.2 and restarting using that version.
Fetching gem metadata from https://rubygems.org/.
Fetching bundler 1.17.2
Installing bundler 1.17.2

Bundler does the safe thing automatically, but you can easily update the required Bundler version like this:

1
$ bundle update --bundler

Pretty meta, right?

I needed to do this earlier today, when I noticed that Bundler 1.x is not compatible with Ruby 3. It took me a few minutes to recall the right way to update the required version of Bundler, so I thought to write this short article for posterity’s sake.

That’s all I have for you today. Keep hacking!

• {x:, y:} is syntax sugar for {x: x, y: y}.
• foo(x:, y:) is syntax sugar for foo(x: x, y: y).

Note that x and y are local variables that are in scope. My first reaction was “WTF???”. My second reaction was to check how this made it to the language.

The feature request ticket has a few more usage examples:

1
2
3
4
5
6
7
8
9
10
x = 1
y = 2
h = {x:, y:}
p h # => {:x=>1, :y=>2}

def login(username: ENV["USER"], password:)
  p(username:, password:)
end

login(password: "xxx") # => {:username=>"shugo", :password=>"xxx"}

What it doesn’t have, however, is any rationale behind the proposed change. Weird. I get that the idea is to emulate the syntax of JavaScript’s object punning, but I find this to be quite misguided if the end result is reduced code readability.² What’s the point in copying features from other languages if they don’t add value to Ruby itself? What’s the point of shaving off a few characters/keystrokes if the reader of the code might struggle to understand it?

I’ve noticed that everyone reacted negatively to the proposal initially, including Matz:

I prefer this syntax to #11105, but this introduces a Ruby-specific syntax different from ES6 syntax.

Besides that, I don’t like both anyway because they are not intuitive (for me).

– Matz

This was in 2018. 4 years later, however, he changed his mind:

After the RubyKaigi 2021 sessions, we have discussed this issue and I was finally persuaded. Our mindset has been updated (mostly due to mandatory keyword arguments). Accepted.

Oh, well… Sadly, no one bothered to share those convincing arguments in the ticket itself. I’m disappointed that in the end of the day the result is more complexity in the core language that serves mostly to allow writing shorter, but harder to read code. We should never forget the following words of wisdom:

Programs must be written for people to read, and only incidentally for machines to execute.

– Harold Abelson, Structure and Interpretation of Computer Programs

So, why do I feel that the new syntax makes things harder to read?

• at a glance {x:, y:} seems like a hash without values. Simple as that. Yeah, when I know about the new syntax I’ll infer that there are some locals with the same names as the keys that are currently in scope, but why bother with all of this? Explicit is (almost always) better than implicit when it comes to code readability/maintainability!
• modern editors and IDEs are already quite smart - if you want to type less, such a problem can be solved at this level (e.g. IDEs would infer that you probably want to put x after x:).
• how can I jump the local variable at point (e.g. I want to inspect it) if there’s no local variable at point?
• there are also some “fun” cases to consider:

1
2
3
4
5
6
7
8
9
10
11
# the shorthand somewhat surprisingly works with methods without params
def destroy (); puts "surprise"; end

{destroy:} # this will print "surprise"

# do you think this code behaved the same way before Ruby 3.1 and in Ruby 3.1?
# see - https://github.com/rubocop/rubocop/issues/10359
def some_method(token)
  user = double :user, id: 42, token:
  described_class.build(user)
end

Not to mention that this complicated further Ruby’s already complicated parsers and created a boatload of work for me and the other members of RuboCop’s team. Observing some of the interactions of the new syntax with other Ruby code (e.g. method calls using the new syntax followed by conditional modifiers) left me believing that the full implications of this were not carefully thought out.

I’m left pondering if I’d feel differently about the feature if it was implemented in terms of a different syntax, that’s not so ambiguous. Probably yes. Still, I’ve decided to give this syntax the benefit of the doubt and not discourage it in the default RuboCop configuration (RuboCop introduced support for Ruby 3.1 in version 1.24). As usual I’ll leave it to the broader community to figure out if something will become a Ruby idiom in the long run or not.

Adopting new syntax is usually the least effective productivity improvement.

And a language where the most easy path of change is such syntax additions is not providing the evolutionary path for meaningful improvements.

– Markus Schirp

This episode is just a continuation of the all the language changes in Ruby in recent years that I’ve found detrimental and that eventually prompted me to write my short essay Ruby’s Creed in 2019. It’s clear to me at this point that Ruby’s direction hasn’t changed and is unlikely to change. That makes me sad. I thought Ruby was all about programmer happiness.³

I can only hope that I’m in the minority and the hash punning syntax makes the majority of the Ruby programmers happy. Be happy!

Each installed gem corresponds to a directory in your local file system, so all you need to do is find out where a particular gem resides. There are several ways to do this. The first option is to use Ruby’s gem command directly:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ gem info minima

*** LOCAL GEMS ***

minima (2.5.1)
    Author: Joel Glovier
    Homepage: https://github.com/jekyll/minima
    License: MIT
    Installed at: /home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0

    A beautiful, minimal theme for Jekyll.

$ gem contents minima
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1/LICENSE.txt
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1/README.md
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1/_includes/disqus_comments.html
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1/_includes/footer.html
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1/_includes/google-analytics.html
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1/_includes/head.html
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1/_includes/header.html
...

The gem contents command is extra useful as it effectively combines something like this in a single step:

1
2
3
$ gem info gem-name
$ cd gem-dir
$ ls -l

You don’t really have to visit the folder in which the installed gem resides to play with its contents. With gem unpack you can dump the contents of any gem in the current folder:

1
2
3
4
$ gem unpack minima
Unpacked gem: '/home/bozhidar/minima-2.5.1'
# You can also specify the folder in which to unpack the gem like this
$ gem unpack minima --target ~/unpacked-gems

The main benefit of using gem unpack is that you can’t modify some gem by accident, with the added bonus that you’ll get an easier to remember directory path.

An alternative option is to use bundler to procure the gem installation directory information (assuming you’re using it):

1
2
3
4
5
6
7
8
9
10
11
12
13
$ bundle info minima

 * minima (2.5.1)
        Summary: A beautiful, minimal theme for Jekyll.
        Homepage: https://github.com/jekyll/minima
        Path: /home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1

# This is a variant of the previous command that returns only the gem path
$ bundle info --path minima
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1
# Alternatively you can use Bundler's show command
$ bundle show minima
/home/bozhidar/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/minima-2.5.1

Unfortunately, there’s no bundler equivalent of the gem contents command, but that’s not that big of a deal.

Bundler and gem actually have one more extremely useful command that will directly open the gem’s folder in your default editor:

1
2
3
$ gem open minima
# or alternatively
$ bundle open minima

Probably that’s my favorite way to navigate to an installed gem’s contents.

As you can imagine it’s pretty straight-forward to change the behavior of a gem - just go to its directory and edit some of its contents. That’s a useful debugging technique, but it opens up one question - how to restore a gem to its original pristine state? Well, turns out there’s a command for this as well:

1
2
3
$ gem pristine gem-name
# or alternatively
$ bundle pristine

The bundler command will restore all installed gems for a particular bundle to their original state.

That’s all I have for you today. I hope you learned something useful! Keep hacking!

If you’d like to listen to our conversation about RuboCop, Emacs and the future of Ruby be sure to check out this episode.

Until next time!

RuboCop’s logo was created by Dimiter Petrov (the best designer I’ve ever worked with!). You can find the logo in various formats here.

The logo is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.

1
2
3
4
5
# compact notation (works only for instance/class/global vars)
"this is #$some_var"

# standard notation (works for any expression)
"this is #{$some_var}"

As you’ve noticed you can leave out the {} which can’t be left out for any other expression. Some people find this interpolation syntax concise and elegant, but I’ll argue that it should be avoided. Here’s why:

• You can’t use this notation in every possible scenario:

1
2
3
4
5
# this is fine
puts "#{@variable}string_straight_after_without_space"

# but this means something totally different
puts "#@variablestring_straight_after_without_space"

This means that using the compact notation only when applicable forces you to introduce some inconsistency in your code. This is rarely good…

• You’re using different notations for the same basic operation (interpolation), without getting anything in return. That’s not the same with semantic use of single and double quoted strings or fail and raise.

1
2
3
4
5
6
7
# using compact
"this is #@x"
"this is #{x}"

# using standard
"this is #{@x}"
"this is #{x}"

• It’s easy to make a mistake in the context of a regular expression (as interpolation works in regexp literals). Recently I saw the following regexp - /[0-9.(),;:!?%#$?\x27\x22_+=\\\/\-]*/. There’s a subtle problem with it, that’s not obvious (unless you have a good editor, that is). The sequence #$? is interpreted as interpolation of the global variable $? (a.k.a. $CHILD_STATUS) and this regexp doesn’t work as intended.

This scenario shows that the syntax was ill-conceived.

• Inexperienced Rubyists probably don’t know about the compact interpolation notation. Few books and tutorials mention it these days, so using it your code will confuse at least some of the people reading it.

It seems to me that Ruby will be better off without a special syntax for variable interpolation. Ideally it would be removed in Ruby 3 and we’ll have one less thing to worry about in our Ruby code.

That’s all for today, folks!

As usual I’m looking forward to hearing your thoughts here and on Twitter!

Here’s an example. Now you can easily refer to rules in heated style debates with your friends and co-workers.

This is an addition that was way overdue (for which I take all the blame). I’d like to say a big THANKS!!! to Tod Beardsley who found the time I never did and got the job done (in style).

P.S. Hopefully soon the permalinks will be leveraged by RuboCop.