Nick
First, I'm not really arguing. Just stating preferences that I believe
would make the software easier to use. Second, I don't claim to know
"what is going on under the hood" or what improvements to Stata are easy
or hard to implement. The ideal solution would be to make the legend
option work regardless of whether -legend- is or is not nested.
Intuitively, I would have thought that providing error or warning
messages would be easier than changing the syntax -- perhaps I am
wrong.
With respect to disabling confusing or rarely used syntax I believe you
do misunderstand me. What I am suggesting is the disabling of syntax
that the parser ignores. I would think it unlikely that anyone would
wish to use an option that was ignored. Perhaps there are programming
examples where you would want to do this, in which case a warning
message would be preferable to a true error message. Either way, this
would not prevent people from using infrequently used commands.
Of course it is true that it is very difficult to know what the user
really wants. It is probably safe to assume, however, that she/he wants
something. Hence, any time the user enters syntax that is ignored it is
very likely that he/she has done something wrong. Also, the debugging
of any program is always more difficult if the parser is allowed to
ignore text that it does not understand.
In your first email in this thread you seemed to imply that the Stata
parser did not act as an advice or counseling facility. There is,
however, at least one example where it does play this role. If you
issue an -stset- command with the -id()- option, the parser will give a
-PROBABLE ERROR- message if it thinks that you have messed up. I have
often found this feature to be very helpful in correcting the errors of
my way.
I do agree that documentation is key and have found Mitchell's book to
be very helpful. The online documentation on the -legend- and -by-
options could be easier to find. In my case, I only discovered it after
doing a search of the Statalist archives, which led to David Harrison's
helpful email.
Bill
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Nick Cox
Sent: Monday, February 21, 2005 4:39 PM
To: [email protected]
Subject: st: RE: RE: RE: FW: RE: RE: Problem with legend option - bug?
We may be arguing at cross-purposes here. Let
me try to make myself clearer.
Naturally I agree that Stata's syntax is pretty complicated
here and that
understanding the syntax oneself (everyone's problem)
explaining that to others (many people's problem)
are important issues.
But my sense is that what Bill wants, even if judged a desirable
tweak to the software, is about an order or two more
difficult to program
in a consistent way
and without undesirable side-effects
than he seems to be guessing. This is because the
problem touches on what the user is thought
to want, which is not a question of syntax at all.
But desirability in principle is the first thing
to discuss.
I sense steps towards two alarming principles here --
if some users get mighty confused by some syntax,
then that syntax should be disabled.
if some syntax is rarely used,
then that syntax should be disabled.
There are two big empirical questions here, and who
is going to collect the data, but more crucially
that's pretty tough on the people who understand
that syntax or people who want to use the rarely
used syntax, either rarely or even frequently.
I must be misunderstanding, because I can't believe
that I am hearing these ideas.
What I can support is people writing wrapper graphics
programs that give simplified interfaces to -graph-,
in effect using a different syntax, and some of my
own programs come into that category. It's quite
difficult to do that without making desirable things
impossible. That is, the programmer provides a simplified
way to get certain kinds of graph, but has to try to
keep open the scope for users to modify something else
not directly controlled by their program.
Similarly, some one could write a -byplot- (or whatever)
with wired-in defaults for what is (supposedly) rarely
used and tweakable options for what is often wanted
to tweak. That would be a far easier solution than StataCorp being
advised to cut functionality because of these
principles. (More important than my incredulity here is
that I can't see StataCorp buying these principles.)
There is no need for brilliant ideas here: you just
hard-wire option choices you find yourself making
repeatedly.
To put it another way, I assert that if there is a solution to
this confusion it comes mostly at the level of
add-ons, or indeed at the documentation level. Michael
Mitchell's book is a striking illustration of a how
a different format explains many things that some readers
fail to find, or fail to understand, in [G].
Nick
[email protected]
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
