What's better about Ruby than Python?

[Terry Reedy]

Lisp is simple.

(<operator> <item-1> <item-2> ...)

Where's the problem?

The very uniformity of everything (including operators?) being a
possibly recursive list and the actual practice of relatively deep
(compared to Python and similar languages) nesting. If a lisp
expression ends with 10 to 20 closing parentheses (which I have seen),
then there were at least 10 to 20 pending operations waiting to be
closed. This many layers is a bit much for many or most people.
There is also the 'problem' of having to read inside out and
backwards. Ok for a line or two, less ok for multiple lines.

Consider the opposite extreme for an accumlator-based machine:

Assembly is simple.

<operator> <simple-operand>

Where's the problem? The very uniformity of doing everything in
sequential baby steps. Once people learn and understand the baby
steps, bigger chunks like
discrim = sqrt(b*b-4*a*c)
are easier to grasp than the assembler equivalent. Empirically, it
seems that most people prefer the mix of steps with expressions to
either extreme of all steps or all expression, even though both
syntaxes express function composition.

Granted, you need an editor that helps you to match the parens

This may make deep nesting more manageable, but does not make it
shallower. Yes, one could also write a 10-line, 10-layer expression
in Python, but I doubt I would.

Terry J. Reedy

 

[Borcis]

Quantum mechanics is simple. It's just H | psi> = E | psi>

What's H mean? And psi? And bra-ket notation?

The reason my original forays into Lisp around 1990 failed was
because the documentation I had for learning it didn't talk about
anything I found interesting, like doing file I/O and graphics. It
went on-and-on about data structures and manipulating them.

My later attempts were by trying to customize my Emacs LISP
setup, and getting various errors because I didn't know the
quoting rules well enough.

The only thing I ever did in (X)emacs was a nicely working code animator for
MOO procedures, actually it was a client-server thing, there was a reversible
code decorator, and the decoration led the code upon execution by the MOO to
surround each one of its steps by a handshake with the XEmacs client, that the
latter converted to an animating transformation of the source code text before
the user's eyes and control. I was left with the impression that Xemacs (and
its lisp) were dependable.

Since then it's been limited to incidental learning, like seeing examples
and trying to figure them out. Eg, consider Gabriel's "Worse is
Better" essay. The section "Good Lisp Programming is Hard"
http://www.ai.mit.edu/docs/articles/good-news/subsubsection3.2.2.4.html
gives this example

(defun make-matrix (n m)
(let ((matrix ()))
(dotimes (i n matrix)
(push (make-list m) matrix))))

(defun add-matrix (m1 m2)
(let ((l1 (length m1))
(l2 (length m2)))
(let ((matrix (make-matrix l1 l2)))
(dotimes (i l1 matrix)
(dotimes (j l2)
(setf (nth i (nth j matrix))
(+ (nth i (nth j m1))
(nth i (nth j m2)))))))))

and says the above is both "absolutely beautiful, but it adds
matrices slowly. Therefore it is excellent prototype code and
lousy production code."

The pythonist can only wonder, before such code, whether the transform
consisting in replacing all parentheses with zeroes (eg null strings) is
reversible; and how it could be doctored to be reversible, if it isn't.

On a sideline, shouldn't the "absolute beauty" of the code mean that a
good enough compiler should *understand* well enough its intent
to substitute more appropriate code ? Of course, we would supply the compiler
simultaneously with the complete layer of methods.

The next step would be to integrate our intelligent compiler in the IDE, so
that the student having typed the above would be proposed coherent completion
upon typing " (defun substract-matrix ..." or " (defun multiply-matrix ..."

Cheers B

 

[Kenny Tilton]

The very uniformity of everything (including operators?) being a
possibly recursive list and the actual practice of relatively deep
(compared to Python and similar languages) nesting. If a lisp
expression ends with 10 to 20 closing parentheses (which I have seen),

Not often, I hope. Then again, I for one hate too much code in one
function or even too much code in one source file! So I break things up
a lot. Funny thing is, I do not end up with a lot of functions for
functions' sake, things just tend to be reusable.

This one is really personal taste. I think I have a very low tolerance
for lotsa code in one place.

OTOH, lotsa closing parens means highly functional code. That is very
good for code quality.

kenny

 

[Michele Simionato]

One of Python's strengths is that you can create powerful abstractions with
functions and classes. But no matter what you do with these, they will always
be functions and classes that adhere to some common language rules. There is
no way to go "over the top" and change the language proper.

This is a mere illusion. There are metaclasses and descriptors now.

Right now I can
read everybody's Python code (unless deliberately obfuscated); this would
change if there were macros that were so powerful that they would change
language constructs, or allow new ones. Maybe they would make your problesm
easier to solve, but Python itself would lose in the long run.

My $0.02,

We already have things worse than macros. Still I am not suggesting we
should add them, because of KISS. But the idea of Python being well
behaved is a mere illusion, however well kept. See my other posts
on "macros revisited" for more on this.

Michele Simionato, Ph. D.
(e-mail address removed)
http://www.phyast.pitt.edu/~micheles
--- Currently looking for a job ---

 

[Michele Simionato]

For observational evidence of this, I suggest my own
subfields, computational biology and computational chemisty.
In the first there are bioperl, biopython, biojava, and bioruby,
all with active participants and a yearly confererence organized
by open-bio.org. But there is only a rudimentary biolisp project
with minimal code available and just about no community
involvement. In the latter, Python takes the lead by far over
any language other than C/C++/Fortran with commercial support
for a couple toolkits and several more free ones beyond that.
There's even a workshop in a couple weeks on the representation
of biomolecules for Python. There are also some Java and C++
toolkits for chemical informatics. And again, there is no Lisp
involvement.

I ask you why. And I assert that it's because Lisp as a
language does not encourage the sort of code sharing that
the languages I mentioned above do. So while it is very
expressive for a single person, a single person can only
do so much.

Andrew
(e-mail address removed)

I would say simply that Lisp has a much steeper curve than Python
& comparable languages. Scientists want to do science, not CS.
Moreover, they typically don't have very hard programming problems
(I mean conceptually, not numerically). So, a scripting language is much
better for somebody who is simply a CS amateur, with a different field
of research. On the other hand, a CS academics would probably prefer
Lisp/Scheme over a scripting language, at least I think.

That said, I do agree that the presence of hundreds of dialects works
against the adoption of Lisp. For instance, this stopped me (together
with other factors).

Michele Simionato, Ph. D.
(e-mail address removed)
http://www.phyast.pitt.edu/~micheles
--- Currently looking for a job ---

 

[Jacek Generowicz]

That said, I do agree that the presence of hundreds of dialects works
against the adoption of Lisp. For instance, this stopped me (together
with other factors).

So why did the presence of "hundreds of dialects" of scripting
languages not stop you adapting a scripting language ?

As I've mentioned elsewhere; objecting to the existence of multiple
dialects of Lisp (essentially, languages which represent their source
code in a form they can easily manipulate), as as daft as objecting to
the existence of multiple dialects of the Algol Language family, or to
the existence of multiple languages with significant indentation.

 

[Neil Hodgson]

David Abrahams:

BTW, the C++ preprocessor is a fairly weak macro system. A higher
level metaprogramming facility that knows more about the underlying
language could be a lot cleaner, clearer, safer, and more expressive.

What do you think of OpenC++?
http://www.csg.is.titech.ac.jp/~chiba/openc++.html

Neil

 

[Michele Simionato]

So why did the presence of "hundreds of dialects" of scripting
languages not stop you adapting a scripting language ?

As I've mentioned elsewhere; objecting to the existence of multiple
dialects of Lisp (essentially, languages which represent their source
code in a form they can easily manipulate), as as daft as objecting to
the existence of multiple dialects of the Algol Language family, or to
the existence of multiple languages with significant indentation.

I disagree.

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, at
least at the syntactical level (which DOES matter when you learn a
language, since you must memorize the syntax too) and on the conceptual
level too. 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.

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, 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, if you prefer the term
implementation to the term dialect. On top of that, how am I supposed
to choose my implementation? Too much choice (meaning a too much fragmented
community) can scare potential lisp newcomers. 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. The goal of
PyPy or Stackless is to enhance CPython, but taking CPython as base
reference. In Scheme there is no such a basic reference, I am correct?
Lisp has CL, but learning CL will not help me very much with Emacs
Lisp which is what I would need the most I am joking a bit here;
BTW, we are going as bit off topic, so let me stop here.

Michele Simionato, Ph. D.
(e-mail address removed)
http://www.phyast.pitt.edu/~micheles
--- Currently looking for a job ---

 

[Jacek Generowicz]

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
languages.

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
Jython?

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
with Python.

Lisp which is what I would need the most I am joking a bit here;

No. You are _completely_ joking

 

[John J. Lee]

Mario S. Mommer:

Lisp is simple.

(<operator> <item-1> <item-2> ...)

Where's the problem?

Quantum mechanics is simple. It's just H | psi> = E | psi> [...]
Since then it's been limited to incidental learning, like seeing examples
and trying to figure them out. Eg, consider Gabriel's "Worse is

[...]

Amusing interactive scheme tutorial:

http://www.ifarchive.org/if-archive/games/competition96/lists/lists.z5

To be run on one of the bazillion Zcode interpreters out there (Z code
is the bytecode used by Infocom for their old text adventures):

http://www.ifarchive.org/indexes/if-archiveXinfocomXinterpreters.html


John

 

[Jacek Generowicz]

This is a tautology. If a Lisp is Common, then it is Common Lisp.

I'll assume you forgot a smiley, and let this pass, otherwise we'll be
stuck here forever.

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.

Indeed, and therefore it is important (in the current context), to
clear up the confusion. So I state once again:

Saying that a language is a "dialect of Lisp" is similar to saying
that a language is "in the Algol Family"; in both cases it is a
statement about the style of syntax on which the language is based,
and leaves open the possibility that it has little else in common
with other languages in the family.

In Lisp I would agree there is a basic reference, i.e. CL.

"In the Algol Family I would agree there is a basic reference, i.e
C++."

Sorry, no. (As much as I would like the other Lisps to go away
it's just factually incorrect.)

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?

Yes, but what if you don't like Lisp (I'll be generous, and include
Scheme under this name , but you do like Python ?

 

[Bryan]

Using Python at all we are trading cpu cycles for higher level

abstractions and better programmer productivity. Why not add Macro's
allowing those of us who know how to use them and like them to use
them. If you hate macros, or you think they are too slow, just don't
use them. They don't change the underlying language, they just add a
more useful abstaction capability into the language.


Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")

but, if someone on my team adds macros to our project, does that mean i'm now forced to learn a macro language?

also, can someone please post a fictituos example of what a macro language might look like and do for me in python? i don't
understand what he benefit would be.

thanks,

bryan

 

[Jacek Generowicz]

but, if someone on my team adds macros to our project, does that
mean i'm now forced to learn a macro language?

But, if someone on my team adds classes to our project, does that mean
I'm now forced to learn a class langugage?

But, if someone on my team adds functions to our project, does that mean
I'm now forced to learn a function langugage?

also, can someone please post a fictituos example of what a macro
language might look like and do for me in python? i don't
understand what he benefit would be.

I have posted some examples of what _macros_ might do, and how they do
it, in the "macro FAQ" thread.

 

[Christian Tismer]

Michele Simionato wrote:

....

There is only one dominant implementation of Python, CPython.

This is correct, so far. Given some time, this might change.

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. The goal of PyPy or Stackless is to enhance CPython,
but taking CPython as base reference. In Scheme there is no
such a basic reference, I am correct?

Not really.
The goal of Stackless is to enhance CPython, while keeping
maximum compatibility. This is really really hard, due to
the restrictions imposed by the C language.
Jython will probably catch up, if somebody is going to
feed Samuele, who really needs support (hint! hint!).
Psyco, in its current state, is also bound to CPython and
tries to enhance it (with remarkable success).

But PyPy, after all, tries to be a lot more.
It finally wants to replace the CPython source by its own.
It wants to be a generic Python platform that allows to deduce
all of the other variants at once. Or, more generally speaking,
it tries to allow all of these to be implemented, using its
generic framework. None of these projects has tried it so far,
but my first goal next sprint is to investigate what it takes
to make PyPy stackless, and which (of several possible) approaches
to use.
PyPy wants to subsume Stackless, Jython, Psyco and some more,
at the same time. And all the developers of these extensions
to CPython are in the PyPy group, not to forget about Guido,
himself, who is happy to play with new alternatives.

So think of PyPy as the level of abstraction that CPython never will
be able to reach. (I really hope to reach it menatally all the
time, since this is not trivial
It is one of PyPy's goal to be able to reduce itself to an efficient
variant of CPython, with the hope to be even more efficient.
But understand this as one of the visions that keeps us going,
and the targets are months and years away. But we will reach something.
PyPy has the best developers I could think of (well, some are
missing whom I know well, too, and I would drop out for them to
be there, hi Tim).

--- Currently looking for a job ---

Me too, unfortunately

ciao - chris

--
Christian Tismer :^) <mailto:[email protected]>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/