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.
1. It is not complete.
2. 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.
3. 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-...
. 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
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
Lee Adkins
Professor of Economics
lee.adkins(a)okstate.edu
learneconometrics.com