Comparison between Python and "Ruby"

[Clemens Hintze]

>>>>> "Andrew" == Andrew Csillag <andrew at starmedia.net> writes:

    Andrew> Martijn Faassen wrote:

[...]

    Andrew> In my experience, unless ruby's extension interfaces is
    Andrew> like tcl's which while simple, isn't terribly powerful,

Ahem... I have written extensions in both Python *and* Ruby. Would you 
please enlight me, why do you think Ruby interface isn't powerful
compared with Python's one? I had the opposite impression. :-/

    Andrew> Python's is simple enough (I've been known for doing
    Andrew> simple extension modules in about 3 minutes -- no
    Andrew> SWIG). But even complicated ones with SWIG aren't hard.
    Andrew> Actually, even without SWIG it isn't really hard, just
    Andrew> boring since most of it is boilerplate.

All that is also true for Ruby! And you have forgot to compare garbage
collection issues which have to be addressed both in Python and
Ruby. While Python use a refcount scheme, where you have to address
that issue yourself, Ruby use true garbage collection (mark and sweep
scheme), so that you have not to deal with it at all.

Under some circumstances, you have to provide up to two function in your 
Ruby extension. One function that mark Ruby objects, stored in your
extension, alive (if there are some), one that free the memory of your
own occupied memory (normally 'free' is enough). I wish Python would
be so easy here!

    >> > * Function objects are accepted as arguments, but iterators
    >> are more > elegant.
    >> 
    >> You can implement iterators in Python, though?  Better core
    >> level iterator support would be nice for Python 2.0, though
    >> (for instance for loops could use them).

    Andrew> I argue that simplicity is better than elegance most of
    Andrew> the time, thus function objects over iterators.  Besides
    Andrew> who wants to make an iterator when you just want to pass a

That doesn't score very well, IMHO. My question to your question would
be: who likes to write an own function for something that is only used
one time and therefor better be stick into an block. Perhaps there is
a misunderstanding for iterators. The word was a little bit misleading
used in the Ruby documentation, IMHO. But now they have correct the
usage.

    Andrew> function you already have?  Reminds me of how you pass
    Andrew> methods around in Java (make an instance of (usually) an
    Andrew> inner class that inherits from some interface that just
    Andrew> calls the outer class's method)... Grr...

It reminds me, more of the way how Smalltalk pass methods! Ruby is
(except syntax) more like Smalltalk, than like Java!

[...]

    Andrew> From what I saw, it looks like they tried to mix python
    Andrew> and perl by sticking the python down the camel's throat

What?!? Do you really saw it? Can it be that you have only had a
glance to the syntax, and therefore decided it's like Perl => crap!

    Andrew> and got camel puke.  You have whitespace for indentation,

Okay! Now I am convinced that you never have really looked at Ruby too
close. Perhaps only a small blink on it! Ruby *does*not* use
whitespaces (unfortunately, cause I like them :-)!

Ruby has in common with Python its consistent behavior, its simplicity
and its easy extension writing. It shares with Perl the speed and much
of the syntax; but not the context dependend behavior, that makes it
so diffcult for beginners to learn Perl.

There is e.g. a syntax for creating regexps, but these are objects
then, like in Python. And it also has many many things in common with
Smalltalk (Ruby is totally OOL). Even a '1' is an instance of class
Fixnum *unlike* Python & Perl!

    Andrew> but all the regexy crap and extraneous ?'s and $'s that
    Andrew> make it ugly.

I don't think, that the regexp stuff is crab! If you want, you can
also use the Python way:

	regex = Regexp.new("^(S+)")    # Or use: regex = /^(\S+)/
	regex =~ "hello world"         # Or use "hello world" =~ regex

Perl is (whether we like it or not) the most used language for
sysadmin and web purposes till today. So there are many programs and
modules already available. To ease the port of them, was one of the
issues, why matz has decided to introduce these ugly variables. I
don't like them, but I can live with them. Hey, there are also things
I don't like in Python, but they doesn't necessarily make the language
worse for me.

    Andrew> -lets-make-a-language-named-perl-so-we-can-cast-it-to-swine-ly
    Andrew> yours, Drew

-be-not-so-biased-towards-one-language-
-there-is-no-only-one-
-all-is-a-matter-of-taste-ly yours Clemens.

[...]