Python syntax in Lisp and Scheme

[Alex Martelli]

Doug Tolton wrote:
   ...
> I can understand and respect honest differences of opinions.  I too

If so, that makes you an exception in the chorus of lispers who are
screaming against my alleged idiocy and cluelessness (though I
seem to remember you also did, but I may be confusing people "on
your side" -- it's been a LONG and unpleasant thread).

> believe that causes of divergence are largely sociological.  I differ
> though in thinking that features which allow divergence will necessarily
> result in divergence.

I don't think it _necessarily_ will, just that it increases probability by 
enough to be a concausal factor.


> I have this personal theory (used in the non-strict sense here) that
> given enough time any homogenous group will split into at least two
> competing factions.  This "theory" of mine had it's roots in a nice

Unless there's a common enemy who's perceived to be threatening
enough to the whole group -- this is probably the single strongest
unifying factor ("united we stand, divided we fall" -- if people are scared
enough to believe this, they may then remain united).

But the amount of time and other external factors needed to eventually 
promote divergence varies with internal factors -- and in cases where
technology plays a key role in the group, then the details of that
technology matter.  Some technological aspects intrinsically promote
convergence and cooperation and thus may help counteract sociological
factors working in the other direction -- other technological aspects
facilitate divergence.  "In the long run we're all dead" (Keynes), so if
the time needed for divergence is not enough, divergence will not
happen within the group's lifetime;-).


> However in the opensource world I expect splinters to happen frequently,
> simply because there is little to no organizational control.  Even

And you would be wrong: forks are much less frequent than your theory
predicts.  Read some Eric Raymond to understand this, he's got good
ideas about these issues.

> Python hasn't been immune to this phenomenon with both Jython and
> Stackless emerging.

Neither of them is a fork, nor a splinter, nor a split.  Jython tracks the 
Python standard (as much as it can with far too few core developers)
and the Python standard has been modified to allow Jython to conform
on some points (e.g. timing of garbage collection).  Stackless has been
rewritten to become a patch as small as possible on standard Python.

And if you look at the people involved, well, I've seen Samuele Pedroni
(Jython's chief maintainer), Christian Tismer (Mr Stackless), Guido van
Rossum (Mr Python) -- and many others, including yours truly -- sitting in 
the same room hacking at the same project during a "sprint" this summer.
And happily guzzling beer and/or wine at the barbecue afterwards, of course.

There's just no "splinter" effect in all of this -- just different 
technology needs (e.g. a need to cooperate with some Java libraries 
seamlessly), requiring different implementations of the same language, 
Python.

> Some people want power and expressiveness.  Some people want control and
> uniformity.  Others still will sacrifice high level constucts for raw
> pedal to the metal speed, while others wouldn't dream of this sacrifice.

And people who have freely chosen Python appear to share enough core
values (simplicity, one obvious way to do it, etc) to be very far from any
splintering yet.  Why does that surprise you?

> What I'm getting at is that I can understand why people don't like
> Macros.  As David Mertz said, some people are just wired in dramatically
> different ways.

Well, it's nice that you understand this.  I just wish more people on your
side did -- most seem to think I'm crazy, my posts boggle the mind, etc.


> What get's me is when people (and I do this sometimes as well) expess an
> opinion as fact, and that all rational people will agree with them.  So,
> for what it' worth, for the times I have expressed my opinion as the one
> true way of thinking, I'm sorry.

I don't think there's anything worth apologizing for, in believing the 
opinion you hold is the true one.  Insulting people who hold a different
rational opinion is of course another issue.


> top secret pet project ;) ) every day.  I very much respect your
> knowledge Alex, because I do believe you have some good insights, and I
> do enjoy discussing issues that we disagree on (when we aren't being
> "bristly" ;) ) because you have many times helped me to understand my
> own point of view better.  So even though we don't always agree, I still
> appreciate your opinions.

Likewise -- for you and the other reasonable people on your side (right
now Pascal Costanza is the only one who comes to mind, but, as I said,
it's easy to start confusing people after a thread as long and confused
as this one).


I don't think macros are evil, either -- I just don't want them in 
Python:-).  Let me give an example: one thing my main client is working on
is a specialized language that represents information-models (actions in
them are in embedded Python), presentation-data to guide generic clients
for GUI / web / print presentation, etc.  I do think we need macros there 
sooner or later (and sooner would be better;-) -- simply to help remove 
redundancy and duplication, because in this purely declarative language 
there are no "functions".  (Were it not for language/metalanguage confusion 
risks, and the issues of ensuring the clarity of error-diagnostics, python 
functions emitting code in the specialized language [which gets compiled
into Python], i.e. "functions that run at compile-time", would be the 
obvious solution, and we could hack them in within an afternoon -- but we
DO want to provide very clear and precise error diagnostics, of course, 
and the language/metalanguage issue is currently open).  You will note
that this use of macros involves none of the issues I have expressed about
them (except for the difficulty of providing good error-diagnostics, but 
that's of course solvable).


Alex