3:46 p.m.
On Mon, 18 Jul 2005, Ignacio DÃaz-Emparanza wrote:
I admit R is hard, so for a normal undergraduate student Gretl will
give a
much more friendly and quick taste of what Econometrics does.
But R is so hard because it is so powerfull!!
I don't dispute that. But I know for a fact that *I* don't like using R.
And indirectly, the proof that other people don't either is in the simple
observation that a package which is so good as R (AND FREE AS IN BEER)
is not yet the de-facto standard in the econometrics community. As you
say, a nice front-end application probably would help a lot in bridging
the gap, but I've never seen one yet. If gretl could do the trick, so be
it. But why relegate gretl to this role, when many things could be done
natively?
> This is most likely a
> big problem for someone who is not a full-time econometrician, but it is
> likely to be a big hurdle for people who do applied research who want
> something that "just works". Remember, these people form the vast
majority
> of the users of econometrics/statistical packages. Example: I had a
> colleague who needed the HP filter. Fairly standard, no? It took me less
> time to add it into gretl (with Allin's help) an give him the upgraded
> package than it would have taken having him download and set up R,
> learning how to import his data, perform the filtering, and going back to
> the applications he normally uses. And once this is done, it's done for
> everyone. Rather than the fish, you give people the fishing rod.
Sorry Jack, ... this argument is tricky ;-) You already know programming in
C!! Do you know how much time would I have to dedicate to this job?
( I bought the books about C that Allin recommended to me, but I did not pass
the Fahrenheit-Celsius example )
Don't overestimate my knowledge of C (Allin can testify!). Besides, in the
HP filter incident, I just found a C routine on the net. I never claimed I
wrote it myself.
> If the functionality of gretl as a R front-end can be enhanced,
that would
> be a very cool thing to have (for me at least), but there's no reason to
> be tied to it for the less trivial computations.
May be I have been too much strict with this question. I think that running
commands through the entries in the GUI (in the menus) is much more friendly
that running commands in the console. So we should try to fill the menus with
so many elements as the GUI can accept. But I suspect that soon there will be
no room for many more elements than we already have, so gretl will have to
evolution more through the console commands. And this will do the user have
to look more frequently at the manual.
Certainly. But gretl's scripting syntax is far easier to grasp to the
casual user than R's syntax is. But again, this is a personal feeling.
Moreover, the most recent additions to the function code make it much
easier to write scripts.
> Besides, if you look at
> the source, the infrastructure for adding more sophisticated stuff into
> gretl is already there.
Yes, this is something that Allin told me, but I had no time to try. Have we
documentation about this?
As Obi-Wan Kenobi would say... "use the source, Luke!" ;-)
No, seriously I think we're a bit lacking in that respect, but the one
person who knows precisely how the source works is already putting so much
effort for the benefit of the community that we can't expect Allin to
write docs too. My advice to you and all the others who would like to have
a peek under the hood is to download the source and tale a look to the
files in the "plugin" subdirectory. Most procedures in there are
reasonably self-contained. That's the way I started, anyway.
> only a few weeks to have the full Johansen procedure set up.
Once we're
> there, I have the feeling that the number of users who would choose gretl
> would exceed those who use R by several orders of magnitude.
You are optimistic,... That is good!!
(By the way, do you know Gretl is at the top 5% of sourceforge downloads for
several weeks?)
That's cool! How do you get these statistics?
> As for competition between R and gretl. In my view, competition
is GOOD.
> These are not commercial products. These applications are part of the free
> software ecosystem, where biodiversity is essential for survival. Contrary
> to commercial software, the existence of a competitor produces POSITIVE
> externalities (take a look at KDE/Gnome). There is room for R and gretl,
> and to spare, just the same way you get Debian, SuSe, Red Hat, Mandriva,
> Ubuntu and all the various linux distros.
I am sure competition is good for the "products", but I think it is not so
good for the users. For example, the R development team decided not to
support the development of an R GUI. So they leave volunteer programmers
to work in a competitive way (see http://www.sciviews.org/_rgui/ ). The result
is that after several years of development the user does not have a decent
graphical interface for R. I am sure that if this efforts had been
coordinated the result would be different.
This is the trouble with all volunteer-based projects. But as you say,
I'm an optimist. Eventually (asymptotically?) what's good for the products
is good for the users. Small-sample bias can be huge, though :-)
Have a nice day,
Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università di Ancona
jack(a)dea.unian.it
http://www.econ.unian.it/lucchetti