What's better about Ruby than Python?
jacek.generowicz at cern.ch
Sat Aug 23 20:29:28 CEST 2003
mis6 at pitt.edu (Michele Simionato) writes:
> Perl is NOT a dialect of Python. Ruby is NOT a dialect of Python. Tcl
> is NOT a dialect of Python. They are entirely different languages,
Oh ferchrissakes ... Scheme is not a dialect of Common Lisp, elisp is
not a dialect of Common Lisp, etc. etc. They are entirely different
Please stop (not you in particular, but you all in general) taking a
whole bunch of different languages, which happen to share one
characteristic, and claiming that they are dialects of eachother. Perl
NOT being a dialect of Python (and the similarity of this fact to the
fact that Scheme is not a dialect of Common Lisp) is exactly my point.
> I would concede than in many ways Python, Perl and Ruby are similar
> and more or less with the same power, bust still the way of
> programming in one or the other is completely different.
Well, guess what, the ways one programs in CL, Scheme and elisp are
also completely different.
> I would concede that Lisp is different from Scheme, more at the conceptual
> level that at the syntactical level. But still the reality is that the
> different implementations of Lisp and Scheme are different,
Well, yes, that's generally true of implementations of _completely
different languages_ !
> especially in what concern the interface with the operating system
> and scripting facilities, which is what one does all the time (at
> least in this mailing list ;). So once I know an implementation, I
> am never sure my program will run on another implementation,
Once you know CPython, you are sure that your program will run in
> 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.
> 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.
> Too much choice (meaning a too much fragmented community) can scare
> potential lisp newcomers.
Funny, I usually hear the criticism that Lisp is dead and that there
aren't _enough_ implementations of it.
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.
> 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.
> 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. This, still, has nothing to do with macros.
(NB, I do _not_ program in Scheme. Caveat emptor.)
> Lisp has CL, but learning CL will not help me very much with Emacs
The Algol Family has C++, but learning C++ will not help you very much
> Lisp which is what I would need the most ;) I am joking a bit here;
No. You are _completely_ joking :-)
More information about the Python-list