Benefits of moving from Python to Common Lisp?

[Marco Antoniotti]

"Andrew Dalke" <dalke at dalkescientific.com> writes:

> Marco Antoniotti:
> >Historical cruft?  The evolution of the languages have been different.
> >The presence of strong vendors in the CL camp does (IMHO) work as a
> >disincentive to community wide standardization.
> 
> Interesting.  So by *not* having a strong advocacy for Python,
> there isn't the urge to have multiple competing implementations,
> so Python can keep developing new 'standard' libraries?
> 
> I like that approach -- less arguments and more code  :)

I guess :}

> 
> [Seeing that you didn't cross-post to c.l.lisp ..]
> 

I try never to cross post.  I believe it makes it difficult to follow
a discussion and it augments the noise.

> I always seemed to me too easy to make new Lisps, and many of the
> people doing Lisp argue for esthetic purity, which leads to the
> large number of variations in the language.

THis argument was true until the early nineties.  Now people make
(because it is relatively easy) new Scheme's, all slightly
incompatible.  Common Lisp is remarkably stable and with a large set
of primitives.

> Python has always felt more pragmatic, and pragmatically speaking
> it's easier to have one standard, reference platform from which
> other implementations derive, rather than through a language spec.

This is true of Python and Perl and other languages (INTERCAL
included :) ).  Common Lisp did simply not evolve like this.  In the
early eighties there was a lot of money being poured into "Lisp", and
vendors appeared very early in the process.  Once you have people with
a lot at the stake and you get committed to a stadardization process
you slow down.

The ANSI CL standard (not very usable as a tutorial, but very good
indeed) provides a sound and very flexible foundation upon which to
build various systems.  Unfortunately, whatever is not in the
standard, makes it relatively difficult to write "very" (note the
quotes) portable code.

Take the case of C/C++ interfaces.  Every CL implementation allows you
to interface to - at least - C.  This means that you could always link
in C code into your application.  However, in CMUCL you do it in one
way, while in ACL you do it differently.  And, up to this point there
has not been any incentive or energy to come up with either a
"reference implementation" for a C interface (a Foreign Function
Interface), or a specification document accepted by all the people
with a stake in CL.

> >As for  "widely used though non-standard libraries for CL for "doing
> >stuff like internet programming", you can check the CLOCC
> >(http://sourceforge.net/projects/clocc). Not much, but it is there.
> 
> I know little about CL systems, which is why I quoted the original
> statement from someone else.

Maybe it's time to have a better look at CL?!? :)

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.