[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Python for Lisp Programmers"
Or , to put it as simply and briefly as possible, in answer to "Why is Python considered lightweight and Lisp is not" , there are
Syntax matters. It matters a lot. Academic language designers seem to be most concerned with semantics, completeness, doing the
right thing, etc; but not as much concerned with syntax.
Syntax has an awful lot to do with ease of learning; a simple, intuitive, consistent syntax is very easy to learn. A foreign,
unintuitive, complex syntax is harder to learn.
Give people a language that gives immediate satisfaction, as in Eric Kidd's 6 hour teaching session below, and folks will get
"hooked" and wind up spending many hundreds of hours studying the intricacies of the language with great pleasure. Give folks a
language that is frustrating for the first six hours of learning, and they will likely not even finish the original six hours,
unless they are forced to.
----- Original Message -----
From: "Eric Kidd" <firstname.lastname@example.org>
Sent: Thursday, December 06, 2001 10:31 PM
Subject: Re: "Python for Lisp Programmers"
> 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
> 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
> 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
> * 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