R help - Jan 2008 - I need arguments pro-S-PLUS and against SAS...

I need arguments pro-S-PLUS and against SAS for a meeting I will 
have next week. S-Plus is (90 - 99)% compatible with R, so using 
S-Plus will make things much easier for everyone. But I can't use
this argument. What other arguments could I use?

Alberto Monteiro

On 1/4/08, Alberto Monteiro <albmont at centroin.com.br>
wrote:
> I need arguments pro-S-PLUS and against SAS for a meeting I will
> have next week. S-Plus is (90 - 99)% compatible with R, so using
> S-Plus will make things much easier for everyone. But I can't use
> this argument. What other arguments could I use?
There was a recent discussion "who uses r". Maybe some arguments there
are useful in your case.

Liviu

You might want to descibe what uses you expect to have
for SAS and/or R. It might make it easier for people
to make specific recommendations.

Personally I like the graphics, ease of writing
functions, and general ease of data manipulation.


--- Alberto Monteiro <albmont at centroin.com.br> wrote:
> I need arguments pro-S-PLUS and against SAS for a
> meeting I will 
> have next week. S-Plus is (90 - 99)% compatible with
> R, so using 
> S-Plus will make things much easier for everyone.
> But I can't use
> this argument. What other arguments could I use?
> 
> Alberto Monteiro
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained,
> reproducible code.
>

SAS programming is easy if everything you want to do fits easily into the
row-at-a-time DATA step paradigm.  If it doesn't, you have to write macros,
which are an abomination.  DATA step statements and macros are entirely
different programming languages, with one doing evaluations at
"compile" time,
and the other at "run" time.  Except that that's not really true,
either,
witness the 'call symput()' construct.  

Then, if you want to interact at all with the user, you need to learn SCL, a
third language, with it's own rules.  And to do anything sophisticated with
a
user interface (which will still look like hell), you have to learn the SAS
A/F toolkit built on SCL.  And of course, A/F requires you to think
differently yet again.

So, to be a competent and versatile SAS programmer, you have to learn four
languages and four paradigms, and keep them all straight in your head while
programming.  Of course, hardly anyone can do this, so you usually find stacks
of reference documentation close at hand when you visit a SAS programmer's
office.

R and Splus don't offer much in the way of GUI programming, but for problems
that don't require a lot of GUI, it's very nice.  You learn one
language, it's
quite forgiving, it's interpreted and usually easy to debug, and the
programs
you end up with are far more readable and maintainable than anything a SAS
programmer can turn out.  Reading my own SAS code is bad, and reading someone
else's is torture. 

Do I sound like an R bigot?  Actually, I'm a Smalltalk bigot, which is even
nicer than R.  But R is quite usable for most things I do, and I use Smalltalk
for GUI-intensive stuff.  Speaking as a programmer, SAS is awful. 

-- 
Jeff

> John Sorkin wrote:
> The difference is not so much the language
> as the end users.
> S-Plus, R, SAS, etc. are all similar in that
> they are all tools to an end and not an end
> in themselves.
Try to find one user who:
  1. is familiar with both SAS and R/S-Plus;
  2. has to do real data analysis work (i.e., other than following
pre-canned procedures, or simpler tasks like data assembly, moderate
data processing etc);
  3. prefers to rely on SAS.
It is impossible; this kind of person does not exist. In my view,
statement #3 negates statement #1, or #2, or both.

And no, the tools are not similar. The end _is_ the tool you use.


> -----Original Message-----
> From: r-help-bounces at r-project.org
> [mailto:r-help-bounces at r-project.org] On Behalf Of Frank E Harrell Jr
> Sent: Monday, January 07, 2008 7:31 PM
> To: John Sorkin
> Cc: r-help at stat.math.ethz.ch
> Subject: Re: [R] I need arguments pro-S-PLUS and against SAS...
>
> John Sorkin wrote:
> > Frank,
> > I believe you are proving my point. The difference is not
> so much the language as the end users. I use SAS, R, and
> SPlus on a regular basis. For some analyses, SAS is easiest
> to use, for some R (or SPlus). I can be just as dangerous
> using SAS and I can be with R if I don't think about what I
> am doing and not only check the assumptions of my models, but
> also pay attention to the results of the checks. You see
> problems with SAS data sets because you know what to look for
> and take the trouble to look for problems. When R (or SPlus)
> becomes commonly used by the great unwashed public, the
> number of poorly done analyses in these languages will
> increase. The basic problem with statistical software is that
> by making analyses easy to do, they allow anyone to do
> analyses. When an unprepared person sets about doing a
> complex task that should demand proper training and
> experience bad things happen quickly, and with high probability.
> >
> > In any event, regardless of which side of the argument
> members of the R listserver might take, we are all deeply in
> your debt for the many contributions you have made not only
> to the R environment, but also to the R listserver. On behalf
> of the entire R community, thank you.
> >
>
> We'll have to have a friendly but strong disagreement about
> this.  I've
> watched statisticians work too many times to not believe that
> many will
> take the expedient route (e.g., assume linearity) when using
> non-flexible or non-powerful software (e.g., SAS).  And I don't find
> errors in the data usually because I know the data.  I find errors
> because I can say things like
>
>   library(Hmisc)
>   datadensity(mydata)   # show all raw data in small rug plots
>   hist.data.frame(mydata)  # postage-stamp size histograms of all
> variables in dataset
>   latex(describe(mydata)) # like PROC UNIVARIATE but shows MUCH more
> information in MUCH less space, including a high-resolution histogram
> next to the tabular info for each variable
>
> I do agree with your comment about making things easy to do.
>
> > With greatest respect and thanks,
>
> Thanks very much for the kind words John.
>
> Cheers
>
> Frank
>
> > John
> >
> > John Sorkin M.D., Ph.D.
> > Chief, Biostatistics and Informatics
> > University of Maryland School of Medicine Division of Gerontology
> > Baltimore VA Medical Center
> > 10 North Greene Street
> > GRECC (BT/18/GR)
> > Baltimore, MD 21201-1524
> > (Phone) 410-605-7119
> > (Fax) 410-605-7913 (Please call phone number above prior to faxing)
> >
> >>>> Frank E Harrell Jr <f.harrell at vanderbilt.edu>
1/7/2008
> 6:41 PM >>>
> > John Sorkin wrote:
> >> I fear I risk being viewed as something of a curmudgeon,
> but the truth must be stated. S-Plus, R, SAS, etc. are all
> similar in that they are all tools to an end and not an end
> in themselves. Any one of the three can do most statistical
> analyses one might want to do. I could point out the
> strengths of  any one of the programming environments, but to
> be fair I would then be required to point out each platform's
> weaknesses. In the end, what matters is the quality and
> abilities of the person who uses the tools, not the tools
> themselves. I don't think you can make a fair statement that
> any one is absolutely better than the other.
> >> John
> >
> > John - I must respectfully disagree at least in part.  I
> have noticed
> > that SAS users are far more likely to assume linearity in doing
> > regression modeling, because SAS makes it so difficult to
> specify that
> > you want an unknown smooth function of a covariate in a model.  SAS
> > users are also less likely to bootstrap and to validate statistical
> > models because it's such a pain to do those in SAS.  Also
> when I get SAS
> > datasets from companies that have paid a fortune to a
> SAS-based contract
> > research organization, I can quickly spot major data errors using S
> > graphics; these errors were missed by all the SAS users
> because of poor
> > graphics.
> >
> > Frank
> >
> >> John Sorkin M.D., Ph.D.
> >> Chief, Biostatistics and Informatics
> >> University of Maryland School of Medicine Division of Gerontology
> >> Baltimore VA Medical Center
> >> 10 North Greene Street
> >> GRECC (BT/18/GR)
> >> Baltimore, MD 21201-1524
> >> (Phone) 410-605-7119
> >> (Fax) 410-605-7913 (Please call phone number above prior to
faxing)
> >>
> >>>>> Jeffrey J. Hallman <jhallman at frb.gov>
1/7/2008 4:09 PM >>>
> >> SAS programming is easy if everything you want to do fits
> easily into the
> >> row-at-a-time DATA step paradigm.  If it doesn't, you have
> to write macros,
> >> which are an abomination.  DATA step statements and macros
> are entirely
> >> different programming languages, with one doing
> evaluations at "compile" time,
> >> and the other at "run" time.  Except that that's not
> really true, either,
> >> witness the 'call symput()' construct.
> >>
> >> Then, if you want to interact at all with the user, you
> need to learn SCL, a
> >> third language, with it's own rules.  And to do anything
> sophisticated with a
> >> user interface (which will still look like hell), you have
> to learn the SAS
> >> A/F toolkit built on SCL.  And of course, A/F requires you to
think
> >> differently yet again.
> >>
> >> So, to be a competent and versatile SAS programmer, you
> have to learn four
> >> languages and four paradigms, and keep them all straight
> in your head while
> >> programming.  Of course, hardly anyone can do this, so you
> usually find stacks
> >> of reference documentation close at hand when you visit a
> SAS programmer's
> >> office.
> >>
> >> R and Splus don't offer much in the way of GUI
> programming, but for problems
> >> that don't require a lot of GUI, it's very nice.  You
> learn one language, it's
> >> quite forgiving, it's interpreted and usually easy to
> debug, and the programs
> >> you end up with are far more readable and maintainable
> than anything a SAS
> >> programmer can turn out.  Reading my own SAS code is bad,
> and reading someone
> >> else's is torture.
> >>
> >> Do I sound like an R bigot?  Actually, I'm a Smalltalk
> bigot, which is even
> >> nicer than R.  But R is quite usable for most things I do,
> and I use Smalltalk
> >> for GUI-intensive stuff.  Speaking as a programmer, SAS is awful.
> >>
> >
> >
>
>
> --
> Frank E Harrell Jr   Professor and Chair           School of Medicine
>                       Department of Biostatistics
> Vanderbilt University
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

You might find this article useful....

Kellie B. Keeling and Robert J. Pavur, A comparative study of the
reliability of
nine statistical software packages,
Computational Statistics & Data Analysis, Volume 51, Issue 8, 1 May 2007,
Pages
3811-3831.
(http://www.sciencedirect.com/science/article/B6V8V-4JHMGWJ-1/2/77a29a95c2071997f13fcca7267711d1)




Alberto Monteiro wrote:
> 
> I need arguments pro-S-PLUS and against SAS for a meeting I will 
> have next week. S-Plus is (90 - 99)% compatible with R, so using 
> S-Plus will make things much easier for everyone. But I can't use
> this argument. What other arguments could I use?
> 
> Alberto Monteiro
> 
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
> http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
> 
> 
-- 
View this message in context:
http://www.nabble.com/I-need-arguments-pro-S-PLUS-and-against-SAS...-tp14621011p14713230.html
Sent from the R help mailing list archive at Nabble.com.