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

[maney at pobox.com]

Carl Banks <imbosol at vt.edu> wrote:
> You mentioned the problems with passing a lot of parameters into a
> function when I said I liked to factor the set-and-test chain into its
> own function so I could use return to break out of it.  At least,

Ah yes, I see.  I might also have referred to that as a drawback of the
logic-becomes-data approach.  It's a good point, although for some
reason - this is interesting - I don't seem to feel that this is nearly
so much an issue for a function that wraps the get-stuff-to-test logic
as the process-stuff-this-way part.  I guess that would be reflecting
my own experience w.r.t. how often there's an annoying amount of local
context needed for those two different roles.  The implementation that
factors the whole switch out in order to [ab]use return as a workaround
would, I expect, suffer from that even more so, since it needs to be
passed all the context for all the tests and all the actions - OTOH, it
benefits by having that done all at once and only once... at least
until another case comes along that needs to reference another bit fo
state.

But it might avoid that if it were def'd as a nested function, if I've
got that straight?  I'm not sure I grok that in fullness - does the
nested def get recompiled on every call to the containing function, or
is it compiled once and then skipped?  Come to think of it, at least
some bits must be processed per call-of-containing or else some of the
recipies that bind to default args of the nested function wouldn't
work.  I think.  Pending further study of this small, simple language. 
<grin>

> But, if you write a function so that you do a lot of things before the
> if condition (which you said you could do when I said an assignment
> operator didn't cover the cases where you had a lot of things to do
> before the if operator), you would have the same problem.

There is a heuristic in my brain that begrudges the overhead of
packaging things in classes or functions in inverse proportion to the
benefit I perceive I'm getting from that packaging.  More or less -
there seem to be a number of parameters and hidden controls involved
that I doubt I can consciously describe with much accuracy.  But the
upshot is that if I'm doing "a lot" then it seems natural to spend
somewhat more effort on structuring it nicely, such as by factoring
that chunk of logic off into a function.

> Well, my feelings about generality are this: if you implement a
> partial solution, that leaves the possibility that you might implement
> a full solution someday, in which case the partial solution you put in
> before is now redundant.  But once you've put something in, you can't
> take it out without breaking backwards-compatibility, so you're stuck
> with it.

I'm not sure I really want to take part in a revival of the whole
do-the-right-thing versus godd-enough-is-good-enough discussion.  :-)

> I.e., it's generality for the sake of not having more than one way to
> do it.  Which, of course, is The Python Way(tm).

Yeah, I've seen that too, as well as the attempts to explain what the
catch phrase really means.  It seems to me that it is also Pythonic not
to forget that perfect generality often has a cost - this is coming
back around to my thought about how perfect generality might offer some
food for thought w.r.t. OP's inquiry.