Python syntax in Lisp and Scheme

[Andrew Dalke]

Pascal Costanza:
> I guess this reflects his experiences when he has learned Lisp in the
> beginning of the 80's (AFAIK).

But the talk wasn't given in the early 80s.  It was given in the early 00s.
And it implies that Lisp is still strange that way.  OTOH, you aren't him
so it's not fair of me to ask you all to defend his statements.

> Yes, scripting languages have caught up in this regard. (However, note
> that Common Lisp also includes a full compiler at runtime.)

However, that's an implementation difference -- the only thing
users should see is that the code runs faster.  It doesn't otherwise
provide new functionality.

> > The phrase "they had hard-headed engineering reasons for
> > making the syntax look so strange." reminds me of the statement
> > "better first rate salespeople and second rate engineers than
> > second rate salespeople and first rate engineers" (and better
> > first rate both).  That's saying *nothing* about the languages;
> > it's saying that his viewpoint seems to exclude the idea that
> > there are hard-headed non-engineering reasons for doing things."
>
> No, that's not a logical conclusion.

I used those wishy-washy words "reminds me" and "seems".  ;)

> These abbreviations seem strange to a Lisp outsider, but they are very
> convenient, and they are easy to read once you have gotten used to them.
> You don't actually "count" the elements in your head every time you see
> these operators, but they rather become patterns that you recognize in
> one go.

I did know about cddr, etc. from Hofstadter's essays in Scientific
America some 15 years ago.

> I don't know how this could be done with 1st, rst or hd, tl respectively.

Okay, I gave alternatives of "." and ">" instead of "car" and "cdr"
"." for "here" and ">" for "the rest; over there".  These are equally
composable.

. == car
> == cdr
cadr  == >.
caddr == >>.
cddr == >>

> Pick your choice. "There is not only one way to do it." (tm)

Perl beat you to it -- "TMTOWTDO" (There's more than one way to
do it.).   ;)

Python's reply "There should be one-- and preferably only one --
obvious way to do it."

> The learning curve is steeper, but in the long run you become much more
> productive.

Which brings us back to the start of this thread.  :)

                    Andrew
                    dalke at dalkescientific.com