st: Re: list in stata8

[Phil Schumm <pschumm@uchicago.edu>]

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/