Python syntax in Lisp and Scheme

[Alex Martelli]

Erann Gat wrote:
   ...
> mindset, that anything that is potentially dangerous ought to be avoided
> because it is potentially dangerous, is IMHO a perverse impediment to
> progress.  There is no reward without risk.

I'm quite happy for you, and all other unreasonable men "without which
there can be no progress", to run all the risks you want, and I'll be happy
to applaud you for your successes -- as long as I don't bear any part of
the costs of your failures.

As for me personally, and for my typical customers, we have lower
appetite for risk: risk is something to be assessed and managed, not
run for its own sake.  A risky strategy is one that has higher expected
returns but also higher volatility: and often there's a threshold effect,
where beating the threshold by a lot isn't much more valuable than
beating it by a little, but falling short of the threshold would be a 
disaster.  Think of delivery dates, for example: delivering a month in
advance is cool, but not really all that important; delivering a month
late may mean the firm has gone bust in the meantime for lack of
the application it was counting on.  I prefer software development
strategies that let me be reasonably sure I can deliver within the
deadline, rather than ones that may, with luck, allow spectacularly
earlier delivery... but risk missing the crucial deadline.  I'm a lucky
man, but part of the secret of luck is not pushing it;-).

You seem to be saying that the technologies you prefer are suited
only for cases in which, e.g., running substantial risks of missing the
deadline IS to be considered acceptable.  Presumably, that must be
because no safer technology stands a good chance of delivering
reliably -- i.e., cases in which you're pushing the envelope, and the
state of the art.  Been there, done that, decided that research does
not float my boat as well as working in the trenches, in software
production environments.  I like delivering good working programs
that people will actually use, thus making their life a little bit better.

In other words, I'm an engineer, not a scientist.  Scientists whose
goals are not the programs they write -- all those for whom the
programs are mere tools, not goals in themselves -- tend to feel
likewise about programming and other technologies that support
their main work but are secondary to it, though they may have
ambitions as burning as you wish in other, quite different areas.

So, maybe, your favourite technologies are best for research in
computer science itself, or to develop "artificial intelligence" programs
(has the term gone out of fashion these days?) and other programs
pushing the envelope of computer science and technology -- and
mine are best for the purpose of delivering normal, useful, working
applications safely and reliably.  If this is true, there is surely space
for both in this world.

> things.  If you have no ambitions beyond writing
> yet-another-standard-web-app then macros are not for you.  But if your

Not necessarily web, of course; and generally not standard, but rather
customized for specific customers or groups thereof.  But yes, I basically
feel there's a huge unfilled demand for perfectly normal applications,
best filled by technologies such as Python, which, I find, maximize the
productivity of professional programmers in developing such apps and
frameworks for such apps, AND empower non-professional programmers
to perform some of their own programming, customizing, and the like.
My only, very modest ambition is to make some people's lives a little
better than they would be without my work -- I think it's a realistic goal,
and that, a little bit at a time, I am in fact achieving some part of it.

So, general macros in a general-purpose language are not for me, nor for all 
those who feel like me -- not for _production_ use, at least, though I do
see how they're fun to play with.


> example, there is no reason it should take multiple work years to write an
> operating system.  There is no fundamental reason why one could not build
> a computational infrastructure that would allow a single person to write
> an operating system from scratch in a matter of days, maybe even hours or
> minutes.  But such a system is going to have to have a fairly deep

So why don't you do it?  As I recall, the "lisp machines"' operating 
systems, written in lisp, were nothing lilke that -- were the lisp 
programmers working for lisp machine companies so clueless as not to
see the possibilities that, to you, are so obvious?  And yet I had the 
impression those companies hired the very best they could find, the stardom 
of lispdom.  Well then, there's your chance, or that of any other lisper 
who agrees with you -- why don't you guys go for it and *show* us, instead 
of making claims which some of us might perhaps think are empty boasts...?


Alex