[R] How to Describe R to Finance People

[Richard A. O'Keefe]

Tamas Papp <tpapp at axelero.hu> 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.'