The article says this particular instance of the debate started in 2011. Things have shifted a little since then, and I think Python has won more mindshare with Pandas, SciPy, NumPy, and all the rest. I've used both Python and R, and think the next debate will be between those two, as people find that R is not a very good programming language and lacks decent libraries for things like web scraping.<p>Python can be a single tool that integrates with every part of your workflow. R right now still wins in the number of algorithms implemented in it (there are statistical methods not available in R but not Python), and R has more terse syntax which some people like for interactive use. But for really Big Data, terse syntax and an endless variety of esoteric algorithms are not as important as, say, robust error handling and debugging (a weak area in R, but a strong one in Python).
I use of both Python (pandas) and base SAS at work for UK government.<p>I have lots of experience in SAS, and enjoy using it. The macro language allows for very succinct solutions to difficult data manipulation problems.<p>However, given SAS's huge expense it's difficult for me to identify any 'killer' areas where it's significantly better than open source tools. Indeed, I find pandas faster and easier to use for many problems.<p>I find it hugely frustrating that the government pays so much money for SAS licences and training when most people use it for simple use cases, where they would be better picking up transferable skills (e.g. Python, SQL, R).<p>My understanding is that that SAS supposed to be good at processing very large datasets because it uses RAM efficiently (only the PDV is stored in RAM). But in reality, a small minority of users are processing datasets that are too big for RAM (e.g. 16gb+) and there are probably better tools for the job in this use case.<p>One user here comments that SAS is like an 'improved Excel'. In fact, I find pandas much closer to Excel than SAS because (in ipython notebook at least), you get nice visual representations of your tables, and it usually isn't difficult to translate an Excel operation into a pandas one. I especially like the multi-index and pivot table based capabilities. With a background in VBA for Excel, it's also relatively easy to pick up Python.<p>None of this is quite so obvious in SAS, which has quite an unusual data step and macro programming language. It's very powerful, but is quite unintuitive to begin with due to a complete reliance on the program data vector.
My company uses R, Shiny, and Rserve for nearly <i>everything</i>. R is a great programing language - if you need to quickly and efficiently develop stat's based features for medium sized data.<p>R excels (get it?) at creating reproducible, fault tolerant, consistent functions that can be automated, packaged, applied to a variety of data types, and then extended later.<p>Our web-stack is Shiny on AWS and we call our API's built in R (ML, images, data, etc) from Android using Rserve.<p>A lot of the (programing?) criticisms of R will be 'solved' or become non-issues in the next few years. Multithreading, implicit vectorization, better memory handling, gpu functions, among other things are all in the pipe :)
(That said, the syntax _is_ a little weird to get use to)<p>-----<p>* We're hiring for very senior positions in data-science and more general R programers. Contact me if you're interested (JasonCEC [at] Gastrograph.com)<p>[edited for spelling]
The problem with R is that it's just not a very good programming language. It's great for interactive analysis, but dismal for building higher level abstractions. It's like the PHP or MySQL of the data analysis world. Data types get magically converted all over the place, the global namespace is just a giant playground for every module to pollute, it has something like 5 different object systems all with subtle differences. All the defaults that are set for the convenience of interactive use undermine any kind of reliable use for building on as a platform (for example, the "simplification" concept where a 1 column data frame often magically turns into a vector).<p>I've forced myself to use R intensively for a couple of years now, but I must say it's still a relief every time I bail out and get back to a "real" programming language.
My favorite part about the SAS v R debate was the conclusion of this article:
<a href="http://bits.blogs.nytimes.com/2009/02/16/sas-warms-to-open-source-one-letter-at-a-time/" rel="nofollow">http://bits.blogs.nytimes.com/2009/02/16/sas-warms-to-open-s...</a><p>"""In the article, Ms. Milley said, “I think it addresses a niche market for high-end data analysts that want free, readily available code. We have customers who build engines for aircraft. I am happy they are not using freeware when I get on a jet.”<p>To her credit, Ms. Milley addressed some of the critical comments head-on in a subsequent blog post."""<p>(Boeing uses R heavily and when you fly on their aircraft, you're flying on open source)
Since SAS is a relatively simple language, why can't someone just write a transcompiler that supports a subset of SAS and move it to R? That way you have the best of both worlds (sort of).<p>The most difficult thing about that is how you would treat "by" statements (SAS) vs the split-apply-combine (R).<p>Self-plug: I sort of made a quick hack about a month ago for SAS-Python, I'm sure someone with more programming experience than me
could produce something much better (I come from a maths background).<p><a href="http://nbviewer.ipython.org/gist/chappers/8747253/stan_example.ipynb" rel="nofollow">http://nbviewer.ipython.org/gist/chappers/8747253/stan_examp...</a>
<a href="https://github.com/chappers/Stan" rel="nofollow">https://github.com/chappers/Stan</a>
I used to work for one of the largest U.S insurance companies. They were always behind in transitioning to new technology (Excel 2003 could be found there in 2013). That being said, the entire staistical modeling team and research department made the switch to R and Python. Only a few clung to SAS but realized they would be forced to move to R as any collabration would need to be converted to R and not to SAS.<p>I believe it will be R verus Python future and SAS will not be a part of it.
These people:<p><a href="http://www.teamwpc.co.uk/" rel="nofollow">http://www.teamwpc.co.uk/</a><p>produce a compiler, tools etc that run the language of SAS.<p>(disclaimer: I interviewed there last year)
Is this even a discussion? Anyone serious about analyzing data will use either R, Python (with Pandas/SciPy, etc), or Julia. For truly immense data sets that require pipelines, you'll use tools like spark, hadoop, etc - but SAS is basically a slightly improved excel.