Hacker News Reader

Comment by jimmyrr | Hacker News Reader

...strange ad-hoc combination of other languages.

I call bullshit, sir. Ruby is objectively less strange and more consistent than Python. Some has to do with the fact that Python is older - hence has more baggage to carry. A lot of it, though, just has to do with poor/missing design choices. Specifics?

- ruby 'block' passing convention is much cleaner and more powerful than python's 'for'/iterators.

- python's global functions are stranger and more ad-hoc than Ruby's strict object-orientation.

- ruby's mixins > python's multiple inheritance

- python underscore (and double underscore) naming conventions to overcome simple language features

Don't get me wrong: i love python - but primarily because of the faster execution and larger community - not because of the language itself.

View on HN

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).

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>

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.

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.

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.

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

Ruby 1.9 has real iterators now.

They're in 1.8 now too:

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

They've been around for awhile

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

Quoting an article on the topic:

Having ploughed through several tutorials, I did not find Ruby particularly "elegant", or its syntax particularly obvious. Much of it seemed ad hoc, thrown together, in particular when there were several different ways of doing something, and it seemed to be the philosophy of the language to provide all of them. I did not find its constructs as intuitive and natural as claimed, trying out simple coding examples proved as frustrating when things didn’t do what you’d suppose they’d do...

(http://www.bitwisemag.com/2/What-s-Wrong-With-Ruby)

I actually gave Ruby a shot, going through the interactive tutorial on http://tryruby.hobix.com. I couldn't do it very long, however, because it was completely ridiculous. In what world does it make sense for hash keys to double as string grep? For instance:

    my_string['foo'] = 'bar'

will replace the first instance of foo in my_string with bar?! WHY?! I can stick an exclamation point on the end of method calls... to signify mutation? WHY?! What twisted logic allows one to rationalize multiplying strings like:

    "5" * 2 == "55"

yet throw an exception for:

    2 * "5"

It makes absolutely no sense! And why would an integer have a method for converting itself to a string? Or an array? I found so many things in Ruby that made me think, "Okay, superficially that's really convenient and sorta cool... but it makes no sense and it is absolutely counter-intuitive. And I feel dirty using it, even if everybody is doing it." Some people, I assume, find Ruby to be "elegant" for the same reasons I find it to be "an abomination."

Well, I can answer at least a few of those 'WHY?!'s.

Firstly starting with my_string['foo'] = 'bar', this is a syntax that is used a lot in Ruby for anytime that you wish to recover a subset of a collection - you can use it with a Dir object for example to recover a subset of directories/files, or in the case of a hash, to recover the object stored at the key. The thing is that you need to think about it as being a subset operator, rather than an index operator.

The exclamation point at the end of a method name has no syntactic meaning - it is simply a naming convention used by the standard libraries to indicate when the method mutates the object or not. Same same for method names ending with a question mark, it's just a convention to indicate that the response will be a boolean.

As for the whole "5" * 2 vs. 2 * "5", I must admit to not understanding where you're coming from. I don't see how you could expect any other kind of behaviour from an object orientated language. Personally I don't like over-riding arithmetic operators for non-number types, for precisely this reason, but hey, some people like it, so why not?

Integers converting to strings? I think every language has that no? I mean there's always something like: sprintf(myStringPtr, "%d", myInteger); or cout << myInteger;

etc etc

By making this a standard method on all classes (to_s), Ruby makes it really easy to dump a class to a serial format, which is very useful for debugging, as an example.

I get the impression that you simply didn't spend enough time with Ruby to come to understand its idioms, in which case, you're not really in a position to effectively criticise the language...

I suppose these just seem odd to me, which was my point. Not that I find something absolutely wrong about them, anymore than I can find something wrong about a language which doesn't have mutable variables or whatever the case may be.

A lot of Ruby's conventions simply scream "ambiguity" to me. A "subset of a collection" is extremely ambiguous; if there is more than 1 foo in my_string, does it always get the first? How do I get the rest? my_string['foo'][2] or something? I can't even intuitively make something up which makes sense to me. Perhaps there isn't a way to get the others, which I suppose would be in line with Python, which doesn't supply a string method to find all occurrences at once... but how do I offset it?

I can see where standardized methods like to_a can be more convenient, but they also open up the possibility for unlimited ambiguity. What does Foo.to_a do for your Foo class? It could do anything! There's no way I could rely on these methods to do something across the board unless I know your class conforms to some Interface (do Ruby folks use/have Interfaces?). In Python, if I do

  [foo]

Then foo is now a list. I always know what I'm getting. I always know what int() is going to attempt to do to an object, etc.

Perhaps there isn't a way to get the others, which I suppose would be in line with Python, which doesn't supply a string method to find all occurrences at once... but how do I offset it?

Yes, there's no way to get the other matches using [] as far as I know, it's just a generalization of being able to pass various types to it; Fixnum, Range, Regexp.. I don't see the harm in doing something with String too. If you wanted to extract multiple items, you'd use something like String#scan, or if you wanted to do a global replace, String#gsub, which can also accept a code block to perform computed replacements.

I can see where standardized methods like to_a can be more convenient, but they also open up the possibility for unlimited ambiguity. What does Foo.to_a do for your Foo class?

As of 1.9, it does this:

    NoMethodError: undefined method `to_a' for Foo:Class

In 1.8 it issues "warning: default `to_a' will be obsolete".

In Python, if I do `[foo]` Then foo is now a list.

You do the exact same thing in Ruby, though if you're wanting to cast your argument like the old to_a did, you use Array(), which won't turn [] into [[]]. If you want a number, Integer() or Float() will raise an exception if they can't give you one.

>I get the impression that you simply didn't spend enough time with Ruby to come to understand its idioms, in which case, you're not really in a position to effectively criticise the language...

Well yeah like others have been saying, python is more attractive to new users is probably partly why it's more popular. You don't need to work as hard to understand its idioms, it's more readable by newbies (by anyone), etc.

"As for the whole "5" * 2 vs. 2 * "5", I must admit to not understanding where you're coming from. I don't see how you could expect any other kind of behaviour from an object orientated language."

Python has a __rmult__ method. If you do A * B, first it internally calls A.__mult__(B) then if that raises TypeError, it tries B.__rmult__(A). It's pretty elegant, I think. For Ruby, it wouldn't look as nice to do A.r* though, I guess, but it would be a nice bit of functionality.

"5" * 2 == "55"

You're calling a method on a string, so you got the string doubled. Seems to make sense to me.

Obviously in this case the order of the arguments matter.

"Obviously in this case the order of the arguments matter."

It's not obvious in terms of intuitiveness, no. Why not extend the Integer class to know to call mystring's * method when their order is reversed? That would be intuitive.

Re: "5" 2 == "55" vs. 2 * "5" == Exception*

You need to remember that EVERYTHING is an object, there are no basic/literal types at all; in this case, "5" is really just syntactic sugar for creating a "5" String object, 2 is syntactic sugar for creating the "2" Integer (Number?) object, and the " * " operator is syntactic sugar for the " * " method of the "5" String object == ' "5".times(2) ' (which is similar to Perl's ' "5" x 2 ' construct).

The String class supports a " * " method which creates n copies of it's string value, and concat's them together into a new String object, but the Integer class does not.

Many "basic" objects have explicit conversion methods, but will also frequently support implicit conversion where it makes sense.

Why does it overload "*" on the right, but not on the left side of the string? Python has __rmult__, and it works. Please do not try to make language warts look better by spilling a bucket of architectural-astronauty crap.

Huntbach's article was pure nonsense when it was written[1], and it remains pure nonsense now.

[1] As I wrote two years ago: http://www.halostatue.ca/2007/03/17/whats-wrong-with-bitwise...

"And why would an integer have a method for converting itself to a string? Or an array?"

You know that under the covers in Python str(1) works by calling (1).__str__(), right? That's why you can make str(my_custom_class) work.

Reply on news.ycombinator.com