[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
st: In search of the perfect Stata
Most Statalisters are professional statisticians who use Stata primarily
for their own analyses. It is important to bear in mind that there are
other users and other legitimate reasons for using Stata. I use Stata
both for my own analyses but also to teach biostatistics to
non-biostatisticians. For this task, the point and click interface will
be invaluable. There is also a very large community of people who need
to run statistical analyses occasionally. These people will never
become fluent with the syntax of any statistical language; for them the
GUI interface is also invaluable.
I believe that with version 8, Stata has made a wise compromise between
the needs of their hard core user group and the needs of students,
teachers and other users.
From: Phil Schumm [mailto:email@example.com]
Sent: Wednesday, February 26, 2003 11:24 AM
Subject: st: Re: list in stata8
At 8:12 AM -0600 2/26/03, FEIVESON, ALAN H. (AL) (JSC-SD) (NASA) wrote:
>As I suggested previously - I am saddened to see that Stata is being
>driven more and more towards accommodating cosmetics rather than
>statistics. I assume this is a market-driven neccessity and done with
>reluctance by Stata Corp.
Personally, I see no evidence of a change in Stata's direction.
IMHO, three of the features that have always made Stata great (and
there are of course many more) are still front-and-center in version
8. They are:
1) A resistance of the temptation to add every conceivable option,
and then to drag these along perpetually across releases. This is
what creates bloated, inefficient, and difficult to use software.
2) A small footprint, and extreme speed. The increased speed of
execution of ado-files in Stata 8 is nothing short of awesome, and
most importantly, makes it possible to implement things with
user-written code that were previously not feasible. I see no
evidence that the menu additions (which I essentially ignore, but
which almost certainly are of help to *a lot* of others) have slowed
down the program.
3) Open-source-like access to much of the underlying code, and the
ability to make changes. This is one of the most impressive features
of the new graphics, made possible only because they are implemented
via ado-files. There is a trade-off with speed here, to be sure --
but it is in the name of flexibility and extensibility, *not* glitz.
Imagine if all of Stata had always been fully compiled (i.e., no ado
files), and then someone suggested that StataCorp introduce
ado-files. There would be the same speed trade-off, but in return we
would get the ability (as users) that we have always had of writing
our own estimation and data-management commands. Would we complain
My sense is that StataCorp has never been "driven" to "accommodate"
anything but what it believes are features necessary and helpful for
effective and efficient data manipulation, analysis, and
presentation. It's design and implementation of smcl is an excellent
example of this. One way to describe smcl is as a markup language --
spartan but highly functional (much like the original motivation for
html). It gets the job done but no more, and as a side benefit,
translates nicely into postscript/pdf. SMCL is what makes the output
of the new -list- easy to read, and I see no glitz (e.g., multiple
fonts, colors, etc.) here whatsoever.
I see no problem with targeted comments and/or criticisms, especially
those designed either (1) to evoke an explanation from StatCorp as to
why something was done a certain way, or (2) to request (politely)
that something be changed in the future. But a general claim about
the direction of Stata requires quite a bit more justification than I
have seen thus far, and StataCorp should be allowed to respond to
such a claim before it is touted as fact.
* For searches and help try:
* For searches and help try: