undefined | Better HN

0 pointsyangyang17y ago0 comments

I have used both, Python more than Ruby.

Python's iterators are more usable in many situations than the Ruby block system. I can return an iterator, stick it in a variable, call another function with it that returns another iterator, and so on.

Python's classes also seem cleaner and less magical than Ruby's. For example, a method on a class is just an attribute that happens to be a method. Much more intuitive than Ruby in my opinion.

I'm also fond of Python's idea that "There should be one-- and preferably only one --obvious way to do it".

I agree that Python does have its fair share of strangeness, but that fades away with time (you don't notice it).

0 comments

8 comments · 2 top-level

wildjim17y ago· 4 in thread

Everything is an object in Ruby, including the blocks. I'm not clear how you can't pass around a block -- or is it the block + iterator metadata you're talking about? I suspect that's just an experience problem, where Python promotes iterators over lambdas so lends itself to a different style of programming; I'm not sure how often you'd want/need to pass a full iterator around in Ruby.

Personally I find blocks far more intuitive than Python's iterators and generators, but that is a subjective thing.

WRT Magical Classes, I'm not a fan of everything being stored in a dict. It seems grossly under-engineered to expose the underbelly as a basic "dumb" object; at the very least, it should've been a "Class Metadata" object with attached support methods to make it easier (safer?) to inspect or update.

And lastly: there is NEVER just one way to do it!! Witness the confusion n00b's feel over the join() method: ",".join([LIST]) where the more intuitive would probably be [LIST].join(",")... but if you MUST have join() in the string module, why not support the latter as a redirect to the former?

Seriously: this sort of dogma can make certain kinds of algorithms very messy to code.

However, my biggest beef with Python is that I seem to have to write a metric buttload of boilerplate and end up with something very Java-esque... <sigh>

yangyangOP17y ago

It might well be experience, I haven't used ruby a great deal. I wanted to do something similar to izip in Python and couldn't see a way to do that without constructing lists in Ruby.

I completely disagree with having to write lots of boilerplate and java-esque code. I've written huge amounts of Python, and seeing Java after that really made me wince. What does Python lack that makes you feel you need boilerplate?

I don't think the one-way-to-do-it thing is that dogmatic, really. It does make code nicer when you don't have to be aware of various aliased methods, and there are less ways of making identical code look different.

pwang16y ago

Under what circumstances have you had to write a "metric buttload of boilerplate"? I've not encountered this with Python in my experience.

cbr16y ago

You can do ", ".join(x) on any x that you can do "for y in x" on. If join were a method of the list (or sequence, or iterator, ...) then it would need to be defined over and over again.

earthboundkid16y ago

Or it would have to inherit the method from a common iterator class. Which gets to the heart of the Ruby/Python thing: In Python inheritance just isn't as stressed, since people prefer duck-typing to isinstance. On the other hand, since you can reopen classes in Ruby, it's not as crazy to use the modification of a common base class as a means of making a method work with a wide variety of object types.

sreque16y ago· 2 in thread

Ruby 1.9 has real iterators now.

Freaky16y ago

They're in 1.8 now too:

    >> [1,2,3].each
    => #<Enumerable::Enumerator:0x801820f10>
    >> RUBY_VERSION
    => "1.8.7"

stephencelis16y ago

They've been around for awhile

    >> RUBY_VERSION
    => "1.8"
    >> require "enumerator"
    => true
    >> [1,2,3].each
    => #<Enumerable::Enumerator:0x29326940>

j / k navigate · click thread line to collapse