First thoughts on Ruby: A quick showdown vs. Python

Running sum

In Ruby, the tendency is to iterate over a number of variables with the #each method, and then you pass in a block that gets called on each of the elements. What’s immediately noticeable here is that Ruby blocks are way more powerful than Python’s anonymous callalbles (lambdas).

#!/usr/bin/env ruby

running_sum = []
args = []

[1,5,7].each do |x|
  args << x
  if running_sum.size > 0 then
    running_sum << running_sum.last + x
  else
    running_sum << x
  end
end

puts "Running sum: #{running_sum} from #{args}."

#!/usr/bin/env python3

running_sum = []
args = []

for n in [1, 5, 7]:
    args.append(args)
    if running_sum:
        running_sum.append(running_sum[-1] + n)
    else:
        running_sum.append(n)

print("Running sum: {} from {}.".format(running_sum, args))

At face value, the two aren’t very different, but these examples illustrate a fundamental difference between the attitudes toward iteration: Python uses for loops for everything, but Rubyists will do everything in their power to avoid using them.

OOP

Ruby classes seem to be both less verbose and syntactically simpler than Python classes. Both languages have a message passing way of calling instance methods: in Python, with getattr(object, name) and in Ruby via #send(). Mixins, via modules, are the coolest advantage Ruby seems to have over Python, where the closest equivalent is boring old implementation inheritance.

Both languages have an equivalent for getters and setters. In Python, this is done via a decorator, but in Ruby it seems to be a language builtin.

#!/usr/bin/env ruby

module Nameable
  def name=(name)
    puts "changed name to #{name}"
    @name = name
  end

  def name
    @name
  end
end

class Dog
  include Nameable

  def initialize(name)
    @name = name
  end

  def bark
    puts 'Woof!'
  end
end

fido = Dog.new('Fido')
fido.send('bark')
fido.name = 'Cheese'
puts fido.name

#!/usr/bin/env python3

class Nameable(object):
    @property
    def name(self):
        return self._name

    @name.setter
    def name(self, value):
        print('Changed name to {}'.format(value))
        self._name = value

class Dog(Nameable):
    def __init__(self, name):
        self._name = name

    def bark(self):
        print("Woof!")

fido = Dog('Fido')
fido.bark()
fido.name = 'Cheese'
print(fido.name)

Hidden

Finally, a serious scripting task!

I’ve been playing with 2bwm as my window manager lately. One of its major defects is that it lacks an easy way to list all hidden windows and show them. It comes with a tool, hidden, that will list hidden windows and print xdotool output for raising them, but the output looks like this:

'hidden.rb':'xdotool windowactivate 0xc003ec windowraise 0xc003ec'
'[nathan@dionysus][~/dotfiles]%':'xdotool windowactivate 0xc0085c windowraise 0xc0085c'

Which obviously isn’t sufficient for easily raising the windows. A potential fix to this is building a wrapper for dmenu that lets you easily raise hidden windows.

#!/usr/bin/env ruby

hidden_windows = `hidden -c`.split(/\n/)

map = {}
hidden_windows.each do |line|
    match = /'(.*)':'(.*)'/.match(line)
    key = match[1]
    val = match[2]
    while map.has_key? key
        key = key + '*'
    end
    map[key] = val
end

choice = nil

IO.popen('dmenu', 'r+') do |dmenu|
    map.keys.each do |name|
        dmenu.write(name)
        dmenu.write("\n")
    end
    dmenu.close_write
    choice = dmenu.gets.rstrip
end

IO.popen(map[choice])

In Python:

#!/usr/bin/env python3

import subprocess
import re

def main():
    hidden_windows = subprocess.check_output(['hidden', '-c'])
    hidden_windows = hidden_windows.splitlines()
    hidden_map = {}
    search = re.compile("^'(.*)':'(.*)'$")
    for window in hidden_windows:
        window = window.decode('utf-8')
        match = search.match(str(window))
        name, tool = match.group(1), match.group(2)
        while name in hidden_map:
            name += '*'
        hidden_map[name] = tool
    dmenu = subprocess.check_output(['dmenu'],
            input=bytes('\n'.join(hidden_map.keys()), encoding='utf-8'))
    subprocess.call(hidden_map[dmenu.rstrip().decode('utf-8')], shell=True)


if __name__ == '__main__':
    main()

The advantages Ruby has here are its simpler means of spawning and interacting with subprocesses, and the far prettier Regex syntax, both of which are inspired by Perl. Python, by contrast, has a clunkier regex engine that requires an import, a call to re.compile, and another call to regex.match(...) in order to use it.

The other thing you notice here is the bytes handling. Subprocess output returns bytes objects in Python, and they have to be decoded into utf-8 before I can do much with them.

This results in a far more verbose Python solution.

It’s also worth mentioning that the subprocess interface in Ruby is handled through an RAII-style block. In Python’s case, it looks like Popen objects can be used in with statements:

with Popen(["ifconfig"], stdout=PIPE) as proc:
    log.write(proc.stdout.read())

but that leaves the clunky Popen interface to worry about. Personally I can never remember what stdout=PIPE actually does, or which of those given modes I should be using for my process. In Ruby, I get to use fopen(3) arguments to describe how I’d like to handle fds on the subprocess. That’s an interface I’m already familiar with, and it’s intutitive.