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
