"Other syntax differences such as '@foo' versus 'self.foo', or the higher significance of case in Ruby vs Python"
...suddenly wonders if there's a language where both case and indentation are significant.
What's better about Ruby than Python? - comp.lang.python
31–40 of 129 posts
Re: What's better about Ruby than Python? - comp.lang.python
#32One good reason: programming style (AKA personal preference). Python is a fine language. Ruby works better for me -- but that's just me.
Re: What's better about Ruby than Python? - comp.lang.python
#33That's an easy one... In Ruby, I can do string.reverse(). Python makes me type string[::-1] to reverse a string. In a nutshell, that is why Ruby is better than Python.
I must admit that I use Python more than Ruby. I like both, but know Python better. I feel Ruby is more consistent though. Either is a good language!
Re: What's better about Ruby than Python? - comp.lang.python
#34My biggest beef when I've done a little Python has been inconsistency, such as that over functions versus methods. Ruby has a simpler mental model to me. I hear this has improved in Python 3.0, but it felt bleurgh to use functions like len(str) some of the time and methods at other times (though str.__len__() is a poor workaround here). That said, the reasons have been discussed and defended numerous times, so it's d…
The main reason why I like having functions instead of methods is that it removes the possibility for inconsistency. In some languages, you have some objects with methods named size, some with length, etc. With python, you just have one global len method to remember.
Then why bother with OOP to begin with?
Re: What's better about Ruby than Python? - comp.lang.python
#35Earlier quoted context omitted.
The main reason why I like having functions instead of methods is that it removes the possibility for inconsistency. In some languages, you have some objects with methods named size, some with length, etc. With python, you just have one global len method to remember.
I am often frustrated by this as well, but I'm not sure it's specific to Python or Ruby. Why is it Math.log(1) rather than 1.log()? And given whatever reason it's Math.log, why is it a.inverse() when a is a Matrix not MatrixMath.inverse(a)? Is there a good guideline for static method vs. instance method distinction?
In python the convention tends to be:
a.inverse() -> mutates 'a' to its inverse
MatrixMath.inverse(a) -> returns the inverse of 'a', leaving 'a' unchangedRe: What's better about Ruby than Python? - comp.lang.python
#36Earlier quoted context omitted.
The main reason why I like having functions instead of methods is that it removes the possibility for inconsistency. In some languages, you have some objects with methods named size, some with length, etc. With python, you just have one global len method to remember.
Then why bother with OOP to begin with?
Having a global len() function is very, very linked to polymorphism. You can call it on anything that has a __len__() function defined (i.e., any class that implements something like a "HasLength" interface in Java terms).
Re: What's better about Ruby than Python? - comp.lang.python
#37Earlier quoted context omitted.
Yep, the equivalent would probably be something along the lines of: if baz > 10 func = :foo else func = :bar end result = self.send(func)
That may accomplish the same thing, but the direct translation would be: if baz > 10 func = method(:foo) else func = method(:bar) end result = func.call Here, we actually deal with the Method objects, rather than just sending a dynamic message. Although the send() approach would be closer to idiomatic Ruby, I wanted to emphasize that dealing with methods as first class objects in Ruby is indeed possible.
I HATE dealing with first class functions in Ruby. I understand that it was a design choice, but man, in Python you can pass a function or a lambda and you just don't have to worry about which one you're calling. In Ruby, () will explode on a Proc object. What is with that?!!?
Re: What's better about Ruby than Python? - comp.lang.python
#38Earlier quoted context omitted.
Both languages offer the unvigilant programmer plenty of opportuities to shoot off his foot. If you're really concerned about this you should take a look at scala. I'm amazed at how much easier it is for me to maintain my own scala code than either ruby or python.
and so much harder for me to maintain someone else's scala code. It feels like statically typed perl, but that's just mho.
Yea, you can make scala look like haskell, java, or perl with relative ease. Up for debate whether thats a good thing or not.
Re: What's better about Ruby than Python? - comp.lang.python
#39Earlier quoted context omitted.
That may accomplish the same thing, but the direct translation would be: if baz > 10 func = method(:foo) else func = method(:bar) end result = func.call Here, we actually deal with the Method objects, rather than just sending a dynamic message. Although the send() approach would be closer to idiomatic Ruby, I wanted to emphasize that dealing with methods as first class objects in Ruby is indeed possible.
I HATE dealing with first class functions in Ruby. I understand that it was a design choice, but man, in Python you can pass a function or a lambda and you just don't have to worry about which one you're calling. In Ruby, () will explode on a Proc object. What is with that?!!?
You can call a proc with []
p = Proc.new {|str| puts "Hello #{str}" }
p["World"] # prints "Hello World"
Re: What's better about Ruby than Python? - comp.lang.python
#40The title made me nervous that this would be run-of-the-mill fanboy garbage. But I trust the author (Alex Martelli), so I read it, and I'm glad I did. It's reasonable and sane. My two big take-away points: 1) It's very nearly a wash. Ruby and Python are so close together (beneath any superficial differences) that distinguishing is almost an exercise in futility. 2) The key thing about Ruby he doesn't like is its "TOT…
The fact that anyone at any point can monkey patch any built-in is a potential liability for large teams, with average programmers. It must be addressed by culture and code review that you may or may not have. Still worth it though :)
In what situation is it actually a good idea to employ a large number of bad programmers, rather than a small number of good ones? We shouldn't be making trade-offs for the sake of bad ideas ;)