[Jiong Yao]

i hope that in the do file editing interface, we are able to connect two do files together (split view model), thus we can check two do files simultaneously

[John Mullahy]

With each new version release—assuming that's what Stata's Twitter hint this morning means—it would be great to see Stata respond to the StataList v17 Wishlist (now at 511 postings, excluding this one) like a revise-and-resubmit: Please indicate how you've responded to each reviewer's comments or why you've elected not to do so.

I realize this won't happen. But many among us who have contributed to the Wishlist and/or have read its postings would likely be curious as to the reasons particular suggestions—offered presumably in the spirit of improving the software—were not implemented. Lack of general interest? Technology constraints? Low priority? etc.

(Twitter link, FYI: https://twitter.com/Stata/status/138...378354703?s=20)

[Leonardo Guizzetti]

i hope that in the do file editing interface, we are able to connect two do files together (split view model), thus we can check two do files simultaneously

I raised a similar question in #432 and wbuchanan 's reply in #433.

[Dirk Enzmann]

John Mullahy (post #512): I can understand the motivation, but I doubt that following the request will be an improvement. There can be many different reasons for Stata (Corp.) not to implement everything or to revise upon users' request (imagine that Stata Corp. is working on a major improvement but does not want to let competitors in the market see what it is working on before the final release). To explain or justify the decision for not responding to each and every wish on the list could easily lead to endless discussion as views may differ.

Most importantly, some (or perhaps many requests) can be solved by creatively using Stata's already existing facilities or have already been solved by users' contributions (.ado-programs). To my mind Stata's big advantage is that using user written .ado's can extend Stata in ways not imagined by those producing official Stata. The history of Stata shows that user contributions (either requests or written code) have been seized by Stata in the past and I trust that this will continue. The wish list should stay a list of wishes, not a list of requests that need justifications if not met. In this respect it is illuminating to read the interview of Bill Gould by Joseph Newton (chapters 2.5 and 2.7 in "Thirty Years with Stata").

I don't think that I am naïve if I trust the expertise of Stata Corp. to make good decisions that will improve Stata to the best of the users and Stata as a company (that needs to survive in order to serve us and that needs to serve us in order to survive) -- Stata can't be compared to a government we choose and that can be held accountable for its decisions. If contributions to the wishlist would only be requests to Stata Corp. it would lose some of its functions of a discussion board of users from which we also can learn how to solve issues in ways we didn't thought of.

[Allan Massie]

compress, dropmi
drops any variables that are missing for all records
compress, dropsame
drops any variables that are the same for all records
True, each of these would be simple to implement in a few lines of code. But it would be nice to have as part of compress. Also, since compress is a built-in function, implementation might be faster for large datasets

[JanDitzen]

With each new version release—assuming that's what Stata's Twitter hint this morning means—it would be great to see Stata respond to the StataList v17 Wishlist (now at 511 postings, excluding this one) like a revise-and-resubmit: Please indicate how you've responded to each reviewer's comments or why you've elected not to do so.

I realize this won't happen. But many among us who have contributed to the Wishlist and/or have read its postings would likely be curious as to the reasons particular suggestions—offered presumably in the spirit of improving the software—were not implemented. Lack of general interest? Technology constraints? Low priority? etc.

I agree! It would be great to know what Stata actually makes out of the posts in this forum and the wishes and grumble sessions at Stata User Group Meetings. I know that some comments made it into the next release, but it would be interesting to know why others did not or if they are coming in the future.

John Mullahy (post #512): I can understand the motivation, but I doubt that following the request will be an improvement. There can be many different reasons for Stata (Corp.) not to implement everything or to revise upon users' request (imagine that Stata Corp. is working on a major improvement but does not want to let competitors in the market see what it is working on before the final release). To explain or justify the decision for not responding to each and every wish on the list could easily lead to endless discussion as views may differ.

Most importantly, some (or perhaps many requests) can be solved by creatively using Stata's already existing facilities or have already been solved by users' contributions (.ado-programs). To my mind Stata's big advantage is that using user written .ado's can extend Stata in ways not imagined by those producing official Stata. The history of Stata shows that user contributions (either requests or written code) have been seized by Stata in the past and I trust that this will continue. The wish list should stay a list of wishes, not a list of requests that need justifications if not met. In this respect it is illuminating to read the interview of Bill Gould by Joseph Newton (chapters 2.5 and 2.7 in "Thirty Years with Stata").

I don't think that I am naïve if I trust the expertise of Stata Corp. to make good decisions that will improve Stata to the best of the users and Stata as a company (that needs to survive in order to serve us and that needs to serve us in order to survive) -- Stata can't be compared to a government we choose and that can be held accountable for its decisions. If contributions to the wishlist would only be requests to Stata Corp. it would lose some of its functions of a discussion board of users from which we also can learn how to solve issues in ways we didn't thought of.

From my point of view this post is very interesting (thanks to the pointer of chapters 2.5 and 2.7!) as it reveals a strength and a weakness of Stata.Usually Stata Corp commands are really good and easy to use. The syntax across the board of commands (including user written) is the same or similar. This makes Stata very easy to use. I am sometimes astonished how clunky R (or Matlab or Python) can be with tasks I take for granted in Stata.

As someone who spends a lot of time or put it differently investments on coding econometric methods into Stata, I am playing a gamble with every new version of Stata. When I finish a program I want that people use and cite it. This is the currency in academia. Of course I enjoy thinking about how to code - say - an estimator, but I have to convince my employer that doing this is worth it. Proofs are publications and citations. Now, with every new version I am worried or even anxious that the new version includes functions or features I was or currently working on. I know a couple of commands where the Stata implementation crowded out the user written program. The authors of these packages might have their commands out and the Stata Journal paper, but in the long run the command is crowded out. It won't get many more citations and the authors might see it as a lost investment.

Why is this important? For two reasons: first, as a relatively young researcher who tries to pursue an academic career, I need publications, citations and coverage for the next step(s). A publication in the Stata Journal might be well received in the community, but it is often dismissed when it comes to hiring decisions (see a discussion here). The same holds for Stata programs. If my code/program/paper is crowded out, my investment did not pay off. When deciding whether to do another one, I might decide differently. Don't do the project or choose a different program. This leads me to my second point. There are other programs out which are for free (I don't want to start a discussion on this topic, a lot can be said about this!). Of course they don't come with the some of the benefits Stata has (see above). But on the other hand I know that if I do an investment in those, there is no company which might crowed out my work. Of course there is a risk that another academic does it, but at least that is more of an equal competition.

In a nutshell, I wish Stata Corp would be more open with their users (or fanbase) on what they work. I do understand the argument that they need to protect what they are working on from their competitors, but some more hints would be helpful. It would improve certainty if you start working on a new Stata program. We all know that a good programs means a lot of work and care, during and after the development stage and it would be good to know that this time is a good investment.

[daniel klein]

This is the wrong place for this discussion, which touches on multiple interesting points. I'll keep it at a minimum.

as a relatively young researcher who tries to pursue an academic career, I need publications, citations and coverage for the next step(s). A publication in the Stata Journal [...] is often dismissed when it comes to hiring decisions [...]. The same holds for Stata programs. [...]

That is a problem in the scientific community; a software company cannot solve that problem.

I do understand the argument that they need to protect what they are working on from their competitors

There is another reason: Things might not turn out as expected and such failures might occur last minute. Factor variables were supposed to handle log-transformations and more (or so I have heard). Turns out, it is not that easy to implement this.There is nothing worse, from a company's point of view, than announcing (even hinting at) such features that then have to be canceled. Imagine other companies (or research facilities), potential customers really, make investment decisions based on such announcements; there's a fair chance that these companies (or research facilities) will not return as customers if disappointed even once.

[JanDitzen]

Since Stata 17 is out, I believe we can keep the discussion here alive, but I keep my comments short as well.

That is a problem in the scientific community; a software company cannot solve that problem.

On the one hand true, it is a problem of the scientific community and Stata Corp cannot do much here. On the other hand, a software company can set incentives that users produce user written commands. If they internalise (or take over) popular commands, then the user written command is crowded out. In a sense you can see it as the following: the return of (time) investment producing a Stata command in comparison to other research is likely to be smaller (the scientific community "problem"). The return gets further diminished if Stata Corp crowds out the work. This is what my comment was about. I believe if Stata would be more open what they are working on, this might help to ensure that the crowding out does not happen.

There is another reason: Things might not turn out as expected and such failures might occur last minute. Factor variables were supposed to handle log-transformations and more (or so I have heard). Turns out, it is not that easy to implement this.There is nothing worse, from a company's point of view, than announcing (even hinting at) such features that then have to be canceled. Imagine other companies (or research facilities), potential customers really, make investment decisions based on such announcements; there's a fair chance that these companies (or research facilities) will not return as customers if disappointed even once.

Agreed!

[Jiong Yao]

I raised a similar question in #432 and wbuchanan 's reply in #433.

thanks. i think that answer is great!

[Vinci Chow]

I've used the Jupyter kernel for Stata mentioned at this link, and I can confirm it actually works very well. It puts graphs directly in output, supports tab completion, and supports all types of Stata comment syntax. (However, installation can be a bit tricky, involving manual edits to a config file). If StataCorp were to offer an official kernel, I think it would be a very nice feature.

FYI, since I only found this out recently myself--Stata's command line does actually have tab completion, but only for variable names.

For some reason, stata_kernel currently does not work with my installation of Stata 17. Version 1.12 simply does not work on my Linux machine, while version 1.10.5 cannot display graphs inline. If anyone is facing the same issue, I have written an alternative Jupyter kernel based on Stata 17's pystata module: https://github.com/ticoneva/pystata-kernel

[Luke Masha]

Stata should add a function to plot graphs that are common in research more easily. Graphs of hazard ratios with CI, forest plots etc should be given specific commands. Similarly to graph competing events on the same graph requires a lot of a work-arounds. Stata should make it easier to combine curves from mutiple regressions onto one single graph

[Clyde Schechter]

Luke Masha Since Stata 17 is already current, it is way too late to post wishes for it. I think you meant to put this in the Wishlist for Stata 18. Why don't you repost it there, where there is some possibility it will be taken into account in the design of the next release.