One general question: do we want to make a big deal of gretl 2.0, or
do we want to "do a Linus"?
I think a Linus is fine. The evolution of gretl is steady and a lot has changed from say 1.7 to 1.9.7
1) Major new functionality
2) Major changes in the GUI
3) A major backward-incompatible clean-up of hansl
I agree with Alin completely here.
4) A major change in the libgretl API, to make it easier for third
parties to use
* Major new functionality: Well, if we're talking C code, then at
present that means stuff that Jack and I will produce. I put my view
on this at the 2011 gretl conference: I think we now have a good
enough baseline that people ought to be able to add functionality to
gretl in the form of function packages and "addons". I certainly
stand ready to fix bugs and tweak the C code (including the GUI code
and the "gretl server" infrastructure) to make that easier. But
right now I myself have no plans to add major econometric
functionality in C form. Jack has been working on substantial new
stuff, but in the form of (brilliant) hansl code rather than C.
The main estimators "missing" are the various simulated mle and such. gretl is already competent in the main categories, wls, iv, gmm, mle, nls. This is not a big deal for me, but as models get fancier, these techniques will be used more. Whether this is better done as an addon or in C I can't say.
* Major changes in the GUI: That's up to me alone, and I have no
plans in that area. Nor do I expect to have time to implement truly
big ideas that others may come up with, though I'm always ready to
consider incremental improvements and bug fixes.
The biggest problem I have with the GUI is window proliferation. As it is now, in a few minutes you end up with a dozen open windows to sort through and this is clunky. Is there a way to introduce tabs into the script editor and perhaps the output windows? So, for instance, the script editor contains tabs for each open script. Ditto for the model output windows. I realize that the session concept is a good way to organize the models, but tabs would be good as well. Being able to dock the main window, the console, and tabbed output window would be very nice.
* Major backward-incompatible clean-up of hansl: consistency and
cleanliness are good, but so is continuing backward compatibility. I
can surely see a case for scrapping some archaisms. But I seem to
recall some folk wisdom from computer science: the production of a
backward-incompatible "cleaned up" version 2 of language L often
results in fragmentation of the user base and decline of L.
It is ok as is. As conflicts arise, they do get taken care of.
* Clean-up of the libgretl API: A good idea. But this can be done
without much (if any) change that is visible to users of gretl
itself, so it's probably not very pertinent to the "2.0" question.
* Purge of bugs and update/completion of documentation: Here I can
really get on board. One conception of gretl 2.0 is that it has
achieved a degree of maturity where we have squashed as many bugs as
we can find on an extended period of testing, and have documented in
a reasonably comprehensible and cross-referenced form all that the
program can do.
This should be the first priority. The documentation is excellent in what it covers, but it suffers three problems.
- It is not complete.
- It is hard to use because it is not sufficiently cross-referenced. Half the stuff I'm looking for is covered in the User Guide the other half in the Command Reference and they don't communicate with each other. There are also the example scripts, many of which are undocumented, that should be cross-referenced in both places.
- It is not easy for potential contributors to add tthings. It might be useful to consider some sort of structure for writing and reviewing new documentation. This is not a trivial pursuit by any means. Consistency of terms and notation across such a large swath of econometric practice not a easy thing to accomplish.
Open source documentation can be horrible (witness R). Gretl, for what it has, is good. We're just not taking much advantage of the openness ... which as R demonstrates, is not without problems. Cross-referencing and openness, though not incompatible, are certainly not going to be easy to do without some commitment.
Should the User Guide be modularlized in order to make it easier to add entries to the Econometric Methods section?
I'd like to see a way to add documented examples that can be accessed from links with the command and the user reference. We've already got some nice examples in the program itself, but they need some words to go with the hansl code, IMO. As an example, if I open the command reference and click on leverage, I'm taken to some stuff that comes from the Command Reference document. At the bottom, there should be links to the relevant entries in the User Guide and to the leverage.inp script. Also, the leverage script example should be discussed in the User Guide. This is bound to make translations harder.
The only other canned software I'm using these days is Stata (and R, only if I absolutely must). So, I'm not familiar with how Eviews, Limdep, SAS, or other econometric software is documented. The documents in Stata are very good. The examples help a lot. Stata's findit command is magical.
Cheers All,
Lee
PS I suppose it's about time for me to start working on the next conference. Ignacio sent me a to do list a couple of months ago, and despite his kind urging and support, I've been in complete denial about my impending role. I hope to meet with our extension director next week to get the ball rolling.
FWIW, we hosted a very large (well 200+ attendees) marketing conference last year and managed to do it in Stillwater. Here's the PR department's take on it:
http://spears.okstate.edu/news/2011/06/28/osu-hosts-prestigious-amasheth-foundation-consortium/ . We sent vans to OKC or Tulsa to retrieve folks from the airport. A lot will depend on finances -- hosting here may cost less and I might be more likely to get the Dean to cough up some support. I'll know more by the end of the month. Any thoughts?
Allin