Ruby vs. Python? [no, Ruby vs. Ruby ]

In fact this is not a Ruby vs. Python list. I know not enought Ruby and I love Python to much :). It's more a picture of the first impressions I had on Ruby after I seriously began studying it.

This is a quick list of thoughts. I'm probably adding more stuff later. In fact I'm reaaly amazed. Ruby is really hackish, but it's also neat and clean. It may sound strange... but I'm afraid I'm gonna love ruby more than Python: it addresses many of the things I come to dislike in Python.

[from the future: this did not happen...; kind of a summer love, back then]

Some stuff I like

• Adding dynamically stuff to classes. The syntax is clean and obvious:
  

  class MyClass
    def aMethod
      puts "Called aMethod"
    end
  end
  
  m = MyClass.new
  
  begin
    m.aMethod2
  rescue NoMethodError => ex
    puts "Failed to call #{ex}"
  end
  
  class MyClass
    def aMethod2
        puts "Called aMethod2"
    end
  end
  

  [from the future: I actually hate this right now. Monkey patching is dangerous.
  I believe that having the nice syntax actually encourages a messy practice.
  I have seen too many ruby plugins/libraries fight because of this crap.]
  
• m.aMethod2 In Python for example it is not that clean. The ruby code looks more like ObjectiveC categories (even if in fact you don't specify a category, of course, since ruby does not need categories).
• private, protected, public modifiers. Being dynamic they do not limit me in any way (if I need I can dynamically change this)
  

  class MyClass
    protected
    def aMethod
      puts "Called aMethod"
    end
  end
  
  m = MyClass.new
  
  begin
    m.aMethod
  rescue NoMethodError => ex
    puts "Failed to call #{ex}"
  end
  
  class MyClass
    public :aMethod
  end
  

  [from the future: I don't really believe they are useful as long as you can
  change them dynamically. They are, by definition, not harmful as well.
  I wouldn't make a war if Python adds decorators to do this stuff. I wouldn't
  be pleased either]
  
• m.aMethod Moreover I can't think to a cleaner syntax to do this. Of course one can argue that they aren't really necessary. Of course, but if you want they do give you a little bit of control, but they don't limit you in any way.
• Object#freeze: if you suspect that some unknown portion of code is setting a variable to a bogus value, try freezing the variable. The culprit will then be caught during the attempt to modify the variable. I believe correct unit-testing makes this sort of debugging mostly useless.
• I love postfixed control clauses. In fact if used with moderation they can augment code readbility (and of course if abused they make it less readable). However, it is pretty logigal to say do_something if something_else. In fact since ruby has blocks it is ok also to write:
  

  begin
      # some stuff
  end if condition
  

  maybe not everyone agrees
• Accessors are great. Using attr and similar constructs is great. I also find quite more readable to "assign" with foo= than using more Javesque setFoo(val). In fact properties in Python work in a similar fashion, even if maybe a bit more verbose (however, I think they make it clearer how to document code, but this is a ruby aspect I've not yet exploited)
• Gems: I think python needs something like that. Pimp is not that good, in my opinion, of course.

Stuff I don't know if I like or not

• Not having to write parentheses with no-argument methods. I've not yet discovered if I like it or not.
• All the $_... They are used a lot in Perl. I like it, but I'm afraid it can mess things up.

Stuff I dislike

• I don't like passing strings to require. In fact it can have advantages, but I prefer the pythonic import foo to require "foo".
• The try catch semantic of try/catch, makes me think to some kind of disguised goto. I'm sure I'm wrong... but
• I'd like to have something like Perl use strict;. It's something I miss in Python (even if with pychecker you can just live without it). Now I've got to find some kind of "use strict" or "rubycheck".
• Assignment is an expression. This directly leads to code like:
  

  a = true
  b = false
  print b if b=a
  

  and we imagine the programmer wanted to write:
  

  a = true
  b = false
  print b if b==a
  

  
  
• However in Ruby almost everything is an expression, and it has quite a lot of advantages. So we have to tolerate the "=" for "==" problem.