From: Ville Vainio <ville@...>
Date: 2004-04-02T23:19:44+09:00
Subject: Re: deciding between ruby and python

>>>>> "Mark" == Mark Hubbart <discord@mac.com> writes:

    Mark> No. When implementing a join method, you have a choice: let
    Mark> Strings understand something about Arrays, or let Arrays
    Mark> understand something about Strings. Does it make much
    Mark> difference either way? Should we choose to make a special
    Mark> case of Strings, or Arrays?

It does make a difference, because sequences (or 'iterables') are a
much more fundamental concept than strings. It's not just one Array
class.

    Mark> pre-existing method. But for most things, we just use
    Mark> blocks. What's so special about using methods?

I guess that's exactly the point - what's so special about methods
that they can't be first class objects?

    Mark> again: blocks? Can you give an example where blocks don't
    Mark> fill the spot functions take in Python?

Nope. I consider modern Python and modern Ruby to be
feature-equivalent. Someone might have some examples, but I really
don't have deep experience in programming Ruby. I've just read the
docs, and played around with it a little bit. Didn't bump into
anything that I was missing in Python, and bumped into several things
that I consider design glitches (mostly perlisms), so I didn't feel
the desire to become more proficient in it.

    >> Calling to_s() seems kinda brutal from the Python POV. Perhaps
    >> this is one of the areas where Ruby chooses the follow the Perl
    >> school of Convenience.

    Mark> it makes perfect sense. Ruby uses duck typing... so when you
    Mark> call join, it assumes that you want the array items
    Mark> interpreted as strings. It

I don't think it's a good example of duck typing, because it coerces
everything to the particular kind of duck it wants to work with.

    >> Yes, Ruby and Python are not all that different. I guess most
    >> Ruby fanatics

    Mark> There's only one fanatic plainly visible here...

Please read back a few posts, I bet you'll find at least one fanatic
more ;-).

    Mark> I think I caught a whiff of elitism there... Perhaps
    Mark> Pythoners would be happy with a forked version of Ruby? I
    Mark> doubt it. And I doubt that Rubyists want a forked version of
    Mark> Python.

From a purely technical standpoint, there are virtues in having a
pre-existing code base that is individually maintained. Ruby people
would only need to maintain the patches that provide blocks, extra
methods and 'end'. Python is the more mature, popular and minimal of
the two, so forking Ruby wouldn't make as much sense.

Obviously history has taken its course, and the two languages exist
independent of each other. But if Ruby started today, would you
implement it from scratch? Or would you rather just add blocks and
'end' to Python?

-- 
Ville Vainio   http://tinyurl.com/2prnb