Python syntax in Lisp and Scheme

Andrew Dalke adalke at mindspring.com
Thu Oct 9 02:21:35 EDT 2003


Me:
> > Or the people who prefer the awesome power that is Lisp and
> > Scheme don't find the limited syntax to be a problem.

Kenny Tilton:
> OK, here you are saying that only a certain subset of programmers have
> the genetic makeup necessary to prefer the unlimited syntax. Unlikely.

Yes, it is very unlikely that I would say that...

Oh wait.  I didn't.

I prefer speaking in English even if Navajo might be a better language
for expressing certain concepts.  That doesn't mean that preference
is part of my genetic makeup.

I prefer the mambo basic over the salsa basic when dancing.
Doesn't mean that's part of my genetic makeup.

>    ({function | macro | special-form} arguments*) => values*
>
> Roughly speaking (I'm no BNFer) but... hellasweet! You can chant
> "simplicity" as much as you like, but /that/ is simple.

Actually, you could have a more minimal language with

    (name arguments*) => values*

but Lispers must have decided that *some* syntax makes
things easier.

And you can get still more minimal with FORTH where the
syntax is

    WORD *

> But with Lisp
> there is a great honking special form (macro?) such as "defparameter"
> that grabs you by the lapels and screams "GLOBAL!!!".

The word "global" would scream "GLOBAL!!!" a bit more.

> But most of all,
> it manages to get the job done with The One True Syntax, using a

TOTS?  If there was no need for backwards compatibility, I'll
argue that swapping [] and () would be better, since I don't need
to use shift to use the [ or ] characters.  (On a US keyboard.  And
yes, I know I could swap the keyboard layout.)  Assuming there
was no other code in the world and no other Lisp programmers,
wouldn't that be a better syntax?

> You call that "limited"? Yer just flaming.

Yes, I'm calling it limited.  I didn't say limiting, which appears to
be what you read.

No, I'm not flaming.

> But go to c.l.l. and flame the syntax and you will discover it is
something
> Lispniks love.

In case you hadn't noticed, this is cross posted on c.l.l.

I am fully aware of M-expressions for Lisp.  I know about
Dylan and it's Lispishness in a infix language.  I know that
Lispers enjoy their syntax.  I know it's the source of the ability
to support macros and other on-the-fly code manipulation.

I am not asking any of them -- nary a soul -- to abandon Lisp.
Nor am I flaming the syntax.

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.

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

Yes, I know that the early teletypes might not have had
[ or ], and that car and cdr come from register names on
the machine Lisp was first implemented on.  If that's
indeed the justification then there may be a Lisp-ish language
which is equally as powerful, equally as elegant, etc *and*
which is slightly easier to learn and type.  But it wasn't chosen,
and it won't be used because of good social reasons: a huge
existing code base and people who now have Lisp "in their
fingers" and don't want to retrain for the slight advantage
that others might get.

"The One True Syntax" indeed.

(Okay, I admit it.  That one line was flaming *you*, but not
c.l.l'ers as a class.)

> And, as you concede, these are people who groove on the
> power of Lisp. Doesn't that make folks think they better go check out
> for themselves what these folks have discovered?

Sure.  More power to them.  For me, it looks like my
next really different language to learn might be OCaml.  ("really
different" because I needed to learn some Javascript recently,
and I don't find it different enough to give a different view of
the world.)

                    Andrew
                    dalke at dalkescientific.com






More information about the Python-list mailing list