Live data from Hacker News

What's better about Ruby than Python? - comp.lang.python

groups.google.com

21–30 of 129 posts

Re: What's better about Ruby than Python? - comp.lang.python

#21
post #7

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

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?

Re: What's better about Ruby than Python? - comp.lang.python

#22

The 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…

About point 2: the author is probably ignorant of ast module ( http://docs.python.org/library/ast.html ), which allows the programmer to take any ast and recompile it to anything he/she wants (in runtime, unlike Lisp macros, but alike parse tree and ruby2ruby in ruby). This feature allows you to transform things like "1, minute" into "Minute(1)", enabling dsls, and "wrecking havoc" all over. In ruby, you don't have t…

So "the author" is Alex Martelli, a long-time Python user, contributor, and winner of the 2006 Frank Willison award which is given each year for outstanding contribution to the Python community.

I highly doubt he's "ignorant" of anything when it comes to Python...

A better theory is this article is from 2003, but the ast module was added in Python 2.6, which was released in 2008.

(I agree with everything you've said in the second and third paragraphs, but, man, try to give people a little credit before you assume they're ignorant, 'k?)

Re: What's better about Ruby than Python? - comp.lang.python

#23
post #16
post #9

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

It is possible to write very cryptic scala code. Mine isn't, but neither was my perl.

Re: What's better about Ruby than Python? - comp.lang.python

#24

Earlier quoted context omitted.

Yes, there is a semantic difference here. In Python, you can do things like this: if baz>10: func = self.foo else: func = self.bar result = func() Here func gets assigned something called a "bound method", which has a reference to the object and the method, which you can then apply the () operator and call. I am not a rubyist, but my understanding is that you would use a symbol to do a similar thing.

You certainly could solve that with a symbol, I suppose, but that's a bit like doing a word-for-word translation of 'it's raining cats and dogs' into a foreign language. Better to translate to the local idiom than to try to blindly write Fortran in any language, as the saying goes. So, for instance, you might solve it with: result = case when baz>10 then foo else bar end This is synthetic, of course. If the goal is t…

Or a slightly more direct translation is:

    result = if baz > 10
      foo
    else
      bar
    end

Re: What's better about Ruby than Python? - comp.lang.python

#25
The biggest difference between Python and Ruby is in the mindset of the developers that choose them.

I think of Ruby and Python as two languages standing back-to-back in the same spot, mostly unaware of each other, greeting developers who come from different directions.

Re: What's better about Ruby than Python? - comp.lang.python

#27
post #4

The 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 :)

Are there many ruby app built by large teams?

In my experience, teams building Ruby apps tend to be much smaller than teams building Java apps ..

That said, this is a problem for any libraries that you might want to include, you have to trust that the authors followed conventions and didn't do any thing 'evil'. Ruby Rewrite (http://rewrite.rubyforge.org/) was conceived to specifically avoid this sort of problem.

Re: What's better about Ruby than Python? - comp.lang.python

#28
This is a fairly superficial difference, but Python's syntax grammar is very conventional, Ruby's isn't. Compare the grammars of Python, Ruby, and ANSI C.

Python: http://docs.python.org/release/2.5.2/ref/grammar.txt

Ruby: http://web.njit.edu/all_topics/Prog_Lang_Docs/html/ruby/yacc...

ANSI C: http://www.lysator.liu.se/c/ANSI-C-grammar-y.html

Python and ANSI C both have a similar organization of productions and names for statements and expressions. It's pretty easy to follow the grammar to obvious points where the language differs. What are valid unary expressions in Python and ANSI C? There's a production in each grammar that makes a convenient starting point and comparison is easy. What is a valid unary expression in Ruby? It's much less clear.

The Ruby grammar isn't large, so I'm sure some people prefer the way it's organized. Once you've absorbed the whole thing questions like "what's a valid unary expression?" don't matter anymore. But I think it's an interesting distinction to someone trying to decide which language to learn.

Re: What's better about Ruby than Python? - comp.lang.python

#29

The 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…

Re 2): With great power comes great responsibility.

Re: What's better about Ruby than Python? - comp.lang.python

#30

The 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…

We run probably one of the largest Ruby production systems that has ever been made and the dynamism and "monkey patching" are used daily to skillfully make the language better and better over time for the tasks that we solve.

It's absolutely crucial to teams that internalize it's power and pitfalls.

Post reply on HN