What's better about Ruby than Python?

[Michele Simionato]

Jacek Generowicz <jacek.generowicz at cern.ch> wrote in message news:<tyfisoow7lj.fsf at lxplus014.cern.ch>...
> Once you know CPython, you are sure that your program will run in
> Jython?

I would expect Jython 2.1 will run 99% of Python 2.1 valid code (except
of course, code involving C libraries). But I don't claim any
expertise in Jython, so if I am wrong, please correct me. In
my small experiments with Jython, I never had problems with
the language; I think the only issue was the absence of the C expat
library, but then you can use a Java equivalent. Speed is the only
real weak point of Jython, as I see it, but this is an entirely
different topic.
 
> > if you prefer the term implementation to the term dialect.
> 
> Don't brush this difference off so lightly, for it is a very
> significant one. Many languages are standardised. For example Common
> Lisp. There are many implementations of Common Lisp. Scheme and elisp
> are most certainly NOT implementations of Common Lisp. "Dialects" of
> Common Lisp do not exist.

This is a tautology. If a Lisp is Common, then it is Common Lisp.
I was talking here about Scheme, Emacs Lisp, etc. Now you argue that these
are not dialects of Lisp but entirely different languages. To be honest,
I do think you have reasons for this claim. Nevertheless, outside of the
Lisp community, everybody who says the name Lisp in a language
(ex. Emacs Lisp) would expect that it is a dialect of Lisp.
So, the confusion is unavoidable.

> > On top of that, how am I supposed to choose my implementation?
> 
> Price, availability on the platform which interests you, quality of
> implementation, the license conditions, the demands of your clients,
> implementation-specific extensions, etc. ... just like for any other
> language with multiple implementations.
> 
> If you want to aruge that a single implementation language offers
> certain advantages purely by having a single implementation, fine. But
> don't use it as an argument to support the (hopelessly false) thesis
> that Lisp macros are evil and are responsible for the "fragmentation"
> of Lisp. C++ (and other languages) also have many implementations;
> this has absolutely nothing to do with them having powerful macros.

Not true. If I wanted to use C++, then there would only one choice that 
would be natural to me, as a Linux user: gcc. This is natural becomes it
comes for free in every linux machine (and under cygwin too). Common
Lisp in not included in the gcc collection (yes, there is gcl but it
does not come automatically, at least it didn't come with Red-Hat 7.3)
Speaking more in general you cannot compare the avaibility of C++ 
(including the avalability of documentation) with the availability of Lisp. 

> Anyway, repeat your argument to yourself, substituting C++ (or any
> other standardized language) for Lisp, and see how ridiculous it
> sounds ... and bear in mind that we supposedly got this excess of
> choice because Lisp macros inevetably lead to Lisp fragmentation.

Notice that I didn't make that claim.

> > At least it scared me.  There is only one dominant implementation of
> > Python, CPython. All the others try to match it as soon as
> > possible. I expect Jython 2.2 (now in alpha) will catch up with
> > CPython, at some moment.
> 
> Guess what: Having a mature standard means that your "standard"
> doesn't change every year or two, as is the case in Python. You'll
> find that implementations of Common Lisp are far more compatible
> than the various Python implementations. I don't have to wait for
> Corman to catch up with MCL (or whatever), because Common Lisp in not
> a moving target, unlike Python.

Actually, I see this as a disadvantage. For the name of standardization
and compatibility one must maintain warts in the language. I am not
scared the least by the coming of Python 3.0 in some (far) future.
I wll always have the option of running old programs with the old
version of the interpreter. It is always free, isn't it?
But actually I am pretty sure the breaking of backward compatibility
will be minimal.
 
> >  In Scheme there is no such a basic reference, I am correct?
> 
> You are not correct. 
> However, it is so minimalistic that every implementation provides so
> much "added value" to make it usable out of the box, that they are
> effectively incompatible.

Let me be explicit about what I mean by "standard reference implementation".
Suppose you have a language with 10 different implementations and a
community splitted in 90% using an implementation and 10% using the other
nine for very specific tasks. Then there is a standard reference 
implementation. The Scheme Revised Report is not a standard reference
implementation: it is silent on too many *important* details. And the
community is not splitted 90% - 10%. So I say there is no basic
reference. In Lisp I would agree there is a basic reference, i.e. CL.

> This, still, has nothing to do with macros.

Let me be explicit about my position about the argument that macros are
the source of the splitting of Lisp/Scheme in different dialects.
I don't by it. It goes the other way around: many lisp
hackers want to have the freedom of creating their own customized
programming language. Macros were created to favor this tendency,
it is not the macros that created the tendency!

In the Python community I don't think macros would necessarely
generate a fragmentation in dialects, since Pythonistas like
to write standardized (even indented !) code. Still, I would
prefer to maintain the status quo and leave things are they
are. If I want macros, I can always use Lisp/Scheme, isn't it?

Michele Simionato, Ph. D.
MicheleSimionato at libero.it
http://www.phyast.pitt.edu/~micheles
--- Currently looking for a job ---