I learned R but it seems that companies are much more interested in SAS experience. What are the advantages of SAS over R?
|
|
I think there are several issues (in ascending order of possible validity):
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. |
|||||||||||||||||||||
|
|
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 :) |
|||||
|
|
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. |
|||||||||||||
|
|
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. |
|||||||||||||||||
|
|
Nobody has suggested the reason it is preferred is plain idiocy. Here's two quotes I recently came across: and
Two minutes with these people would show them how wrong they are. |
|||||||||||||||||||||
|
|
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:
|
|||||||||||||||||||
|
|
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. |
|||||||||||||||||||
|
|
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. |
|||
|
|
|
I think this quote from Anne H. Milley sums up the way a lot of people feel about R:
Unfortunately, I think this misconception (free==inferior) is common in the general public. |
||||
|
|
|
(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. |
|||||||||||
|
|
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. |
|||||
|
|
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. |
|||
|
|
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. |
|||||||||||
|
|
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. |
|||
|
|
|
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... |
|||||||||||
|
|
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 |
|||
|
|
|
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. |
|||||
|
|
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. |
||||
|
|
|
There are several main advantages, in no particular order
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
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.
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.
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. |
|||
|
|
|
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... |
|||||
|
