If you want X, you know where to find it (was Re: do...until wisdom needed...)

[Douglas Alan]

"Alex Martelli" <aleaxit at yahoo.com> writes:

> "There should be ONE 'obviously correct' way to do it" is one of the
> Python mantras

This is a BAD mantra.  Not as bad as the Perl mantra, "There should be
3294369 ways to do it", but extremes are rarely ideal.  "The truth lies
somewhere in the middle."

Besides, there are many uses for procedural macros other than for
providing trivial syntactic sugars that are best done by using the
sugar already provided.  It's not a good idea to throw the baby out
with the bathwater just because something can be misused.

> Or else, join an existing party and try to influence it so its
> political program becomes closer to your wishes.  Which is also
> fine.  But you have to learn enough about political parties to see
> what aspects of their program ARE ones you can influence --
> "superficial" ones, so to speak, the kind that ARE going to be
> changeable -- and which ones are the VERY NATURE of the party.  If
> the things you find unacceptable are deep-rooted ones in the party's
> membership and history, then, in general, striving to change them is
> similar to trying to teach a pig to whistle -- it wastes your time,
> and annoys the pig.  And it's unlikely to produce the kind of melody
> that will make the resulting MP3 a real hit.

I've been programming in Python plenty long enough to understand its
essence.  Just because many people misstate its essence (by
overgeneralizing or undergeneralizing), doesn't make them right.

> It appears to me that the changes you want to see in Python are very
> much of the pig-whistling kind: you want variables to be declared
> (in another thread), you want infinitely variable syntax sugar via
> macros (at least, I hope, of the hygienic kind).

Of course, of the hygenic kind.  I'm not a barbarian.  But hygenic
*and* procedural.  Not the annoying kind that they added to Scheme.

> Hmmm, you sure you wouldn't want some sort of explicit bracketing in
> lieu of indentation for grouping, or inheritance to be restricted to
> single rather than multiple, or...?-)

No, of course I wouldn't.

> Are you perchance at the same time an activist in the Republican
> Party striving to make the party support higher taxes, stricter
> Federal control on States, and more welfare including free
> health-care for all...?

I'd never have anything whatsoever to do with the Republican party.

> just like a non-type-safe, non-class-centered Eiffel

Eiffel isn't (compile-time) safe as it is.

> a non-pure, non-lazy Haskell,

Purely applicative languages are rarely applicative, so Haskell seals
its own fate.  But that doesn't mean that something good, and somewhat
less pure won't rise from its ashes.

> or a Python with declarations and hygienic macros, would have no
> real reason to survive.

That's nonsense.  It would be an even better langauge, with more
safety and more power, and more likely to be able to continue to
evolve to meet the needs of an ever-changing tomorrow.

> Such disintegrations due to "loss of core values" don't ALWAYS
> happen -- the old _name_ may happen to survive even as the deep
> nature of the language is totally changed, cfr. Fortran -- but they
> happen regularly enough to explain why somebody who particularly
> cares for a language's (or a party's) current core-values will react
> to the proposal of so-called "improvements" which are in fact rather
> obvious attacks against its core.].

See Guy Steele, "Growing a Language":

   http://cm.bell-labs.com/cm/cs/who/wadler/gj/Documents/steele-oopsla98.pdf

"We need to put tools for language growth in the hands of the users"

> > Sure, macros are a long rope, but some tasks require a long rope.

> IF there are tasks that require a year-light worth of rope (a
> separate debate), it's still extremely silly to want to attach that
> thread to unsuitable frames.

> There are so MANY languages whose core values do *NOT* include
> simplicity and stylistic uniformity, that it's truly perverse to
> strive to destroy such uniformity and simplicity in one of its few
> "safe harbors".

Simplicity is maintained with a simple understandable model, and a
clean, elegant core, not by resistance to new features that would be
very useful.  Stylistic uniformity sounds like some sort of communist
manifesto to me, and I want nothing to do with it.  I prefer a
language that helps me implement my vision with style and panache.
Python does that just fine, thank you, and with a few improvements it
would do so even better.

> > Take a look at Guy Steele's maxim that a large language is impossible
> > to design well, but a small language is doomed to die.  A language

> The obvious consequence if one believed that would be to design a
> mid-size language 

No, his point is that *any* language, if it is to survive and be
widely used, will someday become a large language.  Since a large
language cannot be designed up front, if you want the large language
that your small language will become to remain an elegant language, it
behooves you to plan well for the inevitable and unrelenting growth of
your language from a small one to a large one.

> -- isn't that what Steele tried to do in Java?

Guy Steele didn't design Java.  His comments are aimed, I think, in
part, in implying in that Java must change if it is to survive.  It
needs, for instance, parameterized types, operator overloading,
and lightweight objects.

> > needs to be able to grow over time.  Procedural macros in Lisp allowed
> > Lisp to continue to evolve over time, so that even though it was
> > invented in the '50's, it remains today one of the most modern of
> > languages.  It was able to do this, in part, by allowing every user to
> > experiment with adding language features, not just the language
> > Illuminati.

> So use Lisp!  Who's holding you back?  It IS an excellent language
> and has splendid implementations.  Why do you want to make Python
> into Lisp?

And should I also move to New Zealand because I don't like the fact
that Amtrak sells information to the DEA?  I don't respect the Not
Invented Here syndrome -- I see it time and time again in the
intransigence of people to take good ideas from other sources because
they didn't think of it themselves.  Good ideas are good ideas, and it
behoves us to accept them where we find them.

There are plenty of reasons why I don't use Lisp for scripting, and if
you have used both of them, you would know *many* possible answers to
this question.

> Some of us believe Common Lisp is too complex.

Indeed it is.  "The truth lies somewhere in the middle."

> Some of us think that hygienic macros make _Scheme_ too big too.

You would be wrong about that.  But Scheme-style hygenic macros are
cumbersome and unpleasant to use for real-world problems.  What one
really wants is procedural macros like Common Lisp, but that are also
hygenic.

> Even _Dylan_, for all of its beauty, and the true awesome power of
> multi-methods, is not what I use, in good part *BECAUSE* of the
> complication macros engender in my view.

I don't use Dylan because no one else uses it.

> You have not explained, I think, why _YOU_ would want to use Python
> rather than Common Lisp, Scheme, or Dylan.

There are numerous reasons.  The fact that the others are not widely
used, are not tuned for scripting, do not have as elegant a syntax,
are not as easy to learn, are not available on every platform known to
man, do not start up in a fraction of a second, do not come with a
huge library of useful tools, etc., are all salient reasons.  And yet
there remain others.

> They have hygienic macros AND variable declarations too.  You say
> that's what you want -- OK, there they are.

Great.  They also lack things that Python has.  If I switched to them,
and wanted to bring the things I like about Python to them, no doubt
their Illuminati would tell me that I should go back to using Python.
Well, here I am.

> > And macros don't ensure that *any* given program is impossible to
> > understand -- it only helps nutty programmers make programs that are
> > impossible to understand.  Conversely, macros can help wise
> > programmers in making programs that are shorter, easier to understand,
> > easier to code, and easier to maintain.

> Sure -- a perfect programmer (a very hypothetical beast) will use
> ANY given tool perfectly (by definition).  All you say here applies
> just identically to the NON-hygienic macros of C, for example.  They
> CAN in fact be used to good effect (cfr. the Python C API for some
> good, typical examples), and C would not be half as successful as it
> is if it didn't have its preprocessor or some other equivalent tool.
> _IN PRACTICE_, out in the field, you'll find C macro abuse rampant
> -- one of the most serious causes of maintenance nightmares.

C macros are a monstrosity, so it's no wonder that in the practice
there is rampant macro abuse.  _IN PRACTICE_ there is not rampant
macro abuse in the Lisp world.  Macros are typically used to good
effect and typically make programs easier to understand, rather than
harder.  Often they are essential to making certain programs
maintainable.  In another language, you would have to resort to
prepossessing or data driven code-generation instead.

> As you seem totally unwilling or unable to understand that
> Weltanschauung to any extent, I don't see how you could bring Python
> any constructive enhancement (except perhaps by some random
> mechanism akin to monkeys banging away on typewriters until 'Hamlet'
> comes out, I guess).

$#@# you too.  You are very rude.

|>oug