Named code blockes

[Alex Martelli]

"Douglas Alan" <nessus at mit.edu> wrote in message
news:lcn194egfd.fsf at gaffa.mit.edu...
> "Alex Martelli" <aleaxit at yahoo.com> writes:
>
> > 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.
>
> And a wonderful hypothesis it is.

I has aesthetic value.  Judging from about 50 years of
history of programming languages, I think its actual
value when put in practice may rank on a similar level
with other "wonderful hypotheses" the last few centuries
have developed and tried to enforce on people (such as
"perfectly-precise use of natural language" -- compare
and contrast youthful Wittgenstein's brilliant efforts
towards that goal, in the Tractatus, to the mature
Wittgenstein's explanations as to why it _isn't_ so
wonderful after all, in the Investigations).


> By doing so, you lower the barier to allowing people to accomplish
> what they want to accomplish.  Isn't that what a high-level language
> is all about?

Not *ALL*, fortunately.  One thing that some people DO
want to accomplish, for example, is getting a savoury hot
pizza delivered to their workplace while they're building
wonderful new programs, so they can gobble it down and
keep working.  Nevertheless, I would NOT think it a
worthwhile objective for a high-level language to fit
a pizza-ordering feature *in the language itself* --
do consider, among other downsides, that deciding whether
the default (when no topping is specified) should be
anchovies, pepperoni, or extra-cheese, is very likely
going to prove a highly divisive and moot issue.

I think there is general agreement that *SOME* of the
tasks that people DO want to accomplish when they are
programming are best left to OTHER tools (an online
pizza order menu might make a best-seller of some new
IDE, for example), rather than letting them affect
*the programming language itself*.  Keeping some tasks
*out* of a language's design goals (and pushing them
onto other tools -- including the standard library,
non-standard extension modules, IDE's, other language
processing tools, &c) allows the language itself to be
smaller and simpler than if it had to cater to every
such need itself.


> > 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.
>
> Embracing one does not mean rejecting the other, since any language
> designer with any sense realizes that even if the goal of being able
> to do everything in one language is a noble one, that it is not yet a
> practical goal to achieve today.  Allowing a language to cooperate
> well with other languages, while also nibling away at the goal of
> being able to do more and more within the language, is the
> pragmatist's way.

True, even _IF_ one did share the desire, embraced by most
(*NOT* all!) language designers, to have One Language To
Bind Them All, one pragmatic issue on the way to such
domination would still be that of fitting well into various
existing niches, which in turn does require ability to reuse
"legacy" code &c.  That accounts for variously-usable
"interoperability" features of many existing languages.

This in no way impacts my assertion, of course.  Python IS
as great as it is in part *because* it never strove to be
"the best language for EVERY purpose".  "General-purpose"
does not imply "best for every goal"...


> > 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.
>
> Well, you clearly don't prefer Python as much as me, since I'd prefer
> to use it for everything.

A language able to do everything well would not *BE* Python (although
of course it might be legally _called_ Python if the trademark owner
so decreed -- much in the "it will be called FORTRAN"'s joke spirit).


> P.S. Btw, I never "clamored" for any changes.  I merely mused on what
> would make Python a better language.  You, as much as anyone, should
> understand the difference.

Thanks for the implicit compliment, I guess, but I still classify
such phrases as your "I'd like to get rid of import statements
altogether", which prompted Remco Gerlich's excellent retort:
"""
Recently people want to get rid of import, change the clear semantics of the
assignment statement, add stricter interfaces, make more private members of
classes, do bytecode optimization...
    [snip]
Seems to me people think Python is really cool, if only it weren't Python,
but language <insert something like Java here>...
"""
and "Python should have procedural macros", and "it's a wart on the
language", and so on, as "clamor" for changes -- "insistent public
expression" -- without any of the "turn something over in the mind
meditatively and often inconclusively" which characterises musing.

I do appreciate your repeated attempts at softening the import
of previous statements of yours, but it seems to me that their
impact is limited without explicit retractions.


Alex