Python's Lisp heritage

[James J. Besemer]

Andrew Dalke wrote:

> James J. Besemer:
> >Seems to me the more prominent genetic similarities are the overall
> > semantics: late binding, garbage collection, lists and sequences as
> > a way of life.
>
> Those are also present in Perl, Tcl, Smalltalk, APL, Mathematica,
> and many other languages.

All much (decades) newer than Lisp.

> Yes, Lisp was there first, but it's only an
> indirect influence on Python.

I hereby once and for ever more retract my casual suggestion that Lisp had or
may have had any direct influence on Python.  I was clearly in error, in part
having specifically mis-remembered some statements I read long ago by Guido,
which in retrospect I find I had completely backwards.

That being said, I guess I just don't get the strong reaction to this secondary
point.  I'm new here but I get the impression that "lisp" is a naughty word,
for some unfathomable reason (unless it's simply that it's syntax sucks).  For
me to say Python shares many concepts from Lisp is intended as praise.  You
react as if it's some kind of an insult.

Actually, it makes me think a little less of the language designers, if so many
good things from Lisp evidently were picked up by accident rather than as a
conscious design choice (if that's truly the case).

> >  Also, the fact that functions are values that may be free rebound
> > to other names.
>
> And Perl and Tcl and ...

And APL and others, but again Lisp was one of the principle origins of this
concept, decades before all the rest.

> >  MAP, APPLY, and especially LAMBDA also are pretty unique to Lisp.
> >  This is VERY like Lisp and very UNLIKE "Algol like" languages.
>
> I first learned about map through Perl.  That's also where I learned
> about anonymous functions, although Perl doesn't use the word 'lambda.'

IIRC, Larry Wall expressly acknowledges Lisp's contribution for these features
and others.

> They were added to Python just before the 1.0 release, as a contribution
> by someone other than Guido.  He's noted for saying way back in 1994
> ] To be honest, I wish I hadn't introduced lambda, map, filter and
> ] reduce -- they support a style that is inconsistent with the rest of
> ] Python. ...

That's disappointing to hear.  I thought including the ability to do some
functional-style programming was a great thing.  Somebody else here or in one
of the books I read recently I thought said support for functional programming
was a good thing.

> One long-time complaint about them is that they weren't lisp-like
> enough, for example, in how lambda handles scope.  Python used to
> be quite different than Lisp in how it did static scope.  But as I
> recall, others have pointed out that some lisp handle scoping
> differently than others, and closer to how Python does it.

Originally Lisp ONLY had dynamic scope, like Perl, which is weird.   Scheme
adopted lexical scope which is how Python 2.2 works by default.  In between,
yes, different Lisp implementations experimented with different approaches,
because dynamic scope is so weird and intrinsically slower than static.

> BTW, the first two features are best done in modern Python using
> list comprehensions and the f(*a, **kw) syntax.

"best" is a value judgment.  But it's true MAP could be defined as a user
function and apply appears to serve no actual value I can discern.

Lambda however seems useful, judging by the number of times it seems to show up
in code examples.

> Oh, I believe there's a lot of indirect influence on Lisp on Python,
> just as there is on most every other language.  Even the first language
> I wrote (a BASIC written in BASIC) likely had some influence from Lisp,
> and that was before I knew the language existed.

> I just argue that there are few direct influences.

Noted.

> I think you misunderstood my statement, but then again, I wasn't
> very clear.  Lisp's idea of lists is as a composition of pairs.  As
> such, certain operations like list indexing are (usually) slow, while
> list mutation is fast.  On the other hand, Python uses a contiguous
> block of memory, so indexing is fast but mutation (other than append)
> is usually slow.

I think you misunderstood my comment but it was about Lisp anyway so never
mind.

In any case, Python clearly made the CORRECT choice, as generally indexing
(access) is the more frequently used operation once a data structure is built
up.

And certain types of mutation, particularly append, do not necessarily have to
be slow.  I assumed the language inventors would provide some extra space at
the end of each list so that append could be almost instant (except for every
Nth one).  Same as hash arrays can be fairly efficient if you don't make them
too small.  But I thus far never looked into Python's implementation and now
you make me wonder.

> So algorithms which might run fast under Lisp do not under Python,
> and vice versa.

I can think of few examples where Python would necessarily be slower than Lisp.

Where Python suffers a disadvantage I suspect the difference has more to do
with implementation details, such as going with reference counting rather than
a higher performance garbage collection scheme.

> The decision for this difference was made after
> observations in ABC that most list use was through indexing, and not
> through a direct decision to be different from Lisp.

After this discussion I'm guessing a lot of the lisp heritage crept in
unnoticed via ABC, which has a number of the shared traits.  So I was right to
see the similarities but wrong to attribute it to any conscious choice.

> >> ] Python comes from the Algol family of languages.
> >
> >In syntax yes.  In semantics it seems quite the opposite.
>
> I've heard the statement from Lisp people that all other languages
> are an attempt to reproduce Lisp, badly.

I don't consider myself to be a "Lisp person."  I suppose it dates me that I've
simply been around long enough to have learned the language well enough to
appreciate that it deserves a lot of respect.  And when you look at the
totality of features, Lisp and Python have a tremendous amount in common.

That being said, I think Python is better than Lisp or Scheme in almost every
way.  The key innovation to my eye is the combination of a rich semantics of a
late binding language like Lisp (and a host of other more recent languages)
with an ALGOL like syntax.  Syntax was one of Lisp's worst characteristics and
the 40+ year old Algol if/then/else/while/do surface syntax has emerged as a
clear winner.

Here, I only object to saying Python comes from Algol because, other than the
surface syntax (and the connection is fairly loose there) the languages are
radically different.  To me, the "Algol family" all means early/static binding,
a small number of base types and arrays, maybe structs as the only user
abstraction.

> >> ] Common Lisp and Scheme.
> >> ]
> >> ] These languages are close to Python in their dynamic semantics,
> >
> >Which was my point.
>
> You said Python was a "Lisp derivitave" with the use of len(obj)
> based in "precedent dating back to the original language."  You
> also said "Python claims a Lisp heritage."

I didn't say "it was".  Rather my exact words were, "it seems" and "I expect".
Clearly I was admitting to some speculation on my part in the matter.

> I am not attempt to say that Python and Lisp don't have similar
> semantics.  What I am saying is that these specific points you
> made are not correct.

See my retraction above.  Despite all the nit-picking, you have agreed that
there are many similarities.

And I think my original comments about len() still hold weight.

> Python isn't a Lisp derivative, except in
> the sense that all modern languages have Lisp influence.

Not true.  Java and C++ are modern languages that have comparatively little in
common with Lisp.

> And that's not the sense you mean since you said "So from a linguistic
> heritage standpoint, it's actually rather odd that Python lacks
> some equivalent of Scheme's IF."

See retraction above.

Strike "from a linguistic heritage standpoint, it's".  Insert "I find it to
be".

> > I don't agree.  I think syntax and semantics are almost orthogonal,
> > with syntax being the less complicated, less important of the two.
> > The fact that Python and Scheme have similar semantics make them very
> > similar despite dramatic differences in their outer appearance.
>
> Spoken, by the way, like a Lisp programmer.

You don't have to resort to insults.  ;o)

> I found that language
> almost impenetrable because of the syntax and my several attempts to
> learn the language have failed.  I enjoy Python's semantics, which
> implies at least to me that syntax is very important.  Perl and Python
> classes also have similar semantics -- Perl got them from Python --
> but I couldn't figure out how to do OO programming in Perl because
> the syntax was so cumbersome.

You misread my statement.  I never said syntax wasn't important.  Rather I said
they were orthogonal, which means largely independent.  That is languages with
similar semantics might vary considerably in syntax. E.g., Lisp, Perl and
Python.  Similarly, languages may have very similar syntax and yet depart
considerably in semantics.  E.g., Java, C++ and C# all share a very similar
syntax although they have considerable differences in semantics.

Your anecdotes about lisp and Perl I think MAKE my point.  I agree that Lisp's
and Perl's syntax are significant barriers to understanding, at least for some
people.  That's why I LIKE Python so much.  It's the best way I've seen thus
far for interfacing to all that functionality.

> The only this I can add is that after watching many non-programmers
> (biologists, chemists, and physicists) learn Python, *none* have
> complained to me that list.len() doesn't work.

Well if they never complained then we'd be silly to listen to the complaints of
professional programmers who do find it odd.

Really, what's so wrong about adding a synonym?

> Instead, since your commentary is at least partially based on a
> view of history which is incorrect, I decided to comment on that
> instead.

Thanks for setting the record straight.  Sincerely and truly.

> I could also have pointed out that except for metaobjects (which in Python
> comes more from a Smalltalk heritage) the way Python has done classes
> has effectively not changed in the last 10 years, so another statement
> you made

> > over time Python has increasingly placed much greater emphasis on Objects

> is suspect.  But I don't have a firm understanding of the history of
> that aspect of Python's history to back up my belief.  Neither, I
> believe, do you.

Here I was talking about changes in the several years SINCE I've been an avid
user, so I was not speculating.  While it's true that some things have not
changed, there has been a lot of activity to change the language in a way that
places a greater emphasis on Objects.  Seems to me the entire effort to
consolidate "types" and "objects" is a tremendous amount of work to shift in
the OO direction.  Similarly, my original example, where "".split() used to be
an error but now it's ok -- why the hell did len() get left behind?  Now you
don't even have to import string to get at the string library, as most of the
functions are now part of the "string class/type."  And, oh yeah, Metaobjects
-- that counts too, right?  So I think it's perfectly valid to say Python's
emphasis on OO has increased over time.  Don't you agree?

I hope you don't take umbrage at anything I say here.  I think civil arguments
are a way for both parties to learn.  I certainly learned a few things, at
least about Python "heritage".

Regards

--jb


--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com