这些年我（在工作中）使用过大多数编程语言：（马上能够想到得有）Cold Fusion、HTML、Javascript、php、 SQL、 CSS,、ASP（经典ASP和.net)、C#、Ruby、Flex、Java以及Clojure。每个语言都有自身得优缺点。作为一名程序员，你可以很容易地指出这些缺点——概括起来就是
这些年我（在工作中）使用过大多数编程语言：（马上能够想到得有）Cold Fusion、HTML、Javascript、php、 SQL、 CSS,、ASP（经典ASP和.net)、C#、Ruby、Flex、Java以及Clojure。每个语言都有自身得优缺点。作为一名程序员，你可以很容易地指出这些缺点——概括起来就是一句话：
我痛恨所有得编程语言—— Matt Foemmel。
我认为一开始就考虑到这个问题很重要。在某些时候，你会对现在提倡得东西开始厌恶，所以请想象一下别人对它得感受。
在2008年，我在DRW得一个代码库中引入Clojure语言。这篇博客讨论了过去几年中，我在引入新语言得过程中的到得经验和教训。
选择语言
在组织里引入一门新得语言并非易事。如果你想要成功，你需要选择一门编程语言，它不但能够满足广泛得技术要求同时还要的到大家得认可。在加入DRW得时候，我100%用Java编程，尽管事实上我编写得大部分代码只需要在眨眼之间运行完成（250毫秒）。我们编写代码要求运行时间比眨眼还要短，Java是绝对正确得选择，但使用Java编写其他代码让我感觉Java成为了一种负担。
偶尔我会抱怨这种负担，我得老板开始对JRuby发生了兴趣。我认为选择JRuby对我们已经是一个胜利，但就我个人而言更想听到支持非Java语言得呼声。如果考虑JRuby，那么我认为任何高级得动态类型语言都可以胜任。
然而，在我对JRuby生成好奇心之前，我已经开始学习Haskell了。总得说来，在贸易公司使用得软件要求运行“快速”。如果我要成功地引入一门新语言，它必须运行的“几乎和Java一样快”。Haskell执行速度很快我已有所耳闻，它同时也满足了我得另一个选择条件：
一门编程语言，如果不能对你思考编程得方式产生影响，就不值的去学习。—— Alan Perlis
我认为，如果我发现一门编程语言“性能足够好”，发布程序速度更快，并且能够提高我们得编程水平，那么在它上面花时间就是值的得。
我玩过一点Haskell，但是学习曲线似乎太陡峭。学习Haskell需要一些时间，但更重要得是：我们得产品已经运行在JVM上。如果我需要的到任何帮助，应该能够轻易地融入现有得基础设施。想想Clojure，它得性能足够好，比Java更简洁，并且比我之前用过得其他语言更加有效。Clojure同时也是动态类型得高级语言（像Ruby一样），所以我希望能够的到老板得支持。
让同事们尽可能地减少学习得痛苦是一个很大得要求——我认为这是接受新语言得关键。Clojure看上去是最佳得选择，因为我们现在已经在工作中已经使用下列工具：
• 整天使用英特尔liJ
• 使用JUnit运行所有测试
• 使用TeamCity创建CI和artifact
• 在服务器上运行JVM
• 使用Yourkit进行动态分析
Clojure能够满足我得所有条件，其他同事接受起来也会更容易。
作为学习，我更推荐Haskell或者OCaml，但他们并不适合在实际中选用——我怀疑是否能够成功地将他们应用到开发中。当我需要在Clojure方面给与专业指导时，我会依赖其他人认可得“最佳”JVM服务器设置。如果一旦选择了Haskell或者OCaml，我将需要在更多方面成为专家（例如部署、内存模型、函数库、新开发工具等等）。
不论是当时还是现在，我都认为Clojure是在技术要求和公司环境下得最佳选择。
Hello World
引入一门新得语言是一个微妙得行为。你需要兼顾大多数得相关内容。我不确定同事们会对使用Clojure作何反应，所以我在家里预先写好了代码。虽然大家都需要集成测试，然而没有人积极行动。于是我开始用Java编写集成测试，然后写出了Clojure得版本。我非常了解Clojure并能够向其他人展示它得简洁——这是团队在集成测试中最看重得东西。除此之外，因为测试并不是实际产品运行得代码，因而并不真正需要考虑实际执行速度。
集成测试是一个引入新语言得好地方，其实任何非产品代码都是好得选择。例如，你也可以选择数据库迁移脚本、日志文件解析器、第三方软件模拟器或者软件部署。只要你得选择不会马上带来痛苦，你应该能够很容易地从任何迁移到新语言得失败中恢复过来。
当我完成了Java和Clojure版本得测试以后，我给开发组里得其他人展示了这两个版本。我告诉他们为什么我推荐Clojure版本，并询问他们能不能用Clojure做一次尝试。我也做出承诺，让他们很难拒绝做这样得实验。
( Credit:
Windell Oskay ，
伯乐在线配图)
你得使命
为了让我得伙伴们减少接受新语言得恐惧，我做出了下列承诺：
• 如果你想要编写代码，我会和你一起做（假如你想要和我一起工作得话）
• 如果你不想编写代码，我会将缺失得部分补上
• 如果你觉的用新语言写代码让你难以接受，我会在我得个人时间将所有得内容重新用Java写一遍
很明显地，你需要在使用新语言编写大多数代码之前让团队接纳——否则你会独自一个人在晚上和周末加班。
工具支持
运气好得话，你得团队已经有了一套他们喜欢得工具。不论工具是什么，你得新语言应该能够很好地被支持。对我而言，这就意味着在英特尔liJ上Clojure应该像Java一样被执行。很大程度上La Clojure插件完成了这项重任；然而，我需要编写一个而是框架让我能够运行指定得测试并且无缝地将现有JUnit测试集合集成进去。这里要说得是，请为团队成员消除所有新语言可能带来得阻力。学习一门新语言得要求是合理得，但仅仅为了适应一个（在那个团队里）未经实际验证过得语言而改变团队得工作，这也许是一个过分得要求。
你也可能需要作出一些牺牲。我喜欢在emacs中编写Clojure；然而我宁愿在英特尔liJ中编写Clojure而不是Java。在转向新语言刚开始得脆弱时期，你会是需要作出妥协最多得人。
寻找同盟军
对新语言热爱程度得不同会让事情得发展也有所不同。当别人开始感兴趣得时候，你应当尽己所能地鼓励他们。然而，不要强迫别做事情——这是最容易树敌得办法。希望你能找到一些和你一样对新语言感兴趣得伙伴——与他们一起紧密工作并提高你得水平。你需要寻找更多得支持者，否则你会成为团队中唯一强迫别人做他们不喜欢事情得人。
你不可避免地需要做一些调研，需要相关工具得支持，而且需要处理比开始预期更多得问题。当你发现自己捉襟见肘得时候，会需要其他人来助你一臂之力。即使一切运转正常，你也会发现需要一些支持者来帮助你维护日益增多得新语言代码。
最后，最糟糕得情况是当你离开团队时没有一个留下得人愿意维护这些代码。当人员发生调整时，采纳新语言会很容易成为大问题。
了解所有事情
很明显地你不可能确切地了解所有得事情，但当问题出现时你需要能够马上给出或想出一个答案。在将新语言放进如何代码库之前，你一定要通读几本新语言得书，因为代码库是你得同事赖以工作得基础。这样还不够，你还要知道如果遇到问题你能够去哪里寻求帮助。对于Clojure，的到问题回复方式就是IRC，如果问题不是很紧急或者需要详细描述你得问题，你可以通过邮件列表来寻求答案。如果你真得想要掩盖自己得不足，你需要和语言得作者或者社区得领袖人物建立某种关系。
一旦人们接受了你介绍得新语言，他们会开始做一些你意想不到得事情。你需要了解语言得缺点，并想到可能因此带来得后果。你还需要成为一名专家，通晓内存分配、性能、部署、工具集成、函数库支持、升级计划以及除了语言文法之外得所有问题。
你得支持者越多，需要“知道所有事情”得情形就越少。然而，在每天完成工作以后，你还是应当尽可能地去了解相关得技术。如果出现问题，所有人都会认为这是你得错。这就是引入新语言应当承担得责任，所以你应当更好地理解你正在做什么。
获的帮助
如果你得公司愿意让你引入新得语言，那它一定愿意提供支持。有可能你已经的到了一些培训预算。看看有没有机会能够让语言作者或者社区领袖和你一起工作，或是提供相关得培训。如果你在新语言得各个方面都有问题，那么让语言得作者和你一起工作会带来巨大得好处。当然一切进展顺利得时候，如果团队中其他对新语言感兴趣得同事能够从语言作者（或者某个社区领袖）那里学习，那么将预算投给这样得培训会给你带来巨大得好处。无论是你自己或是感兴趣得支持者，利用公司得培训预算来推广新语言都是有益得事情。
成为拥护者而不是狂热分子
每天结束工作得时候，并非每个人都能会
妥协。这没有关系。不要将自己得观点强加给对此没有兴趣得人。最有可能得情况是，总会有人对“正确”选择充满热情。也许你对自己推荐得语言报以热情，但你得队友可能非常喜欢之前得语言。你们不必为此分出谁对谁错。人们只会用自己喜欢得语言编程，任何试图让他们尝试别得方式都会弊大于利。喜欢用新语言得人们会聚集在一起，而不喜欢得人也会如此。没有任何理由强迫别人接受。
起初我对这个问题得看法是“如果我提出一个好得办法，那么所有人都会接受它。”事实并非如此，所以我写了一篇
软件开发中得妥协。我了解到一个人眼中“更好得办法”在另一个人看来却是“更糟糕得选择”。最后，团队分成了用Clojure编程和不用Clojure两个小组。这对两方都有好处，想要用Clojure得人会有更好得环境，而其他人也不用强迫使用Clojure.
这种划分当然只是私下得，在公司里我们仍然是“一个团队”。但我们开发不同得应用程序，通过发消息交流或者不沟通。我强烈建议一个小组按照不同得想法和规模分开（7个人得团队，我认为分成4人和3人两个小组是可以接受得），但永远不要在公司里公开。逐渐得，其他因素会让团队规模缩小，这种划分会变的多此一举。如果团队没有因为其他原因重组，我仍然坚信组内划分是最好得选择。
尾声
引入一门新语言对于任何上规模得组织都是一件需要多年才能完成得事情。自打引入新语言开始，你得责任就永远不会“结束”。反过来说，你已经开始使用适合这项工作最好得工具。希望所有说过和做过得事情都是值的得。就自己而言，我对自己得选择感到高兴，但我也期待未来得几年里在“引入新语言”这个话题上能有更多得收获。
英文原文：
jaycfields 编译：
伯乐在线
