> So here's the distinction between the serious and casual programmer -
> maybe for example professional-programmer versus scientist-programmer.
> Earlier I mentioned ordinary people, and I'm afraid that professional
> programmers are often fairly ordinary people. QED, ordinary people
> need to fully comprehend python's features.
>
> In the end the benefits of these new features may far outweigh their cost.
> I just wanted to point out what I see as a fallacy in the notion that you
> can totally avoid these costs by "hiding the implementation from end users".
I don't agree. In my picture of things, python *should* include some
fundamental but sophisticated constructs. There should not be too many,
and they should be expressed as fundamentally as possible. ("Simple
enough, and no simpler", to paraphrase a popular design principle.) If you
leave out ones that are necessary, then you wind up having complicated,
hard-to-write and hard-to-read *programs*, when people try to do without
the missing pieces. (Conversely, if you use constructs that are not
fundamental enough, you wind up implementing pieces of a mechanism in
different constructs - clutter.)
If you want the language itself to only contain simple constructs, you can
do what tcl does and push all the sophistication to extension libraries.
This can make it easier for inexpert people to write very simple programs.
However, i think this makes it less easy to write anything but simple
programs, increasingly less easy as the purpose of the program becomes
more sophisticated.
I think python's big win is due to very straightforward, simple constructs
which cogently implement both simplistic *and* sophisticated mechanisms.
For what it's worth, i happen to really like what jim fulton orginally
proposed, for extending the 'exec' statement so that the programmer can
designate an 'executor' for a statement suite. The scheme seems to me to
be an appropriate extension of 'exec', and a suitable adaptation of the
'construct: suite' syntax. Though i am *not* well acquainted with
transaction processing or threads or whatever, it sounds from the
discussion like the proposed semantics are quite general, and would serve
well for them, whether the syntax includes the keyword 'exec' or some
other one.
I realize that i am sufficiently uninformed that i'm not a good arbiter in
this case. I do hear jim's plea for a suitable mechanism, however, and
think further attention to the issue is warranted...
Ken
ken.manheimer@nist.gov, 301 975-3539