Why is Python popular, while Lisp and Scheme aren't?

Pascal Costanza costanza at web.de
Sun Nov 10 08:45:30 EST 2002


Andrew Dalke wrote:
> Pascal Costanza:
> 
>> I have recently switched over to Common Lisp as my language of choice 
>> and have written an article about it, to be found at 
>> http://www.pascalcostanza.de/lisp/guide.html - you might find it 
>> worthwhile.
> 
> It's a discussion of Lisp, with only a few points specifically of
> why you switched from Java to Lisp and one mention of Python.  (There
> were two references to Monty Python, from which Python the language got
> its name.)  I was hoping for a more philosophical rumination of why
> you chose Java over Python.  :(

This was merely an accident. Back in 95 I based my diploma thesis on 
Java, and this decision was influenced by many factors. It wasn't until 
recently that I learned about Python.

> Some points that are weaker in a Python/Lisp comparison are
> 
>  - Python doesn't have as many "funny names" as Lisp

I guess you are referring to "car", "cdr" and the like. They're actually 
not funny but very useful. ("car" returns the first element of a list, 
"cdr" the list of all elements but the first. You can also use "first" 
and "rest" instead, and also "second", "third", and so on, and also "nth".)

>  - Python also does run-time typing rather than static typing

Yes, I like that. :)

>  - You say
>  > Please remember that due to their syntax, C-like languages and Pascal 
>  > might also run into trouble when curly braces or begin/end keywords
>  > are used incorrectly in conjunction with control statements (like if,
>  > while, switch/case, and so on)
> 
> But Python doesn't have that problem, given neither braces nor begin/end
> keywords.  Indeed, you seem to suggest that all Algol-derived languages
> are like C/C++/Pascal/Java in having explicit delimiters, a separate
> compilation step, static typing,

You're right, I should be more careful with my wording in this regard. I 
will check that.

>   - You say:
>  > A nice thing about Lisp is that it doesn't noticeably distinguish
>  > between built-in functions and user-defined functions.
> 
> The same is true for Python.

:)

> You talk about Lisp's macro feature.  That's come up  several times
> on c.l.py.  I understand at least theoretically the usefulness of
> macros.  However, I am quite worried about the supportability of
> defining your own language on the fly.  For the comparison I would
> have like to have seen, I was hoping for comments on the
> maintainability of macros, especially given that some people like
> you have found "them to be conceptually quite simple and easy to
> write" while others find them "seemingly hard to understand."  I
> believe the answer is you want a language which emphasises your
> personal expressive power and not which which emphasises the
> team's/project's/group's power.

I don't think that Lisp favors personal expressive power over group's 
power. Maybe the group that uses Lisp has to agree on more conventions 
than in other languages (but I am not sure about that).

Macros are conceptually very simple: they just process lists of code 
before it is actually executed. This gives you lots of power, but of 
course you need to be a good programmer to be able to wisely use this 
power. Lisp is a programming language for experts.

> I read your mention that Lisp allows recoverability at the place
> where the exception took place.  I recall reading in my progamming
> languages book back in college that that ends up not being all that
> useful, but I can't provide a reference for that now.  In my
> own current thinking, I agree with the book.

It can be useful in some situations. For example, imagine you have a big 
and expensive calculation running, and after, say, three days there is a 
little bug in some code section that handles a very special case. In 
Common Lisp there's a chance that this bug throws a correctable error 
(exception) - this is reported at the Lisp prompt. Then you can correct 
the buggy code section and try to restart the calculation at the spot 
where the error occurred, without any loss of intermediate results.

Similar situations are conceivable for example in the case of web 
applications that you usually don't want to shut down, etc.

I think that correctable errors are less useful in languages that don't 
offer some form of interactivity.

> So I would also have prefered more examples of why a feature was
> not only available in Lisp but why that feature is useful for
> most programming tasks.  (And you are a fan of "practical things
> that you need in every-day programming" so should stress usefulness
> over ability.)

Thanks a lot for your very useful feedback - I will try to incorporate 
it into future versions of my article.


All the best,
Pascal


-- 
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there 
are always circumstances when it is advisable not only to ignore the 
rule, but to adopt its opposite. - Paul Feyerabend




More information about the Python-list mailing list