苹果经常喜欢用“Reinvent”这个词，用在硬件领域确实高大上。但在软件领域Reinvent大多时候是个贬义词，软件领域上下游结合及相互依赖非常紧密，没有哪个团队甚至公司能封闭的完成所有事情。因此重新发明这件事情在软件领域并不吃香，一个新的体系在小的团队通常会自生自灭（尽管途中可以获得一些荣誉），剩下那些硬撑的项目则会让参与人员痛苦不堪。
比如各厂定制的各种百花齐放的框架，运作几年之后，核心系统越来越臃肿，随着人员的更替能深入了解内部的人也越来越少，改进的动作非常迟钝。但大量的上下游业务服务又需要依赖这些系统，新来的人需要较高的成本熟悉整套系统。问题丛生，但是离开又需要付出极大代价，于是就成了一个鸡肋。如果使用方牵涉到多个部门，更不会有人站起来说将这些定制系统废弃或迁移。
但这个现象在计算机语言领域则是一个例外。一门新的语言，不喜欢的人可以不用，而且大部分开发团队是随大流，不会选用小众语言，所以新语言领域已经在搭建的哪些不成熟的系统也不会给业界带来麻烦及痛苦。少量情况下，极客会心爱的小众语言搭建的一些系统，但根据观察，这些系统通常会随着极客的离职马上会被用主流语言重写替换。因此在新语言领域，可以用更轻松的心态去重新发明各种组件。
一门语言出来之后，复用另外一种语言的模块与组件不是最佳方案，理想情况会选择构建自己的函数库，框架，开发工具，测试工具，代码工具，性能调优工具等。在新的语言出来的早期，这些领域一片空白，踏入这片领域的人会有新大陆淘金的感觉，随便写点东西，很快可以找到市场。
在一个新的语言重写一些别的语言已经完成的项目，尽管这不是什么伟大的发明创造，但参与的人往往更快的取得了成绩并且赢得了尊敬（相对于在“主流”语言拼搏那些人）。我也曾经思考过这个现象。技术人的价值观虽然很多元化，但是有两点却几乎是共通的，一是工程师动手创造带来的成就感，二是感受创造的东西给所在环境以及业界带来使用价值的成就感，不管这些创造是原创的还是山寨。因此在很多领域如搜索、广告以及更基础层面OS、Database、Language总是有乐此不疲工程师重新去建设，因此在语言层面的重新建设就变得容易理解了。
更深层次的来看，在语言层面的基础上，重新去构建一个生态圈，从社区的角度，不只是重新克隆一个新的版本，工程师会考虑以往的经验及教训，重新设计重要的单元，以带来性能上的提升及使用方式上的改进。比如这几天写一个Go语言的小程序，看到Go的社区在配置文件方面的思考及重新选择。配置管理在Java领域大多是XML一统天下，尽管其可维护性较差，但由于历史原因，工程师很难去另起炉灶。
当然在新OS领域重新创造的机会就更多，但是这种情况较少发生，一个新的OS生命周期会延续10年或更久。一些大公司的开发平台生态圈也有类似的这样的机会，不过大部分情况下格局会小很多，也会存在更大的不确定性。
