在电气电子工程师学会（IEEE）发布的2016年编程语言排行榜中，R语言已经冲到了第五名，仅次于C、Java、Python 和 C++。R语言的流行，大致是与数据科学的兴起有关。用R来分析数据，成了一件很时髦的事情。
我在R语言及其前身S-Plus里面摸爬滚打了多年，却一点也不喜欢，因为R语言有许多令我忍无可忍的脑残设计。在本文里，我举两个例子，展示冰山一角。
例1：自作聪明的序列产生器
不少编程语言里，都有序列产生器，例如：
- Haskell 中
[3..7]的计算结果是[3,4,5,6,7]。而[7..3]的结果是空表[]。 - Matlab 与 Haskell 的行为类似，
3:7的计算结果是3 4 5 6 7。7:3的结果是空矩阵Empty matrix: 1-by-0。 - Python 中采取 Dijkstra 惯例，整数区间不包含上界本身。于是
range(3,7)的计算结果是[3,4,5,6]。而range(7,3)的结果与前两种语言类似，是空表[]。
现在R登场了！
3:7
得到
3 4 5 6 7
这个还正常。现在，倒过来……
7:3
R竟然“聪明”地给出了一个倒序的向量！
7 6 5 4 3
在R里摸爬滚打了许多年，我浅薄地认为，这种标新立异其实是个大坑！
下面，我们做一个程序，列出 “从1、2、3、4这四个数中，取出任意两数” 的所有方案。为了描述清晰，我先用 MATLAB 做出一个版本：
for i=1:4
for j=(i+1):4
fprintf('%d %d\n', i, j);
end
end
计算结果是：
1 2
1 3
1 4
2 3
2 4
3 4
下面我们将MATLAB版本直译成R语言：
for (i in 1:4) {
for (j in (i+1):4)
print (c(i, j))
}
我们希望得到类似MATLAB版本的输出，然而，R的计算结果令人发指：
[1] 1 2
[1] 1 3
[1] 1 4
[1] 2 3
[1] 2 4
[1] 3 4
[1] 4 5
[1] 4 4
这个结果让人一时摸不着头脑。在上面的结果中，前面六行没有问题，但第七行也太离谱了！根据正常的逻辑，j的最大值无论如何也就是4，为何会产生5呢？这就是因为R的序列产生器自作聪明！
这个问题的重点是，当i=4的时候，j的范围到底是什么。包括MATLAB在内的正常语言，都会认定此时j的范围是空集，从5到4产生一个序列，下界比上界大，当然是空集咯！但是R偏偏不这么想，它说，下界比上界大，那么我们产生一个逆向的序列吧：5,4。于是，就有了第七和第八行这两对多余的答案。
这里，一定有人说，博主SB，把 for (i in 1:4) 写成 for (i in 1:3) 避免下界比上界大的情况，不就把这坑绕过去了吗？我不想这么做，因为语言是拿来用的，不是拿来练习“绕坑”的！
例2：神奇的等号与箭头
先做个变量 x ，赋值为0。然后，我们来玩一个简单的“比大小”的游戏，比较 x 和 -1 的大小。具体而言，做一个if表达式，完成以下逻辑：
- 如果 x 小于 -1，取值为“躲”
- 否则取值为“策”
稍有常识的观众都知道 0 比 -1 大，所以当x=0时，这个if表达式的值应该是“策”。那我们拭目以待：
x=0
if (x<-1) "躲" else "策"
在R里面执行一下，结果是
"躲"
有一定经验的读者或许已经发现问题了。我来班门弄斧，仔细拆解一下。在解释这一行程序的时候，R完成了一系列动作：
- 把
<-合在一起当成赋值操作。 - 把 x 赋值为 1。
- “赋值”这一操作给出一个值：1。
- 把数值1当作“逻辑真”代入
if表达式，条件满足了：“躲”。
这里，一定有人说，博主SB，专写有歧义的表达式，如果在 -1 之前加个空格：
if (x< -1) "躲" else "策"
不就把这坑绕过去了吗？我还是不想这么做，因为语言是拿来用的，不是拿来练习“绕坑”的！
关于这种设计，我想说几句：
“赋值”这个操作，作为一种动作，还是没有值比较好。在没有上下文的情况下，给“动作”定一个值，是一件反自然、反人类的事情。比如，“伞哥把我打了一顿” 这个动作的值是什么，是“爽”还是“疼”呢？在以上的
if表达式中，x<-1就有个值。根据R的文档，x<-1的值，与赋值后的 x 一样，在这里是 1，这种行为与C语言的赋值语句类似。之后，这个值1，虽然是一个数，却被if拿去强行当成“逻辑真”，这又与C语言的逻辑机制类似。R没学到C语言的高效率，却继承了一大堆糟粕。如果R分不清我是要“赋值”，还是要“比大小”，至少应该给我个提示，让我自行确认吧。无论是什么语言，在
if表达式的条件里做“赋值”是很罕见的事情。在这个例子中，x<-1就是if表达式的条件，但R解释器对这种罕见的情况熟视无睹。相比之下，C语言虽有“赋值语句带值”的坑，而C的编译器却往往有不错的检查机制。许多学过C语言的朋友，都曾不小心写出过类似
if (x = 1) {
...
} else {
...
}
的结构。在这种情况下，一个负责任的C编译器会警告说lvalue异常。看到这种警告，合格的C程序员都会再次确认，到底是要写 x = 1 还是 x == 1。然而，C编译器的警告功能，R解释器却没学到：完全无视上文的 if，不报错，不给出任何提示，一意孤行。在这种情况下，再狡猾的程序员，也躲不过好 bug 啊！
- 以上的例子中，程序员看到值不对，可以迅速排错。然而，错误的程序能有时能产生正确的结果。例如，把刚才的需求调整一下：现在，如果 x 小于 -1，取值为“策”，否则取值为“躲”。取
x=-2，有 bug 的程序如下：
x=-2
if (x<-1) "策" else "躲"
这样一来，只要一运行，就得到
"策"
这个结果是符合需求的，然而程序完全错误！表达式给出的这个“策”，不是因为“x 小于 -1”，而是因为“x被赋值成1，且1被当成逻辑真”。这样一来，错误的程序弄出了看起来正确的结果，这使得调试非常困难。如果成千上万行程序中藏了个类似的错误，一时通过了测试，直到项目交付之后才爆出问题，就更麻烦了。
结语
编程语言，不是谁都能设计的。稍有不慎，就会制造许多“坑”，甚至还会把某些“坑”当做“特性”。R这种东西，拿来当绘图工具或是计算器倒是可行，却也不是必须的。若要拿它做重要的事情，最好再三考虑。写到这里，我已将R卸载了。
