Tamas Papp <[EMAIL PROTECTED]> wrote:
I would emphasize the following:
...
2. The programming language is really friendly and convenient to work
with. In finance, you often need to hack together special solutions
for problems that are not conventional (especially in term structure
models, but I think that the same applies to bi- and trinomial models
and their ilk). As an R newbie, it took me an afternoon to implement
a basic toolkit for the former, which I could use for interesting
explorations.
There are three perspectives on programming languages like the S/R family:
(1) The programming language perspective.
I am sorry to tell you that the only excuse for R is S.
R is *weird*. It combines error-prone C-like syntax with data structures
that are APL-like but not sufficiently* APL-like to have behaviour that
is easy to reason about. The scope rules (certainly the scope rules for
S) were obviously designed by someone who had a fanatical hatred of
compilers and wanted to ensure that the language could never be usefully
compiled. Thanks to 'with' the R scope rules are little better. The
fact that (object)$name returns NULL instead of reporting an error when
the object doesn't _have_ a $name property means that errors can be
delayed to the point where debugging is harder than it needs to be.
The existence of two largely unrelated object-oriented extensions
further complicates the language.
APL, Xerox's Interactive Data-analysis Language (an extension of
Interlisp), and Lisp-Stat are *far* cleaner as programming languages.
(2) The Excel perspective.
Many people are using Excel as their statistics package.
(One of my students persists in using it for making his graphs.
I've talked another lecturer and his student into using R although
it's too late for a paper they've published. Dark backgrounds for
printed graphs don't work well. What persuaded them was a number
of relevant things available out-of-the-box in R.)
In Excel, there are at least three "languages":
- direct manipulation
- the formula language
- Visual Basic for Applications
What R offers is a *single* language that's used uniformly,
with a rich data model.
(3) The statistics package perspective.
I've used Minitab, GLIM, SPSS, Matlab, and Octave (and BASIS, if
anyone remembers that). I've owned and read manuals for GENSTAT.
Recently I had occasion to look at more SAS code than I ever wish to.
(No, I didn't understand it.) Several of these packages share a
common design feature: there is a language of built-in commands,
perhaps a data transformation language, and a separate macro language.
The macro language is typically very clumsy.
What R offers is a *single* language that's used uniformly,
with a rich data model. Analysis components you get off CRAN are
accessed using the *same* syntax as 'built-in' analyses.
R also offers something important for people who _do_ have the money
to buy commercial packages, and who might be reluctant to trust open
source: a very high degree of compatibility with an established
commercial product. R could almost be seen as an indefinite lifetime
'evaluation' version of S-Plus.
The fact that I can use 'contributed' code, or even my own code, exactly
the same way as 'built-in' stuff, even including access to on-line
documentation and examples, actually *improves* the learning curve for R
compared with many packages. At least it did for me.
In the words of an old Listerine commercial: 'I hate it. Twice a day.'
______________________________________________
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
