谈一谈编程语言对行为的影响
本博到现在为止也没正经的说过和讨论编程语言的对比之类的，因为这一方面可能会引来各个派系的圣战，另一方面自觉才疏学浅，也没有这个资历说三道四，但是有时候也会有点小想法。比如我下面要说的：
本文先由leetcode的一道easy类别的题引出count and say。 大意就是给定以个1<=n<=30，要你解出一个字符串，规则就是去数上一个字符串的规律，比如：
1. 1
2. 11
3. 21
4. 1211
5. 111221
第一行是1，就是1个1，所以第二行就写11（前面的1是个数，后面的1是出现的数字），而11本身是2个1组成，所以第三行应该是21，同理第四行就是1211（1个2，1个1），第五行就是111221，由此类推… 其实这道题呢，个人觉得并不是那么的简单(可以先忽略一下的讨论，先尝试自己去解一下)，尤其是你并不非常熟知各种数据结构的相应的方法的时候，想有效的解出来并不那么easy。但是，对了但是来了！我用ruby就不一样了。请直接看ruby解法：
def count_and_say(n, m='1')
return m if n==1
m = m.to_s.chars.slice_when{|a,b| a != b }.reduce(''){|sum,i| sum + i.size.to_s + i[0]}
n -= 1
count_and_say(n, m)
end
对了，可以看出，ruby核心解法就是一行代码，这里利用了递归的形式来求解第n个值，因为n是依赖于n-1的，所以很容易就想到递归。 那么这里的核心方法就是slice_when这个方法。这个方法有什么用呢？字面上可以看出来，当某某情况下进行slice，不懂的人也可以看出，这里就是当a!=b的情况下进行slice。再举个官方的例子好了:
a = [1,2,4,9,10,11,12,15,16,19,20,21]
b = a.slice_when {|i, j| i+1 != j }
p b.to_a #=> [[1, 2], [4], [9, 10, 11, 12], [15, 16], [19, 20, 21]]
i,j代表着数组相邻的两个元素，也就是说当相邻的两个元素满足特定情况时就把他们slice在一起。所以2+1 != 4，那么2和4就被分开了，而1+1 == 2，那么1和2就被slice在一起了。 这个slice_when方法简直就是完美符合此题啊，只要把相同的元素slice在一起不就完事了？比如 1211先转变成数组[1,2,1,1]，然后按照slice_when的方法分类成[[1],[2],[1,1]]这不就解完了吗？[[1],[2],[1,1]]里面既有个数，又有元素换成人话就是[[1个1],[1个2],[2个1]],合并一下111221，也就是n=5的解了
好了，到这里这道题也就解完了。也完美的accept了，速度虽然不是最快，但是内存超越了100%的其他解。
思索
如果在这里就完事的话，可能这也就是一道普通easy题的命运了。但是仔细想想呢？感觉虽然解法很巧妙，但是这都是依赖于语言本身特有的方便性上面，也就是说我都是依赖于有slice_when这个巧妙的方法，内置的方法一般底层都是静态语言编写的，所以速度上能够有一定的保障，所以我可以直接调用它。所以，在寻求解决方案的时候，正是因为我熟悉这个语言，我知道这个方法，我知道这个方法能够用来解决这个问题，所以，我的思想上就偷懒了，我并没有寻求自己利用简单的结构去设计一个方案，而且直接利用了现成的工具就把去调用它了。但是如果没有这个方法呢？比如python，并不是说python不能这样实现，而是我本人对于python肯定没有ruby这么熟悉，ruby我可以很快的就知道能利用这个方法去实现，而python我还得去搜相应的文档或者api，也就是说我的思维就认定了如果我用python去解这道题，我觉得我是可以按照ruby的这种方式去解的，而且我大概率也是可能就是按照我想的这种方式去解。但实际上，我去看了其他的解法，我发现，基本上别人的解法很多都是利用最基本的数据和方法，只不过多了一些逻辑判断，从而利用在资源或者计算上能够一定程度的得到优化。
所以，怎么说呢，从编程语言上谈直观的一些感受就是。比如ruby，我用它用的越久，我的技能会越来越熟练，我的效率会越来越高，相同的事情，可能我会更加快速、效率、优雅的去完成，当然任何一门语言以上形容都可适用。但是经过自己的亲身体会就是，越来越多的功能模块都被集成化，简单化，哪怕小到最小的函数，方法都不需要你再去造轮子了，你只需去熟悉语言自身就行，在抽象的逻辑，设计，思考方面只会越来越萎缩。我个人对这方面还是有所担心的，担心自己只会越来越依赖于语言本身，从而忽略掉了自身的抽象思维逻辑。
但是，正所谓动态语言一时爽，一直用一直爽。这也是大势所趋，在工作压力越来越大的同时，任务越来越不可思议同时，优雅的挥一挥手就完成了任务，是每个人都无法避免的诱惑。毕竟，谁不也想用C语言写几百行代码去实现一个用其他语言几行就可以搞定的正则表达。
所以，我还是会要求自己，在实现功能以后要去多想想为什么这样实现，能不能换个其他方式实现，不同方式能有多大区别等等问题，虽然不一定真的要去做，但是这样真的是可以一定程度上从语言的坑里慢慢爬出来，尽量不要成为某种语言的奴隶了，把你的思想给束缚住了！