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

[Bengt Richter]

On Thu, 21 Nov 2002 14:21:13 GMT, Alex Martelli <aleax at aleax.it> wrote:

>Paul Foley wrote:
>
>> On Thu, 21 Nov 2002 10:36:24 +0800, Maptek  wrote:
>> 
>>> Even if Python and Ruby have or will have the _capabilities_ that Lisp
>>> has, (Python (will (never (be (lisp))))).
>> 
>> Then it'll never have the _capabilities_ that Lisp has; because the
>> syntax is the major source of those _capabilities_ that distinguish
>> Lisp from lesser languages.
>
>It seems to me that Dylan is a creditable attempt to deny this assertion -- 
>Dylan has no lisp-oid syntax, yet Dylan's capabilities do appear to be 
>quite similar to Lisp's at least at the level of approximation that "major 
>source" would seem to entail.
>
You may find it interesting that Dylan started out "lisp-oid" ;-)

In '93 I sent for Apple's Dylan manual, and the version copyright 1992
(which I still have) starts out the "Syntax and Semantics" chapter with
a "Lexical Notation" subheading followed by

    "Dylan programs are written using a parenthesized Lisp notation.[4]"

Footnote 4 said, "A future version of Dylan may support Algol-like or
other syntax in addition to Lisp syntax."

>From the introduction in that book:

    "Dylan is a simple dialect of Lisp with a thoroughly integrated object model..."

and

    "To those familiar with the Lisp family of languages, Dylan looks like
Scheme augmented with CLOS. However Dylan is not intended primarily for
the Lisp community. The real target audience of Dylan is application developers
now [1992] using languages such as C, C++, and Pascal who are ready to move
up to Object Oriented Dynamic Languages. Thus compatibility with other List
dialects such as Scheme and Common Lisp is not a primary goal. Dylan has been
rethought from the ground up, on a fully object oriented foundation. A primary
goal was to make the language as simple as possible, but no simpler. We have
tried to avoid multiple ways to do the same thing, to omit features that
are difficult for the average application developer to understand and use effectively,
to leave out anything that we do not know how to implement efficiently in both
space and time, and to provide a clear separation of the language executed at
run time from the development tools..."

(my [1992] annotation).
Anyway, Dylan's link to Lisp would seem pretty explicit historically, whatever the current
status (which I haven't followed... so many pretty things, so little time ;-).

ISTM that power comes from clean abstractions first, and representation syntax third.
What comes a close second to the first is that the syntax support operating on
representions as such in a way that well models the operations you are
trying to do with the corresponding abstract entities and their relationships.
The best abstractions are ones that can easily be found and assembled to reflect
the structure and dynamics of the concrete without introducing illusory aspects.

IOW, ISTM what you want to do lives in the abstract world. Representations are a necessity,
but they should not get in the way, or distort semantics or add irrelevancies. The best
representations make imagining the abstractions easy, and have transformations that
correspond to useful transformations in the abstract.

Lean domain-specific syntax makes it easier for domain specialists to focus on the essentials
when thinking about their problems, but the down side of a capability to create specialized
syntax is inappropriate use and muddying the concept space of a clean and adequate base language.

My .02 USD ;-)

Regards,
Bengt Richter