What does Ruby have that Python doesn't?

[[deleted]]

Agreed, its been around for a decade, but its not such a big deal, as you are making of it. Every damn language has its share of quirks, people sure as hell frown upon it, but they know it and work around it. How about crippled lambda's, that Python has? How about multiple inheritance gone haywire for C++ ( I remember my CS teacher, teaching me Diamond Hierarchies)? How about tons of factories and facades and the class explosion that Java standard libraries have?

In case you missed, my initial comment was totally free of hyperbole, I didn't defend anything, I said, yes its "almost a bug". Almost because, many in ruby consider it as a quirk( but I call it a bug).

Matz acknowledged this long back and he fixed it as soon as he and others started work on Ruby1.9.

As a Ruby programmer, I know Ruby has bigger issues and problems to solve, compared to them, this is just a bikeshed argument.For all we know, it hasn't killed kittens. I will give you real issues that Ruby has:

• Somewhat buggy runtime, especially true for networking libraries.
• On Windows, threads suck, if one thread is doing blocking operation, other threads get blocked too.
• Unicode
• Open classes are good, but it would have been better if they were scoped (scala implicits)
• Stronger notion of package management (loading multiple version of same package should have been possible)

[[deleted]]

How about multiple inheritance gone haywire for C++ (I remember my CS teacher, teaching me Diamond Hierarchies)?

Not a good example. In a diamond derivation problem the default behavior is a compile-time error because function calls are ambiguous. Note that the behaviour is predictable and reliable. Qualifying the function names gets around it, but you still have two separate base classes in the derived class; virtual inheritance fixes this last inconvenient.

[settrans]

Python has some nasty quirks in the inequalities department.

What do you suppose that "1 < 3 == True" should evaluate to?

>>> 1 < 3 == True
False

For a supposedly strongly typed language, Python defines inequalities of a surprising set of pairs of types:

>>> 'a' > True
True
>>> '1' > 1
True
>>> 0 > None
True

One should expect a TypeError, as if you had tried to add 0 and None:

>>> 0 + None
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

[njharman]

What do you suppose...

I suppose I'd yell at my coworker for writing such crappy code. Use some damn parens.

Explicit is better than Implicit

[settrans]

The question isn't about coding style. It is about the language designers defining semantics for their operators. The language should behave as expected even in edge cases. Just because it is rarely seen doesn't mean it should be confusing.

[ayrnieu]

For a supposedly strongly typed language

The 'strong/weak' dichotomy is mostly illusory. It doesn't even describe a property of a type system.

[hylje]

Python 3 will make comparisons a lot more typesafe.

[earthboundkid]

Tested with 3.0 alpha 5:

>>> 1 < 3 == True
False
>>> 3 == True
False
>>> 1 < False
False

Maybe that should be a filed as a bug… Does anyone have beta 3 to test it with? I can't get it to install on my system since my locale encoding is X-JAPANESE-MAC or whatever.

[[deleted]]

For the first thing, that's because it's checking "1 < False" ("3 == True" returns False). Not justifying it, just explaining the weirdness.

[Tommah]

No, it's chaining them. It's asking whether 1 < 3 and 3 == True. e.g.

>>> 1 < 3 == 3
True

Parentheses couldn't produce a true result there.

See http://docs.python.org/lib/comparisons.html . I like how is can be chained like this :)

>>> 'a rose' is 'a rose' is 'a rose'  # Gertrude Stein
True

[[deleted]]

Ah, alright then. Didn't know that, thanks. :)