"Douglas Alan" <nessus at mit.edu> wrote in message
news:lc7l0k1jwx.fsf at gaffa.mit.edu...
[snip]
> > Yes, 'hygienic macros' WOULD help cut these discussions short. Pity
> > this benefit (basically restricted to c.l.p) would be balanced by
> > the productivity loss engendered by the actual existence of such
> > macros in the language -- a language which may have ANY 'syntactic
> > feature' ensures any given program is impossible to understand
> > unless you first study the exact set of macros used by its
> > author:-).
>
> What happened to giving programmers enough rope to hang themselves?
That's C++'s specialty (it's actually "enough rope to shoot
themselves in the foot" -- unless you mix metaphors a LOT,
you ain't gonna grok C++ nohow).
> What happened to the desire for flexibility and expressive power?
At a MICRO level ("programming in the small") it's never been
part of Python's design goals to provide many ways to express
one design idea. "There should be ONE 'obviously correct' way
to do it" is one of the Python mantras -- clearly an ideal, one
that is totally unattainable of one dreams of something being
'obvious' to ALL the nutty individuals that write on Usenet
(you'll never get 100 out of 100 regular Usenet posters to
agree on ANY single issue -- I await expressions of total
disagreement about that, of course), and unattainable in its
totality even on a pragmatical plane where one is satisfied to
cater for sensible people. It's still a wonderful ideal in
the "to reach the moon, aim at the stars" spirit: by aiming
consistently at this unattainable goal, Python still manages to
get better stylistic uniformity across its disparate user base
than any other widespread language (in my limited experience:
I have NOT used ALL widespread languages enough to get a real
good feeling about stylistic variety among programmers).
The only real downside of this is that it DOES make for
interminable Usenet discussion with people who don't understand
the import of "If you want X, you know where to find it" (see
http://info.astrian.net/jargon/terms/i/If_you_want_X_you_know_where_to_find_
it.html
) for suitable values of X.
Programming languages, like political parties, come as
"packages". You won't like _everything_ you find there,
that is almost guaranteed: to get enough people together
to call it a "party", SOME aspect of the party's program
is likely to be very unpleasant for any given member.
Alternatives are: form your own party, whose program is
EXACTLY the set of your ideas about things (this seems
to be the currently preferred Italian solution, as we
have many dozens of parties with representatives in
Parliament -- of course, to hope to form a _government_,
they have to group into coalitions, meta-parties, so
on one side you find everybody from communists to a
guy who spent 20 years as the director of the IMF --
on the other side, everybody from post-fascist paladins
of a strong centralized state to would-be-secessionists
whose dream is to make of Lombardia a separate state...
so the "package" problem perks up again:-).
This strategy is apparently the one the original poster
to this thread is following -- he's bent on designing
his own language and is just asking for suggestions on
how to about designing it. Fine!
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.
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). 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...?-)
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...?
[The funny thing is that such epochal changes in a
party's fundamentals DO happen -- once per epoch.
Certain core values may apparently vanish (or we
would not see a pro-business, fiscally prudent
Labour government!) and others are born and take
roots (the Tories' current Euro-hostility, for
example). The mutation of Algol into Algol-68 is
an example of a similar epochal event in the field
of programming languages. Of course, it DID spell
the death of Algol as a practical-use language --
just like a non-type-safe, non-class-centered
Eiffel, a non-pure, non-lazy Haskell, or a Python
with declarations and hygienic macros, would have
no real reason to survive. 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.].
> 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".
> 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 -- isn't that what Steele tried
to do in Java? Python is clearly large enough to survive
(the steady, unflagging growth of interest in it over the
years attests to that) -- some of its fanatics think it's
TOO big (or threatens to become so) with the introduction
of list comprehensions or nested scopes. So, if you like
this maxim, considering Python "mid-size" makes sense.
> 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?
Some of us believe Common Lisp is too complex. Some of
us think that hygienic macros make _Scheme_ too big too.
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.
You have not explained, I think, why _YOU_ would want to
use Python rather than Common Lisp, Scheme, or Dylan. They
have hygienic macros AND variable declarations too. You
say that's what you want -- OK, there they are. What does
Python have that they lack, EXCEPT the simplicity (and
fluidity &c due to lack of declarations) that you would
rob from it if you had your way?!
> 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.
Python can live without macros as it has the expressive
power needed to express any design idea it could express
with macros, _net of syntax-sugar considerations_. See
the recent thread about '#define' for some examples.
You can't arbitrarily alter syntax-sugar to introduce
an 'unless condition:' synonym for 'if not condition:',
etc -- true. And *GOOD* in the Python Weltanschauung!!!
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).
Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4