Named code blockes

[Alex Martelli]

"Douglas Alan" <nessus at mit.edu> wrote in message
news:lcu23dvqrq.fsf at gaffa.mit.edu...
> "Alex Martelli" <aleaxit at yahoo.com> writes:
>
> > One genius clamored for a huge new mechanism that would at last, in
> > the Plenitude of Glory, let him write "let x = y" versus "set x = y"
> > so he'd get ``declarations'' -- and then, when somebody showed him
> > how easily he could set things up so as to write "let.x = y" and
> > "set.x = y", he claimed his coworkers would kill him if he
> > programmed that way.  Well isn't that obvious, that being able to
> > have a SPACE there instead of a PERIOD is the be-all, end-all of
> > programming?!  Isn't it _absolutely_ obvious that placing a period
> > there will lead to justified homicide...?
>
> Thank you, Mr. Martelli, for the deference that you show to others
> whose opinions differ.  You are a model for us all.

You're welcome!  And I very much look forward to the PEP and patches
where you'll show us all the true beauty of the new mechanism you
have envisaged in all of its glory -- please be sure to include the
examples that you were using to motivate it, such as this let/set
masterpiece, and, of course, "do/until" (which was, as surely you
will recall, the subject heading of one of the threads in which you
were regaling us with your masterful advocacy) as its true crown.


> I'd like to point out, however, that you have reduced my position to
> an absurdity.  There are a number of other reasons to avoid the
> proposed solution than only the difference between a "." and a space.

Indeed, I agree on the latter -- the key reason being that having
no declarations is one of Python's strengths, and issues such as
typo-checking best addressed by other tools separate from the
compiler (such as PyChecker, for example), without adding any
complexity to the Python language itself.  But then, _I_ wasn't
the one clamoring for additions to Python in order to fix alleged
problems with it, and ignoring such possibilities as operating at
the tools-level and keeping the language simpler.  So, I have to
bashfully decline your kind attribution to me of the absurdity
that does inhere in this position -- I cannot take credit for this
delightful nonsense, any more than I can for "Alice in Wonderland"
and other masterpieces of this genre; a mere journeyman in the
pearly vaults of the Absurd, I always defer to acknowledged True
Masters of the field.


> panelists indicated that hygienic macros are an *essential* feature
> for future languages in order to allow for them to grow and to
> adequately support solving domain-specific problems.  Domain-specific
> languages are essential, they said, for reducing complexity in many
> difficult problems, and hygienic macros are one of the best ways of

Two interestingly embricated claims.  I do see the interest in
separate, Python-like languages such as PyHTML -- domain
specific and all.  But there seems to be an underlying hypothesis
here that it's best to do EVERYTHING in ONE language, including
implementing other ones on top of it.  One of Python's specific
design choices was to reject that: it was deliberately designed
to cooperate well with other tools (and languages in particular)
instead.  Rather than stretching one language to the point where
it covers EVERY important design goals (including this idea of
domain-specificness, but also classic ones such as very high
ability to be optimized), as most other major languages seem
to have set out to do from different starting points, Python
chose instead to stay *SIMPLE*, pragmatic, and highly able
to interoperate with other tools to provide missing pieces of
the software development puzzle.

Why would a "future language" have to be all things to all
people (like was the design goal of, say, 90% of existing
ones), rather than flourish in the 'niche' of doing many things
well and leaving it to other tools to cover the rest?  PyHTML
is one example of how that might work -- and no doubt, if
that is the direction, Python specs may change _a little_ to
make life simpler for the *other tools* (NOT Python itself)
that it cooperates with.

It seems to me no convincing case has ever been made
that a single language MUST do everything well.  Many
widespread languages aim at that -- Common Lisp, Dylan,
C++, Eiffel, Java, just to name a few.  Python doesn't.

I prefer Python.


Alex