This raises issues at various levels. I just want to make a few points,
which are very far from being a complete analysis.
1. User-programmers in most cases presumably write first for themselves,
and then possibly for their collaborators and/or students. I guess that
I am far from the only user-programmer who almost never uses the dialog
system, so I have no wish to write dialogs for myself. (The exceptions
are when I find myself showing dialogs to someone else.) I am not even
clear that students learning Stata are best introduced to dialogs, for a
variety of reasons that I could expand on, but I have no desire to
inflict that prejudice on those who don't already share it. But beyond
that the prevailing attitude as with free software everywhere is "If
this is what you want, that is fine; if it's not, you will probably need
to write some code yourself or look elsewhere."
2. I guess habits are memetic here in so far as it has long been
acceptable among user-programmers _not_ to publish dialogs too and that
to some extent is self-reinforcing. It is an implicit policy of the
Stata Journal that dialogs are optional even for code published via the
SJ. The converse is that it is not acceptable to publish ados without
proper help files. Otherwise put, code without help is incomplete, but
code without dialogs is just code without dialogs.
3. Complexity is a practical issue. I've encountered Stata programmers
of long experience who regard the expectation that help files are
written in SMCL as a reason to retire from the fray, so it's hardly
surprising that dialogs are a complication too far for many. In essence
you can't have dialogs without a programming structure to match.
4. As far as I am concerned anyone is welcome to write dialogs for
programs I have published, subject to good practice in giving credit and
claiming responsibility. I imagine that attitude is widely shared, but
it would be a good idea to check with an author first.
Nick
[email protected]
Martin Weiss
an issue that I failed to bring up at the recent "wishes and grumbles"
at the SNASUG meeting is the complexity of dialog programming. It
seems to me that few authors of user-written software make the effort
to write them. Exceptions are, for instance, -ssc d eclplot- and -ssc
d psmatch2-. Usage of a command, particularly for new users, is
facilitated by dialogs. In fact, Stata is proud of the availability of
dialog boxes and a simultaneous command line and programming
capability. Now, experienced users can master official Stata, apart
from complicated graphs, from the command line. But the user-written
software, which often covers functionality that you need only rarely
(but then badly), comes largely without the benefit of a dialog box to
guide users.
To provide a good example of the issue at hand, -ssc d tabout- is a
wonderful command that I tend to use about once a week. This frequency
is just about enough to maintain awareness of the command, but not
enough to remember all the pitfalls, particularly the incompatibility
between options. If I had a dialog box that took care of the interplay
between options, that would make my life a lot easier. Is there any
good place for authors to start their dialog programming effort (apart
from http://www.stata.com/support/faqs/lang/db-intro/db1.html)? If
not, why not? If so, why are they not rushing to use it?
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
