Hacker News Reader

Comment by ouid | Hacker News Reader

I dunno man, I don't think the languages are properly comparable for readability.

  5.times do

    print "s"  

  end

View on HN

It's a double-edged sword. The code's behavior is apparent in that simple example, but things get considerably more difficult to understand when you're dealing with monkey patched methods and dangerously clever method_missing magic in non standard library code.

Yeah, I had to deal with a perl port from a ruby library that had kept most the rubyisms in. The really disturbing thing about it was the Frankenstein levels of autovivification involved. Fortunately someone (not me) is going to get paid deal with that soon.

You can certainly find snippets that are simpler in Ruby than in Python; they're just not the majority. Consider a slightly more complicated case where you need to print out items in a range with some modification. Idiomatic Ruby:

   (0 ... 5).each do |x|
     print (x + 1)
   end

Idiomatic Python:

   for x in range(0, 5):
     print (x + 1)

To understand Ruby, you need to know what || does, and the overall sequencing of the words as you read that construct is somewhat unnatural for English. Python is comparatively easier to parse with no prior background.

It is definitely possible to write Ruby in a way that's still highly readable. But from what I've seen of real world Ruby code, that's not the way it tends to be written - idiomatic Ruby values expressiveness and DRY, so you see blocks and various terse syntactic sugar used all over the place; lots of "clever" code in general. There's nothing wrong with that - I generally prefer expressiveness over readability myself - but many people do not.

I see your point. But I'll take the liberty to use part of your comment as my own response: "You can certainly find snippets that are simpler in Ruby than in Python, and vice-versa". Now that is something I 100% agree with (I added the part after the comma btw).

Basically what I'm saying is that the differences are very minor compared to differences vs, for example, other languages (Java, Scala, C++, etc). So from that perspective there's not much to complain about. I just have a slight bias towards Ruby, I find it a little more readable (in a small way).

While it is true that with ruby you have to know more syntax, without previous knowledge of either language you caught on pretty fast.

To me it is more expressive of my intent to say "0 to 5, for each, do something" than "for something in the 0 to 5 range do something"

Also you happened upon what peeves me most about Python, you are not actually looping from 0 to 5 since range is inclusive at the start, but exclusive at the end. So while (0..5) gives you 0, 1, 2, 3, 4, and 5, range(0,5) will get you just 0, 1, 2, 3, and 4. Of course it's easier if you think that range() is rather "I want to take X steps", so if you just want to step 5 times range(5) does exactly what you need it to do.

I think this is mostly to keep in line with indexing, where you have that same sort of semi-inclusion.

'example string'[3:8] # gives you 5 characters.

But wouldn't you rather just say: "hey, starting from the 3rd index, give me 5 letters" like

    2.3.3 :001 > 'example string'[3, 5]
     => "mple "

Instead of having to think before hand what indexes thous would be.

It depends on what you're trying to do. It's pretty common with strings to ask for "everything excluding the first and the last character", for example, and then you want the end index (counted backwards), not length. Another common case is when you looked up a substring and got an index, and now you're slicing the string around that index.

But there are also many cases where length is more desirable.

Ditto with ranges - both end-inclusive and end-exclusive ranges are useful in different cases. I kinda like the fact that Ruby lets you choose, but I think that .. vs ... syntax distinction is too subtle and likely to cause bugs.

I kinda like the way Nim does it: .. for inclusive, and ..< for exclusive - e.g. 1..<10. They also use special syntax for count-from-end, instead of negative indices, which is also a good thing IMO (the decision to index from start or from end is usually something that's not going to change at runtime; but with negative indexing, it might inadvertently do so if you underflow when computing the index).

  1.upto(5) do |x|
    puts x
  end

is pretty idiomatic. So I don't see your point.

Or:

   print("s\n" * 5)

Which is more concise and valid in both.

Reply on news.ycombinator.com