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

st: In search of the perfect Stata


From   "Dupont, William" <william.dupont@Vanderbilt.Edu>
To   <statalist@hsphsun2.harvard.edu>
Subject   st: In search of the perfect Stata
Date   Wed, 26 Feb 2003 13:35:55 -0600

Statalisters

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.

Bill Dupont

-----Original Message-----
From: Phil Schumm [mailto:pschumm@uchicago.edu] 
Sent: Wednesday, February 26, 2003 11:24 AM
To: statalist@hsphsun2.harvard.edu
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.
>
>Al Feiveson


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 
then?

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.


-- Phil
*
*   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/
*
*   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/



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