Taking care of a Ruby on Rails project at work while the original author
is on vacation.
How do I put it ... It's not pleasant. Implicit stuff here, unknown
convention there, terrible documation (the Rails docs, I mean). It reads
like minified JavaScript. If you don't already know the project
intimately, it is so unbelievably hard to understand the code.
I sometimes spent half a day to figure out what *one* line does.
I can't really blame the author for that. He basically grew up doing
Ruby and Ruby on Rails. He fully embraced it. Me, I'm a mostly a C and
a bit of a Python guy. Totally different thing. Nothing is similar.
Not even this: In Python, you'd write code like this:
def my_function():
if some_condition:
foo = ['bar', 'baz']
else:
foo = ['something', 'else']
return sorted(foo)
He routinely does it the other way around:
def my_function
foo = if some_condition
['bar', 'baz']
else
['something', 'else']
end.sort
end
A mixture of control flow and assignment. And, of course, no `return`,
because everybody knows that it'll get return automatically!
This is the simplest example I could come up with. There are tons and
tons of shortcuts. This is so hard to read ...
Another example:
def my_function language
{de: :de, en: :en}[language]
end
Can you guess the *intention* of this function? I mean, a hash map that
maps values ... onto themselves?
After a while, I realized that Ruby returns `nil` if you request a key
from a hash map that does not exist. So, our guess is that this function
wants to check if `language` is a valid value. (In the original code, it
wasn't just a simple variable called `language` but a two line long
chunk of "try to parse a string using regexes, use the first match of a
group, and if nothing works, just use `nil`". Again, with tons of
shortcuts.)
A more explicit version in Python:
def my_function(language):
if language not in ('de', 'en'):
return None
else:
return language
Yeah, it's more lines of code. But everybody understands that right
away.
He follows the mantra "it's always better to have less code". No, sorry,
mate. I strongly disagree.
You can do stupid shit in every programming language, but it feels like
Ruby and Ruby on Rails strongly encourage you all the time to take all
shortcuts that you can find ...
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
On a similar note, a nice story of why type inference is a bad idea:
<
http://blog.fefe.de/?ts=a0cf97c9>
Guess what: It's hard to read.
Why is it that after so many decades, we still don't want to accept that
it's more important to produce code with good readability than to be
able to quickly produce code?
Rust and Go made the same mistake. Type inference. "It's so convenient."
Why ...
Type inference is one of the reasons why I'm so disappointed by Rust.
See, Rust cares about types a lot and helps you avoid making mistakes.
But the source code doesn't reflect that. Yeah, the *compiler* knows
about the types, but the *human reader* does not.
