Python syntax in Lisp and Scheme

[Alex Martelli]

Kenny Tilton wrote:
   ...
> As for non-professional programmers, the next question is whether a good
> language for them will ever be anything more than a language for them.

Being a professional programmer, I find Python makes me very productive
at my job -- and yet I know from experience it's also an excellent language
for non-professional programmers.  So, the experiential answer is clear to 
me.

> Perhaps Python should just stay with the subset of capabalities that
> made it a huge success--it might not be able to scale to new
> sophistication without destroying the base simplicity.

Interestingly enough, you and I probably agree on that.  I don't _want_
Python to grow in any way that would "destroy the base simplicity"; indeed,
I'm looking forward to 3.0 (even though it's probably 3 years off or so)
exactly because it may get simplified again then, shedding some accumulated
legacy baggage (there is no reason, except backwards compatibility, to
have e.g "classic classes", range, xrange, etc etc).  Any proposed new 
feature, in my opinion, must be judged strictly on the criterion of: how 
much better than today's set of features would it let us do our jobs?  If 
it provides another roughly equivalent way to perform some of the same
tasks, that's a substantial minus (as it encourages divergence of language
dialects) and must be compensated by really big advantages elsewhere.

Today's Python has the features we need to productively build ambitious 
frameworks for asynchronous network clients and servers (Twisted), spam 
filters that apparently work better than Graham's (spambayes), search 
engines (Verity Ultraseek, nee Infoseek, as wel as Google), ship-design 
optimization apps (Tribon Vitesse), commercial games (Freedom Force, EVE 
Online, Star Trek Bridge Commander...), collaborative enterprise app 
frameworks (CAPS), scientific visualization tools such as MayaVi, business 
logic for factory and tool control (IBM/Philips Fishkill plant)... oh, 
you're perfectly capable of reading the various "Python success stories"
sites and booklets yourself, I don't want to bore you TOO much:-).  The
point is, it MIGHT, as you point out, be unfeasible to "scale to new
sophistication" -- beyond the few 100,000s function points MAXIMUM of
any of these Python successes (roughly equivalent to, say, a few 10's
of millions of lines of C code), to e.g. many millions of function points.

I think the world needs LOTS AND LOTS of application programs in
the 1000-100,000 function points range -- and Python's current set of
features has proven amply sufficient to provide those without damage
to "the base simplicity" which you mention.  If many applications of
many millions FP's (roughly equivalent to a billion lines of C, or so)
are needed, I don't know -- but, if so, I share your doubts about it making
any sense to destroy Python's simplicity in an attempt to tackle THOSE
monsters, "scaling to new sophistication".


> You (Alex?) also worry about groups of programmers and whether what is
> good for the gurus will be good for the lesser lights. What you are
> saying is that the guru will dazzle the dorks with incomprehensible
> gobbledygook. That does happen, but those kinds of gurus should be fired.

That's only part of the problem, of course -- programmers who are not
quite as good as they think they are and inflict their "enhancements" to
the language to everybody else are another issue.  Maybe they should
be fired, but such turnover in the team would decrease productivity
anyway.

> On a suffciently large project (well, there's another point: with Lisp
> one does not hire ten people (unless one is doing three projects)) the

Lisp isn't able to let 10 people work together productively on the
same project?  Oh my -- now THAT would be a huge problem;-).

> team should be divided into those who will be building the
> domain-specific embedded language and those who will be using it.
> Ideally the latter could be not just non-professional programmers, but
> even non-programmers.

If they're programming (in whatever language) they can't be
non-programmers, by definition.  But anyway, this misses the key
issue: who are the *real* experts of the application domain that
your "domain-specific" language is supposed to address so well?
E.g., the *real* experts on turbo-compressor design, on optimization
of ship designs, on the business logic of tool control, on logical
and physical design of integrated circuits, etc, etc?  Answer: they
are likely to be non-professional programmers.  Are THEY designing
the domain-specific language -- or is it going to be designed by
computer scientists who don't really grasp the intricacies of turbo
compressors, ships, etc, etc?

The Agile Programming (Extreme Programming, in particular) answer 
to this enormously important issue is that the whole team, customer
included, *works together* and *collectively owns* the whole body of code.

The computer scientist learns enough about turbo compressors, and
the turbo compressor expert enough about programming, by the
incredibly productive social process of *pair-programming* -- sitting
side by side and working together at testing and building code (in
this order -- but I won't bore you with test-driven-design paeans...;-).

This holistic approach is incompatible with your favourite "the gurus
build the domain-specific language, the peons just use it" approach.
It works particularly well when the language is as simple, as good at
"getting out of your way", as Python (or, admittedly, Ruby -- I have
enormous respect for Ruby! -- though I have some issues on quite
another plane that make me keep preferring Python for this specific,
and very important to me, kind of tasks).

It surely can feel "cooler" for the Guru (uppercase G mandatory) not
to have to mingle with such low-lifes as the lusers (a Guru's favourite
spelling of "users", apparently) -- to just sit in their ivory tower 
spitting out domain-specific embedded languages for domains they
_aren't_ as expert at as the peons.  But I've seen that approach at
work (for hardware design with various lisp variants and dialects) and
don't like the results I have observed, particularly in application domains
where the intended users ARE quite expert in their field (which is the 
case for many interesting apps -- not just those targeting the people
which our society acknowledges as "respected professionals", mind you:
a good secretary knows FAR more than I ever will on how to make an
office run, a shopkeeper on how things work in a shop, etc, etc).


Alex