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

st: Re: list in stata8


From   Phil Schumm <pschumm@uchicago.edu>
To   statalist@hsphsun2.harvard.edu
Subject   st: Re: list in stata8
Date   Wed, 26 Feb 2003 11:24:21 -0600

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/




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