merits of Lisp vs Python

[Greg Menke]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> André Thieme <address.good.until.2006.dec.22 at justmail.de> writes:
> > > import module
> > > module.function = memoize(module.function)
> > 
> > Yes, I mentioned that a bit earlier in this thread (not about the
> > "during runtime" thing).
> > I also said that many macros only save some small bits of code.
> > Your python example contains 4 tokens / brain units.
> > The Lisp version only has 2.
> 
> You shouldn't count the import statement, since you'd need the
> equivalent in Lisp as well.
> 
> Contrast the much more common
> 
>   a[i] = b[n]
> 
> with
> 
>   (setf (aref a i) (aref b n))
> 
> and the attractions of Python may make more sense.

Not really.  The syntax of getting and setting array elements isn't
really the point.  It ignores the cognitive efficiency of Lisp when
things get more complex, and likewise whatever similar characteristics
that Python offers.  I don't mean to imply Python is inefficient, just
that array manipulation syntax isn't where the two languages' strengths
& weaknesses appear.  To compare the languages when things get
complicated, in effect, to see how they help and how they hurt when
problems are difficult, then a more complex example is necessary.  Since
the arguments so far seem dominated by syntactical trivia, they seem to
me more about perceived aesthetics and personal preference than anything
else.

I spent a year or so using Python as a scripting language for relatively
simple applications where shell scripts were insufficient.  It works
fine as such.  But it began to suck performance-wise when I started
trying to manipulate more complex datasets and I began wanting
compilation to get throughput up.  Common Lisp, being a highly mature
language (and thus sometimes ossified in appearance), offered a
standardized language with a variety of implementations, some of which
gave me the compiler tools I needed without forcing me to retool
concepts and source code from the freebie implementations I started
with.  This is a very important point once there is considerable
conceptual investment in a suite of source.

When the New & Cool arguments are presented, this issue seems neglected.
There are many tradeoffs to be made between New & Cool and Highly
Matured, syntax being only one.

Gregm