我认为有几个问题（按可能有效性的升序排列）：

1. 传统/习惯：人们习惯了 SAS，不想学习新东西。（更困难的是，您在 SAS 和 R 中的思考方式不同。）这适用于可能需要向您发送代码或阅读/使用您的代码的任何人，包括经理和同事。
2. 对免费软件的不信任：我有几个人说他们不愿意接受 R 的结果，因为你没有一家营利性公司审查代码以确保它在提供给客户之前给出正确的结果，以免他们最终失去生意。
3. 大数据：R 对内存中的所有内容执行操作，而 SAS 则不一定。因此，如果您的数据接近您的内存限制，就会出现问题。

就我个人而言，我只认为#3 有任何合理的优点，尽管已经用 R 开发了一些处理大数据的方法。#1 的问题不言自明。我认为#2 忽略了几个事实：对 R 进行了一些审查，许多主要软件包都是由一些统计学界大腕编写的，并且有研究比较了不同统计软件的准确性和 R当然是有竞争力的。

除了到目前为止的好答案之外，我还要添加尴尬因素。如果您去年在 SAS 和 SAS 支持上花费了数十万美元，并且您建议不为 R 花费任何费用，并且支持价格极低（Revolution 等），那么链条上的某个人会问为什么。去年 R 存在时，去年花这么多钱是不是一个错误？或者为了一群志愿者创建的东西放弃专业软件是错误的？

一旦以这种方式提出问题，这是一个双输的提议，所以最好不要提出它。

除了 gung 正确识别的内容之外在这里正确识别的内容之外，企业界最大的问题是遗产。而且，当您拥有已知可以完成这项工作的优质生产代码时，您无需更改它。SAS 自 1970 年代就出现了，在当时，按照当时的标准，它是唯一有效的脚本统计语言。从那时起，SAS 在制药和政府中积累的生产代码量是难以想象的，数以万计的人类年。用 R 或 Stata 重写这需要几年时间，生成的代码将变得更灵活、更高效、更透明、更容易维护且更便宜，但没有人会为这种重构付费。（我这样做的经验是，我的 Stata 代码通常缩短了大约三倍；我曾经有一个项目将 SPSS 代码转换为 Stata，我把它缩短了大约 20 倍。

从某种意义上说，这与学术出版商的情况类似：他们正乘着最终用户出于必要而维护订阅的潮流；没有订阅 Nature 的大学并不是真正的大学。通过专业协会的免费出版将使其更便宜，现在人们用 LaTeX 准备他们的提交，所以他们准备好了，同样的人将提供同行评审，所以在任何方面都不会出现质量挫折。但是……在线期刊背后没有品牌名称和影响因子。

这总结了一切：http ://scatter.wordpress.com/2011/06/28/stata-12/ 。Stata在经济学和政策相关的圈子里是首选，我越学SAS越喜欢Stata。

在过去的七年里，我一直是一名高效的 SAS 程序员，在我旁边的一位同事编写 SAS 的时间比我在世的时间还要长。如此处所述，SAS 背后存在大量惯性/遗留问题。但是 SAS 就像 R 一样是一种手段，而不是手段本身。

SAS 在顺序数据访问方面非常高效，并且通过 SQL 访问数据库的集成度非常好。PROC 有很好的文档记录，但遗憾的是没有完全用符号标准化（PROC OPTMODEL 和 IML 是两个例子）。编写复杂代码时有点笨拙，而并行代码则没有那么优雅。我还发现导入 csv 文件有时会带来极大的痛苦，我更喜欢先将其转储到 R 中，然后再转储到数据库中。

尽管 SAS 确实具有共享对象和 dll 的接口，但您无法很好地访问任何头文件或类似的东西，并且代码分发也不能通过快乐的包提供。

然而，很少有人担心有人在您现在需要维护的代码中包含一些现在已经失效或损坏的包，并且 SAS 中的代码质量往往都非常出色（R 核心代码也非常出色，而且也很自由任何人都可以使用）。

如前所述，SAS 也非常昂贵，但当我知道有一个罐装程序可以很好地满足我的需求时，它是一个很好的工具。

R + SAS + mysql 加上一点 perl 将它们粘合在一起，效果惊人:)