导言：
今晚吃饭和媳妇打趣，她把青芒、梨子、桃子几种水果混合在一起榨汁，解决了冰箱里水果濒临吃不完的问题，我来了一句：这些水果通过进化，好不容易才变成不一样的物种，你又给它们混合回去了。
达尔文的物种进化理论中有一个重要命题，就是"物种没有过渡形态，只有最终形态，因为亲代会消亡，子代会更加分化"。这个观点大方向很好，细节有待商榷。
1 过渡形态在哪儿？
按照我的理解， 过渡形态无处不在，只是因为在历史的长河中我们对过渡形态和稳定形态的观测频率一样，才造成了一定的采样偏差。
先说说采样偏差。我们人类是不是最终形态？现代人类几千年的文明历史在地球的历史长河里几乎是观测不到的（如果200年后我们就灭绝了的话）再比如一个主要依靠打车来运输乘客的交通系统，遵循排队理论，如果你在街边有很多人打不到车，你能说这个城市较大比例的打车需求无法满足吗？不是的，因为你并不能看见那些能迅速打到车的人，他们已经在路上了！
我们就是如此容易忽略过度形态，这种忽略是不公平的。站在任何一个时间截面上，过渡形态都会以某种非0概率存在，而不是我们常常说的"只有最终形态"。这种进化是持续演进的，而不会是一蹴而就的，过渡形态一直存在于它们应该存在的时空中，而且在那个时间点甚至并没有显现出"它们是过度形态"这一征兆。也许是偶然事件推动，也许是环境影响，过渡形态才会重新分化、进化，以至于使自己的形态最终灭失。
听上去有点可惜，然而抱着不求天长地久，只求曾经拥有的态度，倒是也能淡定一些了。
2 关于数据挖掘工程师的进化
我听过一个比较有意思的观点，来自于某位互联网猎头顾问：
"外包公司的人的痛往往在于没办法在迭代中进步，做事情长期处于entry level会越来越水；而BAT人的痛往往在于N多年永远是某个特殊岗位上的螺丝钉，逐渐精深做的很好，然而转岗跳槽选择都很少。"
这其实是在讲两个生态环境中的两种成熟的物种。
前者的程序员更擅长做数据的单纯开环而非闭环，至于效果、验证、优化，这种东西完全取决于项目人员的节操。受制于项目成本、甲方的水平，实在是没有办法在平均意义上做的太有水准，甚至连优化迭代这件事的重要性提都不提：即然做完了为什么不直接拿钱走人呢？这种不负责任到底的心态是甲乙双方没有共同利益点的机制使然，半吊子的项目以及残酷的竞标环境，最终带来的，绝大多数情况下导致的是令人遗憾的劣币驱逐良币。
后者的程序员更擅长做数据的单纯闭环：在组织架构分工明确、交接流畅的前提下，每个人都有自己负责的那"一小撮"，只需要担心在数据pipeline路径上，数据输入方是什么状态，数据输出方是什么状态，进而如何影响下一次输入方的数据就可以了。不管是单纯的日志处理，数据仓库搭建，还是使用数据挖掘模型作出预测，从方法论到工具集基本都是套路，也不太需要创造性思维也能把成果稳定一点点提高，因此也会陷入这种模式：人变成了架构、变成了kpi的奴隶，比如预测／有监督学习问题中出现百万、上亿特征而不追求降维、模式研究本身就是一种畸形，这种畸形是"预测准确率就是一切"这种思路带来的，而且还使人前赴后继进行日复一日的重复劳动。
以上两点说的是某种意义上的最终形态。尽管"存在即合理"，但是容易发出怨言的人并不只是负能量的制造机，因为那些人能看到最终形态并不是对于个人而言的最优形态。人有更优而不得，才会产生负能量。对于对于成熟物种的强烈不满，会把人导向另外一条进化道路，这些人会勇于在合适的创业公司中把自己变成过渡形态：他们在新业务数据探索和研究方向上的动机以及实践，与其说是适应环境，还不如说是不满意环境，希望构建一个新环境，然后把自己放在环境里静待进化。尽管这一小撮人的状态对于以上两种人而言像是过渡形态，但也可以反过来想：他们追求并构建的公司数据文化，跟前两种公司的数据文化相比，搞不好还更接近最终形态呢！
3 关于数据科学程序语言的进化
刚才提到，个人会进化，公司文化也会进化，它们虽然形成了层级结构，但是进化的规律如出一辙。这让我不禁再往前思考了一步：公司文化这种抽象的鬼东西到底是什么？公司毕竟是由人组成的，你说公司文化是由ceo／创始人决定的未免太过武断了，从统计物理视角来讲，不如说是"每一个加盟公司的求同存异的个体所形成系统的最低势能点"。
把个人－公司文化这种关系进行类比，我比较有兴趣聊聊一组类似的关系：数据科学程序语言－数据科学派别。
第一类派别就是研究派。就像人会依附公司一样，Julia，R，SAS这种交互式数据研究语言也会寻求对Python生态圈中jupyter notebook的依附，这就很尴尬了，jupyter何德何能让性能的追逐者、追求省钱的学院派、老牌统计分析师一起依附过来呢？也许你会说这玩意的重点在于，研究派人员对数据的交互式探索特别喜爱，因为他们能从数据中获得令人惊讶、惊喜、百思而最终得其解的洞察。这一点说穿了，那就是"让人从dont know how to analyze走向know how to analyze"。数据驱动的意思就是一份数据一个样，A公司今年的经验未必适合于B公司，也未必适合A公司明年的情况——这就主要讲究一个开脑洞获得意外惊喜，因为直到最后一刻，分析师们也许都不知道数据里面究竟包含了怎样的奥妙。
第二类派别是工程派。这里就得借用一个概念了：Domain Specific Language。这是一种粗放的概念，意思是『在某个领域内，使用特殊的约定，使代码完成指定的工作』。不论是SQL，Regular Expression这种粗暴奔放的工具，还是Functional Programming实现数据管线、流式处理，或者是tensorflow、keras这种高度封装的api实现神经网络的构建（如果你们熟悉pylearn2的话也许还记得yaml一样可以定义网络），甚至是openblas，atlas，intel mkl这种矩阵计算工具，这种语言、工具的出现都在说明一件事：我们离不开高级抽象。我们最重要的目标，就是把know how to do交给其他人并忘记，转而执行define what to do。在容易抽象的环节，程序总是扮演着节省人类生命而非浪费人类生命的角色，那么define what to do就相当于是这种抽象，用来define的工具就是人类和人类之间达成的协议。（至于计算机领域所说的protocol，我看它们在某种意义上甚至可以称得上是标准了，因为节省沟通成本，所以全人类都用一种协议，就变成了标准）在工程方面，一个高效执行的pipeline一定离不开以上提到的所有接近进化完全的技能点。它能够同时满足两点：编码效率极高，以及执行效率接近最优。
因此我的个人意见是，以上两派数据科学工具最终形成派别。
结语
本文纯属胡思乱想系列，说是知识言过其实，不如说成是我自己的偏见，仅供参考。
