Re: "Python for Lisp Programmers"

[Eric Kidd <address@hidden>]

On Thu, 2001-12-06 at 16:12, Scott McKay wrote: 
> BTW, I'm not trying to *prove* that CL is light-weight, because I think that
> it is not.  What I am trying to winkle out is, why do some people think
> that Python *is* light-weight, when Python is sooooo close to CL in so
> many ways?  I'm picking these two languages precisely because they
> are so similar, yet the perception of them is so different.

Python and Common LISP are among my favorite programming languages, so
let me take a stab. 

Things that help make Python "light", for an unspecified definition of
that term: 

1) Surprisingly gentle learning curve, across a variety of backgrounds. 
Non-programmers, C programmers and LISP programmers all seem to pick it
up fairly quickly. 

2) Good support for "programming in the small": a listener, single-file
programs, a well-chosen set of standard libraries and an easy way to
define your own libraries. (Python is also quite reasonable for
"programming in the large", but that's another story.)

3) Amazingly simple integration with existing code.  The Python C
API--which supports both extending Python, and embedding it as a
scripting language--is exceptionally easy to learn and use.

4) A lightweight environment.  Python is easy to install (in fact, it's
part of most Linux distributions) and easy to run.  It's also generally
easy to distribute Python software. 

5) A certain elegance of design, largely thanks to Guido's central
control. 

Things that make Common LISP potentially "heavy": 

A) Lots of bizarre names: car, cdr, cons, set, setq, setf, defun,
defsetf,  etc.  Individually, many of these are reasonable.  Taken
together, they're less than charming. 

B) Poor conceptual coherency.  The ANSI Common LISP committee displayed
a somewhat less, um, unified design sense than might be desired.  And
piecemeal historical growth led to messes like the aforementioned 'set',
'setq', 'setf', defsetf, (define (setf foo) ...), etc. 

C) Lousy deployment stories: incompatible implementations, tree shakers,
clunky modules, $500 *academic* runtime licenses, no portable C FFI--you
name it, the Common LISP community did it.  Common LISP is basically for
(1) in-house use or (2) pre-compiled, monolithic applications.  It's not
like I can write scripts in Common LISP and expect them to run on a
random user's system.

D) The LOOP macro.

These are all very subjective criteria, I think. ;-) 

For me, "lightness" isn't solely about the language or the
implementation or the packaging--it has to do with the complete
experience.

A fun example: I once gave a pair of C/Visual Basic programmers a
six-hour introduction to Python.  Nine months later, I came back and
found a bunch of stark, raving Python fanatics with a successful
deployment behind them.  I can't *do* this with Common LISP, for all of
the above reasons and then some.

...

On another note, I think we're experiencing the start of a renaissance
in language design.  Consider:

  * Languages like Python, Java, and Dylan
  * Compiler advances in the Scheme and SmallTalk communities
  * Neat push-the-envelope projects like Proto and ARC
  * Interesting (but poorly known) ideas from JavaScript
  * Lots of new algorithms for type checking, multiple dispatch, etc.
  * Cross language component work, including .NET and the lang-dev folks
  * Python's support for iterators (in a mainstream language!)
  * The massive explosion of CPU power

All in all, I expect to see some deeply cool new languages in the next
decade.

Cheers,
Eric