Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: RE: RE: RE: FW: RE: RE: Problem with legend option - bug?

From   "Dupont, William" <>
To   <>
Subject   st: RE: RE: RE: RE: FW: RE: RE: Problem with legend option - bug?
Date   Mon, 21 Feb 2005 18:06:43 -0600


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

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.


-----Original Message-----
[] On Behalf Of Nick Cox
Sent: Monday, February 21, 2005 4:39 PM
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 

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]. 


*   For searches and help try:

© Copyright 1996–2021 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index