Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Python vs. Ruby: A Battle to The Death (ontwik.com)
42 points by ahmicro on Jan 3, 2011 | hide | past | favorite | 18 comments


So, Gary says both "I can't stand Ruby's Syntactic Flexibility" and "I wish Python had more Syntactic Flexibility." (Really, all he wants are blocks so that he can have RSpec, etc.) But he does point out some odd, and some good features of Ruby that are worth attention.

Make up your mind, please. ;)

His example that:

    >> x = Proc.new { 5} 
    => #<Proc:0x00000001015f21a0@(irb):1>
    >> x()
    NoMethodError: undefined method `x' for main:Object
    	from (irb):2
    >> x[]
    => 5
    >> x.call
    => 5
Is also a bit crazy: Proc.[] is an instance method of a Proc that is aliased to Proc.call (crazy as that may be); proc() is a language feature for calling an object's method (a proc isn't a method, it's an object--Proc.call is the method). And before you ask what about a method without an object, understand that they do not exist. There is a global object that receives all methods not associated with an object.

    >> def x
    >>   p self
    >> end
    => nil
    >> y = Proc.new { p self }
    => #<Proc:0x00000001015ecf48@(irb):4>
    >> x()
    main
    => nil
    >> y.call
    main
    => nil
And, in case you're confused about why y.call prints "main", the Proc's block is technically created within the scope of the calling or parent object. In other words, the block passed to the Proc is created in the main class and then delegated to the Proc instance--therefore when executed it belongs to, and references the scope it was created in: main. (A binding from the Proc itself is neither created, nor passed to the block. If it were the block would return the same Proc inspection from line 4.)

And... the reason a "patch level release" (his words, not mine) added syntax is because 1.8.7 is a backport of new features from Ruby 1.9 down to Ruby 1.8. I don't claim to like or understand the version numbers, but the patch level is given like "ruby-1.9.2-p136" not as the third part of the number itself.

/rant

Sorry, I should stop here before I lose my whole morning.


    And before you ask what about a method without an object, understand that they do not exist.
Technically, there are unbound methods (i.e. methods with no object) but you can't call them.


Technically they exist, but I think it's an oxymoron because it must be bound to be usable. To be honest, I still can't figure out a reason you'd ever use one.

Do you have an idea of when they're useful?


Perhaps more technically, unbound methods _are_ objects (as are [bound] methods, procs, etc.).


You are right of course.


Money quote, at about 15:20:

"The very attributes of Ruby that I find distasteful are what give rise to all the wonderful software that the Python world can never have. And vice versa -- the very thing that makes Python aesthetically pleasing to me is exactly what leads to not being able to do any of this cool stuff. Ever."

This is after complaining about how complicated Ruby syntax is, but then showing how RSpec uses that malleable syntax to make what he considers to be beautiful code.


Related: http://blog.extracheese.org/2010/02/python-vs-ruby-a-battle-... (blog post by the author)

http://blog.peepcode.com/tutorials/2010/what-pythonistas-thi... (Blog post about the video referred to by the author)

http://news.ycombinator.com/item?id=1097723 (HN discussion about that blog post)


The example for "If the implementation is hard to explain, it's a bad idea." was very enlightening.

I always felt Ruby was a bit too irregular for my taste. Now I know why.

On the Cucumber thing, there is something similar in Pyccuracy. The Yahoo office in São Paulo is using it a lot.


There is also a project called Lettuce. It isn't quite as 'natural language' as Cucumber, but the added syntax isn't too much and is still quite readable.


Is any one else getting tired of these versus type articles?


This one was actually interesting. Usually they are obvious and boring.


Yeah. 'cos Perl is the best =)

(j/k)


Ruby overuses []. It is used in Array literals, but it is also an operator (i.e. a method with odd syntax) on several classes: Array, String, Fixnum, Bignum, Proc. In a language with dynamic typing, we should avoid having methods (or operators) with the same name and different function since calling nonexistent methods is how we catch errors.

The [] operator on Proc was new to me. I don't like the [] on Fixnum and Bignum, which is a bit operation: x[y] := (x << y) & 1. Hence my fixes to Ruby would be:

  $ irb
  001> add = lambda {|x,y| x+y}
  => #<Proc:0x0000010089ef30@(irb):1 (lambda)>
   002> add[1,2]
  => 3
  003> 1[2]
  => 0
  004> class Proc; undef_method :[]; end
  => Proc
  005> class Fixnum; undef_method :[]; end
  => Fixnum
  006> class Bignum; undef_method :[]; end
  => Bignum
  007> add[1,2]
  NoMethodError: undefined method `[]' for #<Proc:0x0000010089ef30@(irb):1 (lambda)>
        from (irb):7
        from /usr/local/bin/irb:12:in `<main>'
  008> 1[2]
  NoMethodError: undefined method `[]' for 1:Fixnum
        from (irb):8
        from /usr/local/bin/irb:12:in `<main>'
  009> (100**100)[1]
  NoMethodError: undefined method `[]' for #<Bignum:0x00000101116f50>
        from (irb):9
        from /usr/local/bin/irb:12:in `<main>'
I'm also tempted to remove [] from String, but the usefulness probably outweighs the occasional confusion from thinking a String is an Array.


I use and like them both. I find Ruby more consistent and Python with better libs (for what I do). Either is a fine choice.


Nice talk, but in the questions and answers it would be better to see people instead of the blog address all the time.

+1 For the grammar graphs :)


Can't we just agree that both Python and Ruby are awesome and rant about Java some more? ;)


Lack of namespaces and monkeypatching (extending classes) are THE "features" that keep me from using ruby seriously every time I try to approach the language.


Competition is good.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: