[Guest]

Richard, this is well said (I too started with SPSS):

I always thought that SPSS looked like a collection of 50 different routines written by 50 different people who had 50 different ideas what the syntax should be. With Stata, I have a fighting chance of getting the syntax right for an estimation command even if I am not that familiar with it. With SPSS, no way can I do that. I need the menus or some sample code I can copy and paste. I hardly ever need the menus in Stata (except maybe for graphics) and the help files generally meet my needs.

I see why you want Mplus language translated to Stata's.

[Marcos Almeida]

Guest: Since you said:

I haven't tried Bayes in Version 15.

Definitely, you should give it a try!

I'm not fully acquainted with R, but I did some Bayesian analysis there. Recently, I compared with Stata's - bayes - command. Soo goood.

[Doug Hemken]

Well, I certainly read the post subject "How Stata Fails" as a summary judgement. The only reason to read further is because I recognize the poster's name.

With respect to SEM, I probably work with a couple dozen people each year who are having trouble with a model. Some are just realizing they need SEM - these I almost always steer toward Stata. It is the language most of them are coming from, and they already understand the data manipulation, documentation, and post-estimation. Occasionally someone needs a model/estimator that can't be fit in Stata (or not nearly as easily) and we move to MPlus.

I have yet to see a model converge quickly in MPlus where it didn't appear to converge in Stata, **except** where it appeared that the standard errors were marching to infinity, so I've learned not to wholly trust MPlus results. I'm sure this is a function of the kinds of models I get to look at. Is this a precision issue with MPlus?

I occasionally help people troubleshoot lavaan models (the classroom software of choice for a couple of professors here teaching SEM). These are almost always issues of understanding R, so I haven't really needed to dig into lavann itself yet. I have yet to see a model in lavaan that I couldn't set up anywhere else.

I originally learned about SEM using LISREL. Our LISREL users are pretty self-sufficient, so while I see them on our servers, I almost never see them in consulting.

[Richard Williams]

I might have chosen a different title and/or a slightly different tone, but overall Guest's post seems fine to me. It is basically a Stata wish list. I'm not quite as hard on sem as he is, but I do agree that Mplus has a big edge. Even R's freebie lavaan is faster, at least with the models I've tried.

Personally, my biggest wish is not for new features. Rather, I'd like to see old features work faster and more reliably. You'll see similar comments from people who want reshape to get zippier (which has never been a problem for me but it seems to be an issue for others). Some improvements may not be possible but, when you see the competition doing it, you wonder why Stata can't too.

Unfortunately just saying "old stuff works better" may not be the most effective way to spur sales. But maybe it will help to keep the people you already have from straying elsewhere. I spent a small fortune to buy Mplus and I wouldn't have done that if not for the fact that it is so much quicker with the models I am interested in.

[Guest]

Clarification: The full title in my original post was: "Examples of how Stata fails when trying to catch up". That was summarized to four words. Overall, I see Stata as a great program, which I also said in that post. It's in some of the new features we have problems. My tone came out of frustration, I admit that. But I also chose those words hoping to get noticed by programmers and editors within StataCorp, because this was not just a wish list. It was also a notification of errors in publications that may be addressed (when does a SEM model fit, and is it advisable to run Bayes with one chain?).

[wbuchanan]

Nigel Moore
the over option is specific to graphs where an aggregation function is applied over the values of a variable. The by and bysort prefixes (and options) are more analogous to a vectorized operation where the same task is performed simultaneously as defined by the values in a given vector. It makes sense for these two things to have different names when there is a difference, albeit a nuanced difference in the backend.

[wbuchanan]

Guest,

I’m not personally thrilled with the recent wave of fanaticism over R. There are absolutely going to be times where R is a much better tool for the task at hand, but some of the use cases you mentioned may be the result of the trendiness of R. For example, the first use case you mentioned was solved in R, Stata, and SAS over a decade ago http://homepage.divms.uiowa.edu/~rlenth/StatWeave/StatWeave-manual.pdf”]StatWeave[/URL]. In fact, the earliest implementations in RStudio even referenced this is an older package named sweave.

You also claim broadly that Stata fails at SEM. I’d argue that it isn’t failure as much as an optimization issue that you may not be considering. Stata is optimizing for precision and stability; Mplus, being more mature in this area, has already largely dealt with this and is able to focus optimization efforts on speed. So it isn’t that Stata fails, but that you are wanting a different dimension to be optimized. I agree that Mplus is higher performing, but completely disagree with some of the commentary about the language differences. This is actually a programming issue that has been solved for literally four decades now. There is a title, often referred to as “The Gang of Four” book, that describes programming patterns in object oriented software (published in 1977) in which the adapter pattern is described. This is a way of developing a single API for users while allowing the software to handle implementation specific APIs for the user (e.g., doing what Richard Williams package does with regards to generating the API calls to fit the same model in multiple languages).

Most importantly I’d say we need to consider the market. Stata seems to be focused more on the academic and economics/biostatistics markets. The R Core Group and R Foundation and focused much more heavily around industry and the business verticals. The products will never be completely comparable because they are responding to uniquely different markets and customer needs.

I say all of this not to purely defend StataCorp but to try nudging the discussion in a way that it could generate potential solutions with a more grounded understanding of the ecosystem. I - unfortunately- get stuck on calls with vendors regularly trying to pedal their wares and routinely reference functionality that exists in Stata as a benchmark. More than any other software, I’d argue that Stata is still years ahead of the competition with regards to metadata and how the metadata is integrated into other aspects of the software (e.g., generating legend keys, axis labels, axis titles, etc... automatically).