I learned R but it seems that companies are much more interested in SAS experience. What are the advantages of SAS over R?
$\begingroup$
$\endgroup$
15
asked Aug 6, 2012 at 17:56
-
19$\begingroup$ It's tragic, but true I fear... $\endgroup$– gung - Reinstate MonicaAug 6, 2012 at 17:59
-
22$\begingroup$ A medical statistician once told me, that they use SAS because if they make mistakes due to software bugs and it comes to lawsuits, SAS will recompensate them. R comes without warranty. $\endgroup$– MomoAug 6, 2012 at 20:15
-
46$\begingroup$ @Momo R comes without warranty, true, but I would like to see a reference that SAS has that strong of one. I could not find the SAS license text on their website, but was able to find something for one component: support.sas.com/documentation/onlinedoc/sasc/doc650/common/… That has a 90 day warranty on the media that the software is shipped on and an all caps disclaimer of any other warranty. Please give a reference other than "someone once told me". $\endgroup$– Brian DiggsAug 6, 2012 at 20:54
-
14$\begingroup$ Was just meant as an anecdote, I like the pragmatic cynicism of the comment. But glad you checked, I never cared. $\endgroup$– MomoAug 6, 2012 at 21:46
-
41$\begingroup$ SAS comes with the same warranty as R: none. $\endgroup$– Frank HarrellJan 8, 2013 at 13:26
|
Show 10 more comments
25 Answers
$\begingroup$
$\endgroup$
30
I think there are several issues (in ascending order of possible validity):
- Tradition / habit: people are used to SAS, and don't want to have to learn something new. (Making it more difficult, the way you think in SAS and R is different.) This can apply to anyone who might have to send you code, or read / use your code, including managers and colleagues.
- Distrust of freeware: I've had several people say they aren't willing to accept results from R because you don't have a for-profit company vetting the code to ensure it gives correct results before it goes out to customers, lest they end up losing business.
- Big data: R performs operations with everything in memory, whereas SAS doesn't necessarily. Thus, if your data approaches the limits of your memory, there will be problems.
Personally, I only think #3 has any legitimate merit, although there are approaches to big data that have been developed with R. The issues with #1 speak for themselves. I think #2 ignores several facts: there is some vetting that goes on with R, many of the main packages are written by some of the biggest names in statistics, and there have been studies that compare the accuracy of different statistical software & R has certainly been competitive.
answered Aug 6, 2012 at 18:10
-
44$\begingroup$ Point 1 gains more legitimacy if you also include "existing infrastructure" under that inertia banner. If there are existing business processes which already use SAS, then there is a transition cost with changing. If this is the case, it is not choosing between SAS and R, but choosing between staying with SAS and changing to R, which can have a different conclusion. $\endgroup$ Aug 6, 2012 at 18:16
-
26$\begingroup$ The point of Point 2 is that, while SOME R packages are written by experts, others are not. Who vouches for them? Who tests them? (I know they are tested that they RUN, but who tests that they work correctly?) I know, you can look at the code, but that presupposes the time and ability to look over someone else's code and verify it, often for methods that are very complex. $\endgroup$ Aug 6, 2012 at 19:03
-
20$\begingroup$ @PeterFlom, you raise a reasonable point. As the packages become more esoteric, there is less of a guarantee than there is w/ the basic stuff. But how far afield do you have to go? Even SEM, which is pretty advanced, was written in R by John Fox. Additionally, StasK makes a good point about the reality of the vetting of statistical software in practice. Finally, R is vastly more comprehensive than anything else, so when you want to do esoteric things w/ other software, you mostly have to code it up yourself. Who guarantees the accuracy of that code? $\endgroup$ Aug 6, 2012 at 19:19
-
36$\begingroup$ Who exactly vets SAS, Stata, SPSS, code? Is there any way at all to know if the results they provide, by the methods they say they are using, are actually implemented correctly? I know from following, for example, the
lme4mailing list that comparisons to SAS come up quite regularly. But it's impossible to know if we should even be making such comparisons. Without access to the source, we have to take those companies at their word that results produced by their software are actually valid. Frankly, I prefer to have the ability to review the software code I use. $\endgroup$ Aug 7, 2012 at 1:17 -
30$\begingroup$ True, but it's hard to penalize a statistical computing system for its comprehensiveness. Or to say it another way, R's way of doing something is better than another system's way of not doing it. $\endgroup$ Aug 7, 2012 at 12:29
$\begingroup$
$\endgroup$
6
In addition to the good answers so far, I'd add the embarrassment factor. If you spend hundreds of thousands of dollars last year on SAS and SAS support, and you propose spending nothing for R, with extremely low support prices (Revolution, etc), someone up the chain's going to ask why. Was it a mistake to spend so much money last year when R existed last year? Or is it a mistake to drop professional software for something created by a group of volunteers?
Once the problem's framed in that manner, it's a lose-lose proposition, so perhaps better to not bring it up.
-
54$\begingroup$ This is perhaps the most cynical answer on cross validated. +1 $\endgroup$ Jan 7, 2013 at 13:12
-
11$\begingroup$ @probabilityislogic: Thanks! To be clear, this is more of a comment on poor higher-level management than on the people who use the software. I've worked in places where there really was the attitude (at higher levels), "Hmmm... you didn't spend all of the money we budgeted for you this year. Obviously you can get by on less money, so we're cutting your budget for next year and giving the extra to the department who overspent." Dilbert Rules. $\endgroup$– WayneJan 7, 2013 at 15:31
-
11$\begingroup$ "You did not spend the money..." -- that's exactly how the Soviet planning system used to work, from my firsthand knowledge. $\endgroup$– StasKJan 9, 2013 at 16:19
-
5$\begingroup$ Someone up the chain needs to be explained that for a fraction of the cost of a SAS license, you can install R Studio Server on an AWS Virtual Machine with 16 cores and 256 GB RAM - in the hands of 2 good R programmers, that's more powerful than anything SAS can do. Think how fast billion records can be fuzzy matched to each other ! Or for that matter even Open source PostgreSQL with Python + PERL will achieve at a fraction of a cost. $\endgroup$– vagabondFeb 4, 2015 at 22:01
-
1$\begingroup$ "Or is it a mistake to drop professional software for something created by a group of volunteers?" This is a false dichotomy! $\endgroup$ Aug 7, 2015 at 18:36
$\begingroup$
$\endgroup$
4
On top of what gung has correctly identified here, the biggest issue in the corporate world is legacy. And when you have a good quality production code that is known to do the job, you don't change it. SAS was out there since 1970s, and at the time it was the only effective, by then-standards, scripting statistical language. The amount of production code accumulated since then in SAS in pharma and government is unimaginable, tens of thosands of human years. Rewriting this in R or Stata would take a few years, the resulting code will become more flexible, more efficient, more transparent, easier and cheaper to maintain, but nobody will pay for such refactoring. (My experience doing this is that my Stata code is generally about three times shorter; I once had a project converting SPSS code into Stata where I made it about 20 times shorter. For those of you who worked in maintaining your statistical packages... well, you know what that means.)
In a sense, this is a similar story with the academic publishers: they are riding a tide of the end users maintaining their subscriptions out of necessity; a university without subscription to Nature is not really a university. Free publishing via professional societies will make it cheaper, people prepare their submissions in LaTeX these days, so they are camera ready, and the same people will be providing the peer review, so there will be no quality setback on any of the dimensions. But... there's no brand name and the impact factor behind the online journals.
This sums it all up: http://scatter.wordpress.com/2011/06/28/stata-12/. Stata is preferred in economics and policy-related circles, and the more I learn SAS, the more I like Stata.
-
41$\begingroup$ SAS has a horrific syntax that started with something similar to JCL (IBM's Job Control Language) for submitting punched-card batch jobs back in the day. It's remarkable that people are still using it, really. $\endgroup$– WayneAug 6, 2012 at 19:33
-
6$\begingroup$ +1 I particularly enjoyed the BlackBerry:iOS:Android:Nokia as SAS:Stata:R:SPSS analogy in the scatterplot post. $\endgroup$– jthetzelAug 6, 2012 at 21:24
-
6$\begingroup$ Wayne, if you have ever had given another thought about CARDS statement, you realize that SAS is the statistical software package to work with punchcards. Stata works with rectangular data sets. R works with objects. So depending on what kind of data format you have to deal with, one may be better than others. $\endgroup$– StasKAug 7, 2012 at 3:36
-
3$\begingroup$ One big point in the legacy is things like FDA approval or similar regulations. Industry I've spoken to won't touch anyhing(TM) after they got through that to be sure they don't have to go through the whole process again. And that is a big argument in terms of money. $\endgroup$ Aug 11, 2012 at 14:50
$\begingroup$
$\endgroup$
2
I have worked as effectively a SAS programmer for the last seven years, next to me a co-worker has been programming SAS longer than I have been alive. As noted here, there is a massive amount of inertia/legacy behind SAS; but SAS just like R is a way to a means, not the means itself.
SAS is extremely efficient at sequential data access, and database access through SQL is extremely well integrated. PROC's are very well documented, but unfortunately not-entirely standardized with notation (PROC OPTMODEL and IML are two examples). It is a bit clumsy when it comes to writing complicated code, and not as elegant for parallel code. I have also found importing csv files to be a source of great misery at times and prefer to just dump it to R first then to a database.
Although SAS does have interfaces to shared objects and dll's you don't get nice access to any header files or anything like that, and code distribution also isn't available through happy packages.
There is however little concern about someone including some esoteric now-defunct or broken package in your code that you now need to maintain, and the quality of the code in SAS tends to be uniformly excellent (R core code is also excellent, and also freely available to anyone).
As mentioned before SAS is also extremely expensive, but it is a good tool that I go to when I know there is a canned procedure that works well for my needs.
R + SAS + mysql with a little bit of perl to glue to them together works amazingly :)
-
11$\begingroup$ The remark about maintaining old packages goes just as well for a user written macro or an old proc that sas hasn't updated. $\endgroup$ Jan 7, 2013 at 13:05
-
4$\begingroup$ R has also very good SQL support gained recently via
dplyrlibrary - it literally translates R/dplyr syntax into SQL and calls the database, you can decide what operations to do on db server and what locally using the same syntax: cran.r-project.org/web/packages/dplyr/vignettes/databases.html $\endgroup$– Tim ♦Jul 20, 2015 at 19:41
$\begingroup$
$\endgroup$
8
So I use both R and SAS - admittedly in academia - but there are a couple reasons that I tend to head toward SAS at times:
- Better documentation. R is getting better at this, but documentation, especially the official documentation, is often kind of terrible and opaque. Beyond that, SAS is supported by a massive infrastructure of books - the use R! series is helping this in R, but it's not quite there yet. I can turn to Paul Allison's Survival Analysis Using SAS, or Categorical Data Analysis Using SAS or the book I have on Monte Carlo methods using SAS and I have a book clearly written in a fairly consistent style for the language I'm using.
- Inertia. This isn't just "companies are lazy" - inertia has value too. There's institutional knowledge. So-and-so has code that does that - and does it well.
- Packages. Some packages in R are amazing. Some packages are not. You have to go find them, evaluate them, and even then there's some leap-of-faith issues in that the package is only as good as the guy writing it. It's hard to trust that. SAS has essentially the "full faith and credit of the SAS Institute" which has a pretty solid track record.
- Single-source support. If SAS is broken, you call SAS. If R is broken you call....?
-
21$\begingroup$ "If R is broken you call....?" Brian Ripley :-) (+1 for this well argued response) $\endgroup$– chlAug 11, 2012 at 20:28
-
6$\begingroup$ Regarding 4), I think there is a confounding of concepts. If you use a program and it breaks, you generally have two options. You can pay for support, or you can seek out freely available support (online community, literature, yourself). R and SAS can be compared as statistical programming languages. Both have freely available support, which can also be compared. R and SAS cannot be compared as paid support solutions... $\endgroup$– jthetzelAug 11, 2012 at 21:16
-
7$\begingroup$ ...SAS Institute provides paid support for SAS. Companies like Revolution Analytics and TIBCO (S+) provide paid support for R. If you want to compare paid support solutions for R and SAS, you should compare SAS Institute to Revolution Analytics and TIBCO, not R. The confusion, I believe, arises from the tight integration of the SAS language with the SAS Institute and the non-integration of the R language with R-related corporate support and education. $\endgroup$– jthetzelAug 11, 2012 at 21:17
-
3$\begingroup$ @jthetzel I don't think its "confusion". SAS the language is tightly coupled with SAS the service. Any platform SAS works on has support from SAS. This is not true for R - support and the language are decoupled, there may be no help for you depending on platform (try talking to Revolution sometime while not using Windows or RHEL...), and they won't necessarily take responsibility for RandomPackage's errors, where as SAS will support PROC Arbitrary. $\endgroup$– FomiteAug 11, 2012 at 21:22
-
2$\begingroup$ @probabilityislogic I think its beyond having to evaluate it to see if its appropriate for your analysis. Yes, both could be wrong, and both need to be evaluated. But I trust SAS's quality control team more than I trust me, on my own. $\endgroup$– FomiteJan 7, 2013 at 22:18
$\begingroup$
$\endgroup$
10
Nobody has suggested the reason it is preferred is plain idiocy. Here's two quotes I recently came across:
"Using open-source software such as R was out of the question – we couldn't guarantee a perfectly repeatable outcome"
and
"We would be unable to provide any support for this as it is open source software"
Two minutes with these people would show them how wrong they are.
-
4$\begingroup$ Two minutes with which people? Without references it's almost as if you just made those quotes up. $\endgroup$ Aug 7, 2012 at 7:21
-
4$\begingroup$ the second quote seems fine from a council IT department, they can't be expected to support all possible open source software that a customer might use, hence the blanket warning. I think the worst anti open source quote I've heard was from SAS saying soemthing like 'would you trust a jumbo jet designed in open source, an engine might drop off' $\endgroup$ Aug 7, 2012 at 12:37
-
5$\begingroup$ @PaulHurleyuk: +1 The quote was “We have customers who build engines for aircraft. I am happy they are not using freeware when I get on a jet.” by a SAS marketing director in this New York Times article on R. The SAS representative clarified her remarks in a later blog post. $\endgroup$– jthetzelAug 7, 2012 at 12:53
-
4$\begingroup$ @PaulHurleyuk: Equally the council can't be expected to support any proprietary software the customer might want to use. The open-ness is not the reason. If they'd said they couldn't support anything outside their supported set of software then fine. $\endgroup$ Aug 7, 2012 at 13:30
-
5$\begingroup$ In the two cases I quote, there could well be a rational decision, but the reasons given are clearly not those reasons. A rational reason might be "we already support SAS, and we can't afford to support two stats packages". But "We can't support this because it is open source" is a non-sequitur. The two parts may be true, but the conclusion does not follow. Its like saying "Elizabeth is the Queen because the sky is blue". $\endgroup$ Aug 8, 2012 at 7:08
$\begingroup$
$\endgroup$
1
One issue does not seem to have been addressed explicitly: ass-covering. If you go with SAS and things blow up, the decision maker can always say that he bought state-of-the-art software, and how was he to know it would break? If he decided to go with R, this argument will be harder to make. Yes, this is related to the inertia argument already mentioned here.
A few decades ago, they used to say that "noboby ever got fired for buying IBM", which has been called the greatest marketing phrase ever.
answered Jan 7, 2013 at 8:49
-
2$\begingroup$ Although, I'm not sure how R is any less state-of-the-art than SAS (and with regards to many procedures, I am under the impression that R is more state-of-the-art than SAS). My guess is that a lot of SAS users don't know about that though... $\endgroup$ May 24, 2013 at 22:55
$\begingroup$
$\endgroup$
The times they are a changing
As of 2015, actuaries under the age of about 35 prefer using R - the text books use both R and SAS code. Older actuaries never learnt to use R and prefer SAS and do not use R. The proportion of actuaries actually coding in SAS will decline.
If you search Google scholar for papers referring to SAS - then you will find a steady 550-ish publications per year for the last few years. If you search for papers using R ("R Foundation for Statistical Computing"), there were 25,100 in 2014 and as of mid-July 2015 there are 16,700. Plotting the rate - it's growing very fast!
SAS didn't help themselves for a few years by demanding large licence fees from universities - which they have since reversed - but it is now too late many universities have converted to teaching using R and not SAS.
New statistical techniques are published in papers in conjunction with an R package. Some techniques that have been in base R for years have still not appeared in SAS. You can now use R from inside SAS.
In summary, things are changing and changing fast.
$\begingroup$
$\endgroup$
1
As a user of both SAS and R, I would say the biggest reason we use SAS over R (when we do) is its ability for sequential processing. We only need machines with no more than 4GB RAM to process 15 years worth of data. I would need a much larger machine using stock R and I have not tried to migrate the SAS code to run with Revolution R.
-
8$\begingroup$ +1, although it's worth noting that there are a few ways to work with larger-than-memory datasets in R (bigmemory, ff, chunking data from a database, a wide range of distributed computing options). But all of that takes setup; SAS will indeed just chug through whatever you throw at it, which is a real advantage. $\endgroup$ Jan 16, 2013 at 17:58
$\begingroup$
$\endgroup$
9
In the pharmaceutical industry SAS is used because it is what the FDA uses and likes. There are some serious reasons though. Results are traceable and the output has a time stamp. FDA statisticians can check what you get. It is very good for database management and it is reliable software. Of course many of the attributes of SAS can be argued to be present in other software packages including R and SAS is expensive. Still I think anyone wanting to be an applied statistician working in industry will be best off to at least learn how to program in SAS. Use R or STATA if you prefer but know SAS. When you work for a company that wants you to use SAS they will pay for the licensing.
answered Aug 6, 2012 at 18:53
-
4$\begingroup$ Here's some additional information on the FDA's thinking with regards to R: blog.revolutionanalytics.com/2012/06/fda-r-ok.html $\endgroup$ Aug 6, 2012 at 19:26
-
4$\begingroup$ The R Foundation published a paper in 2008 discussing the use of R in regulated clinical trials. It should be a good reference for collaborators who are skeptical of using R. $\endgroup$– jthetzelAug 6, 2012 at 19:52
-
2$\begingroup$ i agree that there is a move to use R more in clinical research and that many believe that R can be made every bit as traceable as SAS. $\endgroup$ Aug 6, 2012 at 21:12
-
6$\begingroup$ The FDA are quite vocal about NOT endorsing or requiring any one software to be used. It's historically true that most submission have used SAS, so the FDA have lots of SAS knowledge, but they have been very quick to embrace other systems, using R for quite a lot of recent work, especially around meta analysis. $\endgroup$ Aug 6, 2012 at 21:20
-
1$\begingroup$ @PaulHurleyuk What the FDA will say publicly and how they act in practice are not necessarily the same. Most pharma companies are primarily concerned with phase II and III clinical trials and they generally expect that they have to and will continue to need to use SAS for the analysis of those trials. $\endgroup$ Aug 6, 2012 at 21:32
$\begingroup$
$\endgroup$
I think this quote from Anne H. Milley sums up the way a lot of people feel about R:
We have customers who build engines for aircraft. I am happy they are not using freeware when I get on a jet.
Unfortunately, I think this misconception (free==inferior) is common in the general public.
$\begingroup$
$\endgroup$
3
(slightly off topic): viewing it the other point round: some of the advantages R has in academia don't apply to industry.
E.g. in academia it is a clear advantage if you can tell the students to go and get the software and work at home. In industry, you're usually not supposed to take any data home with you...
Neither are you supposed to try out a few things(TM), download tons of packages (even if reputable & tested), use cutting-edge methods. Instead you're usually expected to stick to methods & code that have been used for years and where the behaviour is known for ages. You wouldn't win much academic merits with that.
And of course, as has been mentioned: noone is going to risk redoing all kinds of regulatory approval for the sake of switching to R. From what I've seen that's less about R and more about the enormous costs + work for getting regulatory approval.
answered Aug 11, 2012 at 15:08
cbeleites unhappy with SXcbeleites unhappy with SX
37.4k3 gold badges77 silver badges142 bronze badges
-
3$\begingroup$ There is nothing that needs to be done to redo regulatory approval for the sake of switching to R. $\endgroup$ Aug 11, 2012 at 18:58
-
2$\begingroup$ @Frank: maybe we're thinking in different scenarios: I guess you're possibly thinking of a new trial (and there your're right) - I'm more thinking in terms of process analytics (chemical + statistical analysis) of ongoing production. AFAIK, you cannot just switch your data analysis there (but then, that's not SAS country) . But I may be wrong. $\endgroup$ Aug 11, 2012 at 19:18
-
2$\begingroup$ I'm not familiar with that world but I suspect that scientists have more freedom than they think. $\endgroup$ Aug 12, 2012 at 13:49
$\begingroup$
$\endgroup$
Whilst its quite pessimistic, my answer would be that the kind of people who make sweeping decisions in corporations like 'we just use SAS' are also the kind of people who don't trust what they don't understand, and automatically think the value of something is directly proportional to the amount of money you spend on it. This leads them to prefer paying for SAS rather than spend time investigating alternatives.
answered Aug 7, 2012 at 12:35
$\begingroup$
$\endgroup$
3
Why would a major drug company even want to convert to R from SAS? SAS costs millions but it is nothing to a drug company. However, converting all the stable reporting systems from SAS to R would cost 50-100 times more.
SAS has phenomenal support system: every time I needed help they were able to provide it within few hours.
And what exactly does R have that SAS does not: 1) better graphics...ok, it is a big one but graphics are not everything. besides R can always be used an extra tool to create some cool graphs and SAS is not too bad when it comes to graphics 2) modern and more efficient programming language. Many SAS users are not programmers and don't care about using a cool language. They just want to be able to analyze the data.
I love R but it would be insane for a big company to convert to SAS. It could make sense for smaller firms though
-
4$\begingroup$ Agree with you, @Max. Finally an answer coming from someone in the industry. It's EXPENSIVE to switch to R. $\endgroup$– DanMay 22, 2017 at 22:01
-
4$\begingroup$ That is false. The cost of programming support for SAS is much higher than that for R. Companies hire hoards of SAS programmers to make up for the archaic language SAS uses. $\endgroup$ Feb 4, 2019 at 13:17
-
$\begingroup$ I'm in industry and use both. R can perform data manipulations and, more importantly, analyses with far fewer lines, and hence can be developed much faster. I will say that some drug companies have thoroughly built out SAS systems for regulatory programming that have been successful. The point bears into consideration: why change (at this point)? If they were doing it from scratch, perhaps R instead. $\endgroup$– AdamOSep 24, 2019 at 17:08
$\begingroup$
$\endgroup$
2
There are several main advantages, in no particular order
- SAS has a large installed base and a long track record
I'm purposefully avoiding use of pejorative terms like "legacy" or "habit" Many companies have been using SAS for 30 or 40 years, and they have millions of lines of working code. In addition, there are all of the benefits of a stable code base with millions of user days in an area where small errors can be critical. This is the same reason that Unix flavors are still popular even though Unix is over 40 years old and obsolete in some ways. Finally, there is a large community of experienced SAS professionals who are used to solving business problems
- SAS is well suited to heterogeneous, complex data and operating environments
Companies have lots of different data sources, based in different types of systems, as well as in many cases, multiple operating environments. R has only very recently gotten some extremely basic capabilities to deal with more than can be kept in memory. Compare this with SAS's ability to support native, optimized, in-database processing for terradata, to cite just one example. In most real world situations, the hardest part of analytics is dealing with the data and operating environment. (need to run your Windows developed model scoring code on the mainframe? With SAS, no problem. With R, you are out of luck.) R doesn't solve any of those problems.
- The user doesn't have to worry about being "on their own"
A SAS user can be reasonably certain that every code module has been tested by qualified people. It is not necessary to devote time and effort to learning the provenance of the code, or independently validating it. Furthermore, if issues of any kind are encountered, robust assistance (from something as basic as documentation to something as comprehensive as detailed exploring unexpected results or behavior of a sophisticated method) the user can pick up the phone and get help.
- It's "good enough"
The language turns off some people because it is different than modern languages for general programming. Having said that, the language is high level, powerful, expressive, and comprehensive. In short, once you learn it, it gets the job done. For companies, the elegance of the solution isn't much of a selling point.
-
2$\begingroup$ Elegance maybe - but cost? I think companies care about that! $\endgroup$ Apr 10, 2014 at 22:25
-
2$\begingroup$ R can run on anything from a mobile phone to a supercomputer at zero cost, and a mainframe too, also at zero cost. $\endgroup$– SeanJan 29, 2016 at 19:01
$\begingroup$
$\endgroup$
4
Customer support.
I once had a chat with a friend working in a company specializing in installing servers, and he then explained to me why big companies always opt for Microsoft products rather than go open source. The advantage Microsoft has over its open source competitors is the customer support. If something goes wrong with the product, the company can call Microsoft, big companies even have personalized support for them. Not so with open source software.
I think that is the exact same reason SAS is getting precedence over R.
-
2
-
4$\begingroup$ I think these comments are not correct. In the server world, open source rules, and the Apache web server is the most popular web server. $\endgroup$ Aug 11, 2012 at 13:47
-
$\begingroup$ I never said he was talking about servers. Rather about products like Microsoft Office. I only mentioned that he is working in the server world. $\endgroup$ Aug 12, 2012 at 10:35
-
2$\begingroup$ Reminds me of companies that use a sharepoint and an open source wiki. Almost always the sharepoint is barren and only the wiki is updated. $\endgroup$– TLJDec 16, 2013 at 18:41
$\begingroup$
$\endgroup$
1
I once worked for a consulting company that gave SAS assistance to a large chip manufacturer in the Silicon Valley. Our contact person at the company told us that he got an offer by another company to give them the exact same consulting, by using a different software which covers all areas covered by SAS and which would cost the company a fraction of what SAS was charging them (\$30,000 as opposed to \$1,000,000). The contact person considered what to do and decided against informing his boss about the offer because he feared getting fired for using SAS in the first place and not considering cheaper alternatives. Instead, he insisted that our consulting company give their company a big break in our consulting fee. Our company agreed.
-
2$\begingroup$ So your contact person couldn't make the argument that R is still relatively newcompared to SAS, and he wanted to wait to make sure R was established before using it? $\endgroup$ Apr 10, 2014 at 22:22
$\begingroup$
$\endgroup$
7
What about Frontends? What is R's equivalent for the SAS Enterprise Guide, Web Report Studio or Enterprise Miner? Edit: These tools make it possible for a non-programming User to use a DATA WAREHOUSE, without knowledge about the underlying technology. They are not primarily tools for the use of SAS as such. R GUI's are just IDE's for the R language/system, AFAIK. They cannot provide help for the non-technical user who wants to gain information & insight from the DWH.
-
2$\begingroup$ It IS an answer. What makes SAS so valuable to customers (like us) is the ease of use for people who don't have to write a single line of code. $\endgroup$– KurtSep 3, 2013 at 14:29
-
2$\begingroup$ @Kurt, gung didn't want to mean that this is not an answer, but rather that your answer does not fit to this site (and especially for the present question, actually) $\endgroup$ Sep 3, 2013 at 17:28
-
$\begingroup$ There are tonnes of GUIs for R, see stats.stackexchange.com/questions/5292/… $\endgroup$ Sep 4, 2013 at 0:12
-
2$\begingroup$ Well, I have worked with RStudio. Compared to SAS Enterprise Guide, its still has a very long way to go until it reaches the ease-of-use for a newbie user. Add the fact that R is missing an equivalent to the Metadata Server. And I completely miss an out-of-the-box equivalent for WRS (maybe I'm blind :)). The beauty of a language and the productivity you can achieve means next to nothing for companies where 90% of the data warehouse "customers" couldn't write "Hello World" in any programming environment. That's what I wanted to point out, and that's where a lot of work is left to do. $\endgroup$– KurtSep 4, 2013 at 5:22
-
2$\begingroup$ Thank you for updating your answer, @Kurt. I think it will be more useful for future readers now. It is true that there are point & click, & data warehouse offerings for SAS that are more comprehensive, & ready-to-go out of the box than R. That is a reasonable point to raise. +1 $\endgroup$ Sep 6, 2013 at 17:32
$\begingroup$
$\endgroup$
3
I don't think application security has been mentioned. This question was raised in Stack Overflow but dropped since it was off topic.
I collaborate with the the Swedish National Board of Health and Welfare that use SAS. When I talked to their statisticians (that like R) they claim that their IT-folks prefer SAS since they don't trust the packages downloaded in R. My wife also works in SAS and her institution often claims the same issue...
I would love to see some comments on this issue. I've done a quick search but haven't found any good references...
answered Aug 11, 2012 at 12:51
-
3$\begingroup$ What is the alternative to downloading a package that provides new capabilities (as most R packages do)? Is it to home grow those capabilities? Is that more reliable? $\endgroup$ Aug 11, 2012 at 18:59
-
2$\begingroup$ @FrankHarrell I agree, but I think this may be an easy area for the R developers to target and improve. A simple solution could be different levels of security for packages - if a package has a system call or connects on its own to the Internet the package should have a higher clearance. This could allow installations with only low-level clearance in those institutions/companies where a data leakage is of major concern. I as a user could then also do an extra check when I choose to install a high clearance package. (Btw, when is your book (RMS ver 2) scheduled?) $\endgroup$ Aug 11, 2012 at 20:38
-
$\begingroup$ I'm hoping that the 2nd edition of RMS will be available in just over a year. $\endgroup$ Aug 12, 2012 at 13:48
$\begingroup$
$\endgroup$
The reason I understood to be the most convincing was that SAS has an extensive library of vertical business specific modules that people in these verticals all use, so it is somewhat of a lock-in.
But also that SAS has addressed the needs of these vertical segments in business and optimized around their needs - optimized in the sense of "user doesn't have to do a lot of extra work to get the results". I am not a SAS user, so this is not meant as a biased defense of the SAS business strategy.
$\begingroup$
$\endgroup$
1
Being the big commercial product that SAS is, there's a strong and coordinated effort by payed salespersons to promote it. I don't think that efforts to promote the usage of R can match these.
-
8$\begingroup$ Yes, people have to some extent discover R on their on. But much of the issue comes down to inertia of learning a new language. New languages are always coming out that have advantages over older languages yet users cling to the old languages (witness COBOL). Programming in SAS is hugely inefficient, requiring perhaps double the number of programmers to do the same job as R, but SAS experts are happy to hum along on their merry way and companies are afraid of the kind of disruption that would save them millions of dollars in salaries. $\endgroup$ Jan 8, 2013 at 13:33
$\begingroup$
$\endgroup$
4
I look at Open Source or licenced software like this, be it SAS or anything else. My IT department is there to provide a service to our business. The company earns no money from IT, only from the business IT supports. The business has annual revenues of \$16 Billion. IT costs around \$200 million a year. If money was the issue I would cut costs, but if I save 10% (\$20 million) of my budget, will the business notice? Will they just reduce my budget next year? If the IT fails the business loses revenue, how much will vary on the nature of the failure. Parts of the business may no longer earn revenue. If a product like SAS fails, I can sue under a contract. If an OSS product fails, I cannot. I will not recover my \$16 Billion, but I may get some back, and realistically with SAS, you are unlikely to lose the lot. The difference in price versus cost has to justify any additional perceived risk to the business. Sometimes it is cheaper to stick with SAS than to retrain. Sometimes there are higher priority issues, so companies stay with SAS. Some companies do not need the full functionality in which case alternatives are viable. Some do not need the support and again the alternatives are viable. If you meet the business requirements then either options are valid, if you want to provide support for a business you need to look at the total cost of ownership over 5-10 years, the ability to recruit experts in the tools, stability in the product so you don't have to rewrite everything with each new release, the training courses available to skill up, the size of the potential skills available in your region... Often the biggest problems with OSS come about through the poor architecture of the products, look at Linux when 64 bit processors came out, look today at MySQL was recently ported but without support for secondary indexes which is coming later...
-
4$\begingroup$ I don't follow your reasoning. The amount of money wasted paying programmers to program in an archaic language (SAS) vs. modern free languages is stunning. $\endgroup$ Apr 15, 2013 at 15:25
-
4$\begingroup$ @Frank - I have to disagree with your characterization. A competent SAS programmer can be highly productive in SAS, and competent SAS programmers are widely available. I grant you that R is structured more like a modern language, and so might be easier to learn for programmer who knows, say, Java. In my experience at many companies, developer productivity using SAS is rarely a material issue. $\endgroup$– JBKJun 9, 2013 at 22:21
-
9$\begingroup$ Having used SAS for 23 years and S-Plus/R for 22 years I can say that a highly experienced SAS programmer can be highly productive, but that an experienced R programmer can be easily three times as productive. $\endgroup$ Jun 10, 2013 at 3:18
-
2$\begingroup$ "I can sue under contract" haha - incorrect code written by employees is far more likely to cause problems than something SAS or R does "on its own" $\endgroup$ Apr 10, 2014 at 22:29
$\begingroup$
$\endgroup$
1
Some reasons that I haven't seen mentioned:
Better documentation. SAS documentation is verbose, R documentation is terse. Many companies may prefer verbose documentation.
Better error messages. R's error messages often seem designed to prove that the person writing the message is smarter than the person reading it.
Tech support. SAS has some of the best tech support I've run into anywhere, provided by SAS. You can get help with R, but that help is scattered over different places and isn't always available. The people on the various sites that provide help with R are volunteers - and volunteers aren't obligated to help. The people at SAS tech support are paid to do what they do - and they do it well. Not only do they do it well, they do it politely a trait that is often not present in all R communities (my favorite? "I got help by typing 'help', why don't you try typing 'help'?")
Ease of coordination with Word and Excel. Yes, I know you can get R to do this, but it's easier with SAS (on the other hand, R works better with $\LaTeX$ but a lot more companies use Word).
answered Feb 4, 2019 at 11:38
-
1$\begingroup$ I am sure there are companies that sell tech support for R. But how good that is I have no experience! $\endgroup$ Feb 4, 2019 at 12:37
$\begingroup$
$\endgroup$
I think the legacy angle can be a big one for the following reason. An organisation hires a person, call them person X. They are a computing guru/wizard/etc. They build awesome SAS programs/tools/etc. They are so good that other people in the organisation don't feel like they need to understand how the programs work. They make it so easy to just push a button, and everything just works (the magic black boxes).
Person X leaves the organisation. Unfortunately, the knowledge that person X has leaves the organisation (documentation and knowledge management was not prioritised, working programs was instead). They are replaced by person Y. Person Y is great with R but has no idea about SAS, and hence has no idea about how the SAS programs actually work. There is a huge learning curve to even figure out what needs to be translated into R. For example, person Y can not tell if a data transformation has been done to enable a proc to be called, or for merging with other data, etc. The transformations needed are probably different in R, because the functions are different, and the defaults are different (e.g. treatment of categorical variables in proc glm vs the lm()) So, you are now faced with a unequal cost trade off. Say the cost of re-writing / translating from SAS to R is $C_T$. We then need the (small?) efficiency gain from moving to R (I say small based on my experience with optimising SAS code and optimising R code for logistic regression predictions). This also needs to be compared to the license costs for SAS. It is likely that $C_T$ is significantly higher than a single year license for SAS. I expect that SAS would be doing some analysis of this trade off, and letting this influence how it sets the licence fee (well, I would if I worked at SAS). Also notice how SAS plotting procedures are way better than a decade or so ago (eg proc sgplot vs proc plot). coincidence that R did good plotting first? I think not! This effectively reduces the efficiency from switching because plotting is not so different anymore - R is still better, but not by enough to switch...
answered Apr 27, 2019 at 9:32
$\begingroup$
$\endgroup$
For industrial statistics, there are quality assurance people who (usually) have no programming, statistics, or science background and who audit statisticians, programmers, and scientists. They want to know, "How do you know that what you're doing is right?" and "If it's wrong, how can we blame somebody and how will they pay for it?".
The GNU/GPL Copyleft license comes with canned text that says, "R is free software and COMES WITH ABSOLUTELY NO WARRANTY" in all-caps text exactly as I have written. This is offputting. When a quality person reads this text, they basically discredit R outright. I mean, if a product is good, it's worth adding a warranty right? Such has commercial products led us to believe. In fact, it was ultimately the FDA who said they would accept regulatory submissions in R that reflected a seachange in the software industry. (Note this statement comes after the original posting date of the question.)
For someone who knows nothing about computers, the imagined scenarios of security, irreproducibility, and grave scientific errors are unbounded as a result of this ABSOLUTELY LACK OF WARRANTY. We all agree mistakes can have catastrophic costs. For your SAS license, SAS has experts who can explain their software to auditors, and in the impossible scenario that SAS actually causes such an issue, they can be accountable for fines and punishments (they also have enough money for lawyers to ensure they'd be exonerated completely in such a case). The burden and cost of having an analyst/programmer present this case for R basically amounts to a SAS license. Not that programming in SAS completely exonerates you from the crushing burden of quality compliance!
So basically, I would say litigiousness has played a prominent role in necessitating a costly license software.
