Why Ruby Is More Readable Than Python

Ruby, like so many other good things, is best enjoyed alone :-)

I've loved every Ruby codebase that I've written. I still consider it one of my favorite programming languages, and (in pedagogical terms) one of the best languages for learning "practical" functional programming (point-free style, blocks as intuitive closures, &c.). But when I work with others, I find that all of the things that I love are obnoxiously clever to others, and that the things they love are obnoxiously clever to me.

Python isn't immune to that kind of cleverness, but subjectively it's not as common. I chalk that up to the higher pain threshold for doing really obnoxious metaprogramming in Python, a lower community tolerance for unidiomatic interfaces, and (broadly) better QA tooling (RuboCop is great, but MyPy + isort + Black + flake8 is really hard to beat).

I find Ruby to be more straightforward than Python. In isolation, I’d argue Ruby is greatly more readable and understandable than Python.

In practice, Ruby code isn’t. Once someone starts doing advanced meta programming, get the shovel, because you’re going to kill whoever wrote it and need to bury the body.

Rails largely gets away with this by having opinionated design, good documentation, and a large user base who have already written answers to your questions.

Interesting. Even with the examples given, I found Python considerably easier to follow, with the possible exception of the inheritance example.

Just goes to show how subjective it all is!

“ I didn't work hard to make Ruby perfect for everyone, because you feel differently from me. No language can be perfect for everyone. I tried to make Ruby perfect for me, but maybe it's not perfect for you. The perfect language for Guido van Rossum is probably Python.”

…

“I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language.”

- Yukihiro Matsimuto

I read through the article waiting the whole time to see that "this is more readable", but I found nothing. Also I'm not sure if the Python examples are so blatantly wrong on purpose or if the author read one Python tutorial beforehand and then decided to write this article. For example this:

> In Python, you will never do post.__str__ for example. Instead, you’ll do str(post)

No you dont. You do the same thing you did with `puts post` in your Ruby example: `print(post)`, which will call `__str__()` method.

> In Python, it’s easy to accidentally write to the count attribute — which can break your program.

To address writing into attribute directly - you can use @property decorator, which will stop you into writing into given attribute, unless you add a setter.

However the main problem in this fabricated example wouldnt be that you can break your program by accidentally writing into an attribute. I'm not sure how common is it in Ruby, but mixing the instance variables together with class variables this way seems like a bad design, and that is what will break your program.

Regarding the Django example - ok that is far from perfect, but comparing a framework which maintains backward compatibility for years with code you write from scratch without worrying about anything is barely a fair comparison.

Until metaprogramming, autoloading, DSLs and everything that eventually makes Ruby code unreadable takes place due to personal preferences.

Ruby is clever, it can be beautiful, but I've never seen a good codebase using it grow well without enforcing strictly opinionated ways of writing it to ensure maintainability. Which breaks a lot of the expectations of some Ruby developers that chose the language because they like to write it in their own way.

I initially thought this article was being sarcastic. After each comparison when they said Ruby was more readable I thought they were joking, until we got to multiple inheritance.

One of my favorite HN comments talks about the differences between Python and Ruby way back in 2009: https://news.ycombinator.com/item?id=682364

Still applicable I think.

Both Python and Ruby can become extremely hard to read if you start leaning heavily on the metaprogramming parts. When I was learning ruby on rails circa 2012 I frequently got frustrated with libraries writing their own DSL.

Moving to Python from Ruby, one very early scarring experience was battling trying to get the length of a string, before eventually discovering len() - a free function, whereas in Ruby (OO purist that it is), everything is a method.

Well I thought this was rather silly and counterintuitive of Python, and said so in some forum or other, whereupon i discovered the very passionate views of folks who have come down hard on one side or other of this debate.

So, lesson learned: keep one's opinions on such matters to oneself, as one man's banquet is another's poison. In which vein, it would be splendid if this comment did not occasion another screed about the manifest glories of __len__ to enlighten us heathens.

Subjective opinion presented as fact? Say it ain't so.

Currently I’m working in a large ruby codebase and previously I was working with Python and Go. Until this moment, I do prefer Python.

Ruby is too flexible for me to ever want to work on a Ruby codebase.

Also, those ruby examples aren't readable, I have no idea what your sigils and double sigils are doing beyond giving me Perl flashbacks.

Does Ruby have support for just exporting functions around? All these examples are class based. When I was a Python programmer, we found functions scaled infinitely better over time (with the exception of data classes, unfortunately) for complex business logic especially.

Both options looked bad from the start, and only got worse. Why do I need a class with getters and setters, in-place mutation, a pointless toString and a (mutable!) static count variable, instead of:

  {
    title: “a grumpy programmer’s rant about objects”, 
    body: “Wait, hear me out y’all…”,
    published: true
  }

Both the Python and ruby examples have no post-ID, so mutating in-place is an extra-bad idea. It should not be the default.

Why does the static count variable exist? These things are all stored in some list (memory, db, whatever, perhaps multiple places) and we can count any subset of those that fits our purpose. What happens when I’m asked to add draft posts? Should I only update the count only if published == true? It depends on whether I’m looking at “number of blog posts” as a user or “my drafts” as an author.

Why does the toString exist? Nobody uses those in real app code for end-users, they are a convenience for developers. Use a better REPL/debugging environment that can handle pretty-printing data. If you need more customization, use a function.

Please, just use plain data wherever possible. Please use languages that support and encourage using plain data. Please push mutation to the edges of the system, and please carefully control the in-place updates. The computers in our pockets are more powerful than anything that existed on earth before 199x, yet the industry is still acting like we’re running them on 8086 microprocessors with 640k RAM.

Let’s grow up and think more deeply about building robust systems which can evolve with changing needs.

EDIT: Changed published to true, because this is basically that.

I find it odd that getters and setters are implemented in Ruby … manually. attr_accessor is the idiomatic way to do it (or attr_reader / attr_writer if you want more granular control).

Hmm. I knew how to read python before I bothered starting to learn it. There are language primitives in Ruby that I have no experience with. So the premise is simply wrong...

I think he proved the opposite case -- and gave examples, too!

Years ago, I tried to teach myself Ruby because Rails was all the rage.

But I could not, for the life of me, remember which symbol means private, which meant protected, which meant public. There was no affordance to the symbols, and I have never seen any other OOP language that does that.

And then I moved on to Python and Django, and found the lack of real private/protected/public in the Python world utterly liberating. The more I programmed in Python, the more I appreciated “we’re all consenting adults”.

The more I thought about it, the less reason I find in trying hide anything via protected/private. For example, if I understand correctly, in .NET/Java, anybody with enough determination (and runtime permission) can use your protected/private stuff via reflection anyway.

Not on topic but a little rant about dark themes. After years of reading code displayed in dark mode on a white page (high contrast), I still wonder why. It's really hard to see, at least for me. Most of the time, I end up selecting the whole piece of code to have white text on a black background - it's not as good as black text on a white background, but it's much better than dark blue or dark red on a black background.

This interesting article uses dark red for operators (".", "=", "<", etc.). This is one of the worst choices. On a dark background, please do not use dark color.

I write Ruby for a living and I'd argue than in my case it has to do with blocks, which are so much more relatable coming from C# than tabulation-based code blocks... To me, it feels much more natural.

What I enjoy about Ruby over Python the most is not intricacies of the OO implementation or delicacies of metaprogramming, but a good support for functional style. In ruby, statements are expression-like, they have a return value. Also, with Ruby it's easy to break down code to consecutive pure blocks.

Condiser the following task: take /proc/kallsyms in Linux, that lists symbols in kernel, in an '<address> <type> <name>' format, like:

  0000000000000000 A fixed_percpu_data
  0000000000000000 A __per_cpu_start
  0000000000001000 A cpu_debug_store
  0000000000002000 A irq_stack_backing_store
  0000000000006000 A cpu_tss_rw
  000000000000b000 A gdt_page
  ...

let's make stats on it -- how much of each type is present? Wanna get the result ordered by number of occurrence.

In Ruby:

  # ruby -rset -e '$<.readlines.to_set.classify { |l| l.split[1] }.transform_values(&:size).sort_by { |_,v| v }.to_h.tap { pp _1 }' /proc/kallsyms 
  {"V"=>1,
   "w"=>2,
   "a"=>14,
   "R"=>98,
   "W"=>154,
   "A"=>328,
   "B"=>655,
   "D"=>2910,
   "b"=>3097,
   "T"=>22289,
   "d"=>34424,
   "r"=>49904,
   "t"=>55346}

Of this method call chain, first and last are impure (as they do I/O), the intermediate ones are pure.

In Python you'll have to grind through it procedurally. (Unless you use reach out to some advanced libs... https://gist.github.com/richardbann/5b363096de6b3de2e8178cce...)

There's more than one way to write the corresponding Ruby snippet. If I had been writing it, I might have translated it something like this:

    class BlogPost
      class << self
        attr_accessor :count
      end
      self.count = 0

      attr_accessor :title, :body

      def initialize(title, body)
        @title = title
        @body = body
        @published = false
        BlogPost.count += 1
      end

      def publish!
        @published = true
      end

      def to_s = @title
      def count = self.class.count
    end

This avoids needing to understand what `@@count` means, and lets you use the same syntax as in python: `BlogPost.count += 1`.

Or, if I were in a codebase using static type annotations with Sorbet, I'd do something like this[0]. To each their own, write code in the language and style that makes the most sense to you.

[0] https://sorbet.run/#%23%20typed%3A%20true%0Aclass%20Module%3...

This lost me when the first example showed named arcs in the python version, and none in the Ruby version.

Gues what? They aren’t required in python either

The article closes with this thought:

> While both languages are much easier to read than say, PHP or Java, [...blah blah blah...]

Which leads me to wonder: Have there been any serious studies of the readability of programming language syntactic and semantic conventions? For instance, a good friend of mine (whose day job is working as a software consultant, and whom I imagine would disagree with the author's assertion) finds it extremely difficult to understand python code in particular due to his dyslexia, and I wonder how common such problems are, both as a % of people and % of programming languages.

to me it comes down to taste.

in those examples, python looks more readable to me (and easier to write) because it is more concise. the less code that i have to scroll through, the more readable it is. (to a degree. APL is compact but not concise because it uses short symbols for things that would be readable words in other languages)

getters and setters are boilerplate. if you want them, you can use them in python too. common operations should be easy, uncommon operations should be possible. python is doing that. ruby in this case forces me to treat a common operation the same as an uncommon one. personally, i only want getters or setters if they do something beyond plain return and assignment of the value, like a range or type check for example. that way, when they actually matter, they stand out in the code. the same goes for access to class variables.

i get it, there is some beauty in having every class look the same. you can just write it all down without much thinking. and when you need a custom setter, it's already there and easy to modify, whereas in python i may have to do some extra work, add the setter, and make sure its use is enforced. it's a trade-off.

+() vs __add__() to define a + operator? sure, +() looks more elegant, but in the end the code is the same, __add__() stands out well enough, and while i too would prefer +(), it's not something i'd bother complaining about. there are other things that are more irritating.

and finally, single inheritance vs multiple inheritance. an age-old discussion with good arguments on both sides. pick your preference.

Surely there's a correlation between ease of reading and ease of compilation?

I'm thinking in terms of avoiding back-tracking in your syntax.

E.g.: regices are hard as shit to read, and I don't think that back-tracking helps

   (ab + c)*

Or

   *+(ab, c)

The first says ab, no - it's the union of ab and something, something is c, no - it's one or more of those.

The second says one-or-more of the union of (ab) and (c).

Why haven't languages pushed that way?

Ah, that's why my analytics is showing HN traffic. OP here. Thanks for sharing my friend.

I'm not a Ruby programmer but I wrote this post while learning Ruby and after having read through the entire Sinatra code base. I was surprised at how much easier Ruby code is to read even though I've been a Python programmer for the past 6 years.

Having worked on both python and ruby applications in my professional life, I am shocked that anybody could claim that ruby is in any way ... readable.

I look at the __init__ and initialize methods in the examples here and remember why I don't want to use either of these languages. What useless boilerplate, just to define a simple type.

I read the article and I am more convinced that Ruby is, if anything, more complicated than anything.

The dunders in python make my eyes bleed. It stands out in an otherwise neat language, due to its significant whitespace.

I didn't get Python until it was pointed out to me that Python is procedural. The objects in Python is more like how I wrote "object-oriented programming" in Pascal with records and procedures. All the intuitions one would expect in Ruby with respect to encapsulation is inverted in Python.

I have noticed that this extends to Ruby's approach to bundler, and Python's approach to virtualenv/et al.

Knowing this made me less irritated at Python.

What is your view on why did Ruby missed Python's current spot?

Did it miss the data science/ML boat?

With better unicodes I wish computer language could use fancier characters to express loops, conditionals and in general without using the english language. goodbye to [if, else, switch, break, lastly, each etc..] let us crate a language that uses no letters but unicode symbols to express abstractions. Like emojis.

Maybe I am an outlier, but the few jobs I have had with a ruby codebase have been super fun and relatively easy to pick up. Every project has a learning curve, and I have experienced some pretty bad ones that were not written in Ruby.

Nice to see some of the differences clearly laid out.

It's not.