Python syntax in Lisp and Scheme

Kenny Tilton ktilton at nyc.rr.com
Thu Oct 9 07:47:45 EDT 2003


Andrew Dalke wrote:


> What I said was that Python is *not* an application of
> Greespun's Tenth Rule of programming because 1) it isn't
> bug-ridden, and 2) because Python explores ideas which
> which had no influence on Lisp's development -- user
> studies of non-professional programmers.

I wouldn't take the Greenspun crack too seriously. That's about 
applications recreating Lisp, not languages copying Lisp features. It's 
just a reaction to Python (a perfectly nice little scripting language) 
trying to morph into a language with the sophistication of Lisp.

As for non-professional programmers, the next question is whether a good 
language for them will ever be anything more than a language for them. 
Perhaps Python should just stay with the subset of capabalities that 
made it a huge success--it might not be able to scale to new 
sophistication without destroying the base simplicity.

Another question is whether Lisp would really be such a bad program for 
them.

You presume that only Lisp gurus can learn Lisp because of the syntax. 
But methinks a number of folks using Emacs Elisp and Autocad's embedded 
Lisp are non-professionals. And let's not forget Symbolic Composer 
(music composition) or Mirai (?) the 3D modelling/animation tool, both 
of which are authored at the highest level with Lisp.

Logo (a language aimed at children, including very young children) cuts 
both ways: it's a Lisp, but it dumped a lot of the parens, but then 
again it relies more on recursion.

You (Alex?) also worry about groups of programmers and whether what is 
good for the gurus will be good for the lesser lights. What you are 
saying is that the guru will dazzle the dorks with incomprehensible 
gobbledygook. That does happen, but those kinds of gurus should be fired.

To the contrary, macros in the hand of truly talented developers allow 
the gurus to build Lisp up to a higher-level language with new 
domain-specific constructs to empower the rest of the team.

You dissed Brooks in an earlier article (in favor of a Redmund Clone, of 
all things) but you should go back and read him again. Especially No 
Silver Bullet and NSB Revisited. He has a lot of great insights in 
there. (Your Redmond boy is counting LOC to assess languages, apparently 
because he can understand counting LOC. hmmm....)

Brooks talks about productivity coming from greater expressive power, 
from having the language more capable of expressing things at the same 
level at which the programmer is thinking. (He also touts Interlisp at 
one point!) But in NSB he says languages have reached the conceptual 
sophistication of their users. What Brooks missed (despite his awareness 
of Interlisp, which he dug because of its interactivity) is what few 
people understand, again, that macros let you build a domain-specific 
HLL on top of Lisp.

On a suffciently large project (well, there's another point: with Lisp 
one does not hire ten people (unless one is doing three projects)) the 
team should be divided into those who will be building the 
domain-specific embedded language and those who will be using it. 
Ideally the latter could be not just non-professional programmers, but 
even non-programmers.

> 
> Where are the user studies which suggested () over [], or that
> "car" is better than "first"/"1st" or that "cdr" is better than
> "rest"/"rst"?

Studies. You use that word so much. A good study is hard to find. You 
loved McConnel's LOC nonsense, but it is worthless. Ooooh, numbers! Look 
at all the numbers! [why [dont you] [just] [type out [a form [with [lots 
of brackets]]] and [see what [they [look [like]]]]?

They [ook [ike He[[.

-- 
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
  http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey





More information about the Python-list mailing list