Phil, Buzz, Nick and others:
OK - OK - I respectfully admit I am in a small minority (of one?). I just
have one last question, then I'll be quiet about this topic:
What percent of Stata Corp.'s resources were spent on the development of
GUI, graphics, windowing, etc. for STata 8, as compared with the develpment
of improved statistical modelling, estimation, etc. routines? Same question
regarding SMCL in Stata 7.
Al Feiveson
-----Original Message-----
From: Phil Schumm [mailto:[email protected]]
Sent: Wednesday, February 26, 2003 11:24 AM
To: [email protected]
Subject: one last question
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/
