[R] Comparison of SAS & R/Splus
rpugh at mango-solutions.com
Fri Sep 5 16:33:44 CEST 2003
Sorry - couldn't resist chipping in.
Firstly, this sort of conversation has been done over and over again on
the S-News list, and I'd look in the archives for more info.
My background: I was a SAS "statistical programmer" in the pharma
industry before I joined Insightful (S-PLUS guys). I now work at Mango
Solutions (an independent consulting firm) so don't feel I'm
particularly biased to either S, R or SAS.
IN MY OPINION, the issue of "comparing" SAS to S/R is a strange one,
because the technologies had very different upbringings. The tools are
also aimed at serving different jobs, and that can really sum up the
differences in one sentence: SAS is a data language, S/R are
On your point about when the different softwares were "developed", I
believe both languages were developed in the 70s. The real difference
is when the systems were "commercialized": SAS in the 70s, S-PLUS in the
90s. That's where the difference in "time lines" occur.
As far as comparisons are concerned, I would go as far as saying that
you "CAN" do everything in S/R that you can do in SAS and vice-versa.
The important factor is often "how easy" it is to do those things. For
example, you can create extremely complex graphics in SAS using things
like Proc Annotate, but I wouldn't recommend it. This again comes back
to the different aims of SAS/S/R: in my experience, data manipulation
and basic reporting can be "easier" in SAS, while fitting stats
models/creating graphics is far better in S/R.
So, why is SAS so heavily used in (say) the pharma industry nowadays?
Firstly, ask yourself how long it would take to rewrite every SAS
macro/application your company uses today, or how much has been invested
in SAS training over the last 10-20 years. Very often, issues such as
these can dominate discussions about transferring to S/R/Whatever.
Having said this, I do know a number of pharma companies who are looking
to move away from SAS. The key here is to take it slowly. There's no
way you can just decide to switch from SAS to S/R overnight. The best
way of going from SAS to S/R is to look at replacing SAS modules
gradually. For example, how about replacing SAS/GRAPH, SAS/STAT,
SAS/IML, SAS/ASSIST, SAS/Access and SAS/INSIGHT with S-PLUS or R? In
most countries, this will save a good deal of money which can be spent
on training/consulting to ensure everyone can get up to speed with S/R.
As far as the FDA is concerned, they do not support any commercial
software, and I know that SAS and S-PLUS are used there. As far as
providing transport files is concerned, that doesn't particularly
restrict the choice of package. Plus, I can't see this standard lasting
- personally I believe that CDISC (or a version of it) will catch on.
www.cdisc.org for more info.
At the end of the day, SAS, S and R are all good technologies, and the
"best one" to use completely depends on what needs to be achieved.
Sorry for the long rambling email ... I'd happily chat more about this
with people "offline" ...
From: r-help-bounces at stat.math.ethz.ch
[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Thomas Lumley
Sent: 05 September 2003 14:49
To: Paul, David A
Cc: r-help at stat.math.ethz.ch
Subject: RE: [R] Comparison of SAS & R/Splus
On Fri, 5 Sep 2003, Paul, David A wrote:
> d. Because SAS is commercial software, a posteriori errors found in
> clinical trials analyses (and due to software issues) can be
> attributed by the NDA applicants to the SAS Institute.
> Lawyers really like this. Of course, Splus is also commercial
> and therefore does not suffer from criticism on these
Note, however, that one of the few specific pieces of guidance the FDA
gives on software is that it isn't sufficient to place your trust in
commercial off-the-shelf software (and of course this is reinforced by
the software licensing terms).
R-help at stat.math.ethz.ch mailing list
Incoming mail is certified Virus Free.
More information about the R-help