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.

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

Ruby 0.0

Today I decided to take some time and have a look at Ruby. I found online a version of Programming Ruby and started reading it. In fact I knew I was going to like Ruby. In fact the first time I took contact with it I quite liked it, even if I didn’t fully exploit its capabilities.

Well… let’s see how it goes. Right at the moment the first thing I wrote is

class Employee
  attr_reader :wage, :name
  attr_writer :wage
  
  def initialize(name, surname, wage)
    @name = name
    @surname = surname
    @wage = wage
  end
  
  def surname
    @surname
  end
  
  def to_s  
    "#{name} #{surname} (#{wage})"
  end
  protected :wage=
  
end

class Manager > Employee
  def initialize(name, surname, wage, employees=[])
    super(name, surname, wage)
    @employees = employees
  end
  
  def setWage(emp, wage)
    emp.wage = wage
    emp
  end
   
  def to_s
    super + @employees.collect{|e| "\n  #{e}"}.join("")
  end
end

mr = Employee.new("Jack", "Bravo", "1000€")
mc = Employee.new("Michael", "Charlie", "300€")
mngr = Manager.new("Angus", "Smith", "10000€", [mr, mc])
mngr.setWage(mc, "700€")
puts mngr

SourceForge.net: Aquamacs Emacs 0.9.8 is out

SourceForge.net: Aquamacs Emacs 0.9.8 is out:
Posted By: davidswelt
Date: 2005-12-21 09:32
Summary: Aquamacs Emacs 0.9.8 is out
Aquamacs, the friendly, mac-like distribution of GNU Emacs for the Mac is available in version 0.9.8. It brings a number of bugfixes and goodies for people with non-English keyboard layouts. It’s a highly recommended update for those with version 0.9.6 or older.

(Via Aquamacs.)

More on Aquamacs (frames and dired)

This is a short tip from the wiki (and most of the notes here will come from the wiki)

After some time, I found quite annoying the way Aquamacs manages frames and windows when I use it as a filemanager (which is something Emacs is really good at) — in fact this ain’t a problem, since I rarely use it that way and I can quickly change behavior with a menu toggle –.

If you would like it to behave like “traditional Emacs” you may want to read this tip

Since I was speaking about dired mode, I add it here: another tip. With this you can open files using mac os open command.

Come colorare il prompt di bash

Avere il prompt di bash a colori, oltre che bello, e` comodo. Quando per esempio abbiamo lanciato comandi con un output molto lungo, la possibilita` di separare visivamente gli stessi e` davvero comoda. Il fattore estetico non e` comunque da trascurare.

E` possibile inviare al terminale caratteri di controllo, che modificheranno per esempio il colore, renderanno i font bold o italic (se il terminale supporta questi caratteri, un xterm lo fa — e analogamente piu` o meno tutti i terminali disponibili sotto X11 –, le console testuali di GNU/Linux lo fanno, Terminal.app di MacOS pure). Ora noi specificando il prompt (variabile d’ambiente di PS1) inseriremo questi caratteri di controllo, in modo che il terminale li prenda. Attenzione a rimettere il testo ‘normale’ alla fine del prompt, altrimenti anche tutto quello che verra` scritto poi (vostro input oppure output di programmi) manterra` quell’aspetto [ eventualmente creando un po’ di confusione e perdendo leggibilita`].

(continua…)