From Pythonistas To Rubyists
DISCLAIMER: I’ve been coding in Python for the past 4 years. It was my very first programming language. While I love Python, I tried to be as unbiased as possible.
This is not a stab at the Ruby programming language. I love Ruby too. This is simply nothing else but a comparison between the philosophies of both languages.
Below is the infamous Zen of Python.
1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases arent special enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one-- and preferably only one --obvious way to do it.
14. Although that way may not be obvious at first unless youre Dutch.
15. Now is better than never.
16. Although never is often better than *right* now.
17. If the implementation is hard to explain, its a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea -- lets do more of those!
19 lines of rules primarily on how Python code should be designed and crafted. This is the philosophy of mostly every Python programmer out there. We are religiously binded to consider these design laws prior to writing our code, and about 99.9% of the time, we do.
One of the biggest arguments Ruby developers have against the Zen of Python are always about line 2 and line 13, and let me tell you why that’s bullshit.
Line 2 #
Let’s talk about the first argument about the following line:
2. Explicit is better than implicit.
Remember that one girlfriend (or boyfriend) you have had at some point in your life, the one that would feel angry or upset about something but they wouldn’t tell you anything about it, so you have to go through the process of figuring out what their problem is.
You would ask:
Are you okay, babe? and they would respond with something like: I'm fine. even though that’s a complete lie, and it goes on and on until eventually you get her to tell you what’s wrong and then you fix it and then everyone’s happy, 6 fucking hours later.
That is like the most pointless, most unnecessary, most annoying thing on this planet. Just tell your partner what’s wrong as soon as they ask. Don’t be complicated by trying to be creative in your announcements of how you feel.
This analogy applies to the Ruby developers who don’t agree with line 2 of the Zen of Python. Explicit is always better than implicit because it’s how it’s supposed to be. Just say what it is. Don’t be annoying. If you ever have to decide between making something explicit and making something implicit, please pick the former. You are making everyone’s lives a lot easier by doing so.
Line 13 #
Moving on to the second biggest argument Ruby developers have:
13. There should be one-- and preferably only one --obvious way to do it.
Ruby developers constantly boast about the fact that there’s so many different ways to do something in Ruby. It allows your inner creativity to explode with the code you write. There’s so much magic, and so much syntatic sugar – and that’s a great thing, right?
Unless, you’re learning the language for the first time, of course. Then the whole philosophy of having one million different ways to do something has the guaranteed posibility of confusing a beginner. Allow me the honor of showing you yet another example.
Characters #
- Sophie the Instructor
- Francis the Pythonista
- Alice the Rubyist
Sophie: Could you guys write code in your respective languages that would return the first letter of each string in an array with three strings, please?
Francis: Easy peasy lemon squeezy.
array = ["This is the first string.",
"This is the second string.",
"This is the third string."]
for string in array:
string[0]
Alice: Sure…
Alice: thinks to herself: I forgot whether or not I should use an each loop, a select loop, a collect loop, a detect loop. Hmmm. Well, I could try an each loop first, but I’m pretty sure collect loops return the new array, and that’s probably what she wants, right? Okay, let’s try it out and see if it works.
array = ["This is the first string.",
"This is the second string.",
"This is the third string."]
array.collect do | string |
string[0]
end
Do you see what happened there? In Python, there is only one way ever to iterate over an array. That is with the for keyword. There is no other way around this, no sugar coating, you know exactly what you’re getting with this approach.
In Ruby, however, there are multiple different ways to iterate over an array. Which means you have to make a decision. Making a decision takes time. This also applies with Ruby’s philosophy on implicit vs explicit. Making a decision of whether or not you need to include self takes time. This makes you a slower programmer than your Python counterpart.
And that’s totally fine if it means your code is more efficient, but that’s not what it means at all. In fact, using one of those fancy syntatically sugar coated methods like .each and .collect are slower than simply using for directly. So not only are you a slower programmer, not only are you not getting any efficiency to compensate for your slowness, but it turns out that every approach you’re taking in Ruby is completely unnecessary and strictly for the sake of readability.
Having rules and having some sense of order isn’t a bad thing. It doesn’t necessarily limit your creativity either.
So, again, to Yukihiro Matsumoto: Making Ruby a tad bit more linear might make the world an even better place.