From: Bill Kelly <billk@...>
Date: 2003-08-20T04:43:51+09:00
Subject: Re: Why did you switch from Python to Ruby?

> This question is only meant to apply to people who used to use Python, but
> switched to Ruby.  Why did you do so?

I understand Python has improved significantly since my
experiences with it.  My "Python Essential Reference" book
was based on Python 1.5.2.  I learned Python at work, in
parallel with Ruby at home.

We were all learning Python together, at work.  We were
writing Java apps, but wanted something higher level to
program in, so Jython (nee JPython) seemed the thing.
(No JRuby was available at the time.)

Python was so much more fun than Java that I embraced it
wholeheartedly.  (Putting aside my/our misgivings about the
syntactically-significant whitespace thing.)  [I tried
to persuade others on my team that _anything_ had to be 
better than Java.... They were less dissatisfied with Java's
expressive power at that time than I was...]

Ultimately Python served us well.  But there were so many
times we'd try to figure out how to do something in Python
that either turned out to be impossible or inelegant, that
it became a running joke.  We'd just turn to one another
sadly, and in commiseration proclaim, "Guido!".  (Perhaps
a little like "Newman!" is said on Seinfeld.)

. . . Wish I could remember more of what those things were.
Maybe they're addressed in Python by now.  One, for instance,
was when we tried to figure out how to create class methods
(as opposed to instance methods.)  Page 64 of the Python
Essential Reference admits, "... it's not possible to define
class methods that don't operate on instances."  ...Guido!!
The other I recall was trying to figure out how to do an
assignment within a conditional.  The code I wanted to 
write was something like:
            
            if (val = gd.get('startTag')):
                attrs = parseAttrs(gd['allAttrs'])
                self.handleStartTag(val.lower(), attrs)
            elif (val = gd.get('endTag')):
                self.handleEndTag(val.lower())
            elif (val = gd.get('text')):
                self.handleNonTagText(val)
            elif (val = gd.get('comment')):

                #...etc.

Apparently this was impossible.  At least, I never was able
to figure out any way of doing it.  I ended up with some
annoying, verbose, nested thing like:

            val = gd.get('startTag')
            if val is not None:
                attrs = parseAttrs(gd['allAttrs'])
                self.handleStartTag(val.lower(), attrs)
            else:
                val = gd.get('endTag')
                if val is not None:
                    self.handleEndTag(val.lower())
                else:
                    val = gd.get('text')
                    if val is not None:
                        self.handleNonTagText(val)
                    else:
                        val = gd.get('comment')
                        if val is not None:
                            #...etc.

...Guido!!

Another silly example might be the interactive Python 
interpreter.  It goes through the trouble of recognizing that
when someone says 'exit' they probably want to exit.  But instead
of doing what the user intended, it merely spits out a complaint
that one should "Use Ctrl-D (i.e. EOF) to exit."

...Guido!!!  

My impression was that Python's designer was trying to achieve
elegance by fiat.

My experiences with Ruby were, truly, quite the opposite.
The surprises were so pleasant: I used to laugh out loud
after awhile when I'd look up in Programming Ruby how to
do some particular thing (create a class method, say) and
find that whatever-it-was was exactly what I would have
written had I just guessed and tried it.  This happened
over and over and over.  So many times, I couldn't believe
it.  It became a _positive_ running joke, of sorts, with
me.

Anyway, ... it's all so subjective.  But Ruby "rubs me
the right way"... and Python didn't.  Although, Python is
still way more fun to program in than Java!  <grin>


Hope this helps / for whatever it's worth / etc...

Regards,

Bill