每次开始一个新项目，无论是一个独立的程序还是现有计划的一个组件，都会面临着一个应该选择什么样的编程语言的问题。只考虑之前用过的编程语言或者现在最流行的语言的话，你很可能会得到一个糟糕的结果。所以
你应该实时评估自己的选择，并不断寻找更好的替代方法。
评估一种语言的同时，你还需要考虑项目的整体架构，并不是项目的所有部分都适合用同一种语言来写。选择编程语言的过程，实际上也是你项目初步设计中的一个重要组成部分。如何分解和连接组件也非常受语言选择的
结果影响。有些项目很容易就能看出最合适的语言，相信你能够自己得出结论。当然语言也会随时间而改变，所以两年前的最佳选择也许现在已经不再适用，而当初首先被排除的语言反而变成了最佳选择。
你的团队有过什么样的经验？
虽然显而易见，但是不得不说，你也许应该选择自己最熟悉的那门语言。虽然尝试新的编程语言是一项伟大的创新，但非研究性项目并不是适合试验的地方。如果你需要预测出项目的时间表，并且避免大规模的未知变数，
相信你不会愿意使用任何不熟悉的语言。
这并不是说团队里的每个人都必须是这门语言方面的专家。你甚至可以让团队的一小部分不熟悉这门语言的人加入开发中来保证其他人能有较高的效率。仅仅因为不熟悉项目所需要的语言就把有经验或者有才华的程序员排
除在开发团队之外实在是非常愚蠢的行为！好的程序员都有不错的适应能力。当然，即使优先选择熟悉的编程语言，肯定也有让你不得不使用陌生编程语言的时候。
有没有计算开销大的操作？
比如视频处理，图形渲染，密码学，统计分析，信号处理这些对原始处理能力有巨大需求的功能。他们要执行多长时间直接影响到计算机芯片的使用效率。
对于这些模块，你几乎肯定会需要一个静态类型和编译的语言。或者简单地说，这些地方你需要快速的编程语言。不论这是多么罕见的问题，这肯定是会出现的。通常这些性能密集组件是有限的，而且可以很容易地模块化
并且和其他语言组合。
会涉及到许多子流程和文件管理吗？
很多软件都是为了自动处理重复的手工劳动而存在的。过程中一步都已经有了个非常适合的程序，你需要做的就是把他们组合在一起，这就是软件开发系统管理员的主要关注点所在，当然也包括很多保证系统和高级运行的
。
在这里，你需要执行其他程序并且进行文件管理，而脚本语言灵活又简单，并且与生俱来地实现了这些功能，毫无疑问是你的最佳选择！
有紧张的资源限制吗？
虽然在一定程度上，现在硬件已经够用了，但是在某些情况下或者对于某些应用来说，硬件还是十分受限的！这一点在嵌入式设备中尤其明显。然而不是所有的编程语言都适合受限的硬件环境下开发，你需要一种编出来的
程序能够在那样的环境下运行的语言。
有时候运行时的内存限制是主要问题，有时候可能加载过程的问题更大！也许你会遇到这样的问题：你的应用需要从EEPROM或者网络中初始化，那么你可能需要静态链表或者未修剪的库。这并不是排除了使用基于VM的
语言的可能，相反，有时你甚至需要一个小型的VM。
是否有明确的需求？
不管是什么语言所写，好的程序总是能够快速地重构和调整。一些语言本身就可以建立快速原型。而且很多商务项目完全没有规范，或者极其粗糙，这种情况下，客户在看到最初产品前完全不知道它应该是什么样子。你会
需要不断地修改，直到每个人都满意。
如果你需要在会议中频繁修改程序来演示或者是为了作一份它的详细报告，你会发现快速原型非常重要。动态语言在这里很有优势，它可以很容易地结合多个不相关的库。当然，隐藏“细节编程"，比如内存管理，也非常有
助于建立快速原型。
产品的生命周期有多长？
不是所有语言都是足够稳定的，许多年轻的动态语言在升级中会变得不向后兼容或者大量修改它的核心代码。瞬息万变的项目，决不会真的有这些变化的一个问题，事实上，许多项目甚至还会从这些变化中受益。因为时间
向后兼容性成为一个问题，寿命短的项目也会因此变成没有人关心的项目。
如果你的产品寿命长达五年，十年，甚至二十或更多年，无法向后兼容的问题可能会成为你的噩梦。我不认为你会想继续使用过久的编译器和和其它古老的工具，特别当它们还跟老的硬件挂钩时。项目支持新的版本或者新
产品肯定会让你受益。这个时候你最需要的肯定是一个有标准委员会管理，并以长期支持和向后兼容为目标定制的稳定的语言。
需要支持什么平台？
不是所有的语言都适用于所有平台。如果目标设备不支持你喜欢的语言，那么你肯定是没法使用它的！当然你也不能信任实验性的支持。你喜欢使用C语言，而目标OS上也有C编译器也并不一定意味着它会很合适。定制化
的芯片或者甚至是GPU之类有时只支持部分语言产生出来的二进制文件。
芯片组兼容性问题并不唯一，对于需要同时工作的其它软件也一样。比如你需要在用户的浏览器中运行代码，那就没有多少语言可供选择了。某些消费设备供应商也只允许部分语言在自己的平台上使用。 服务供应商往往
只专注于某些语言和框架，而并不在意别人的因此带来生的牺牲。如果你打算为Linux编写设备驱动程序，你会发现它的内核小组只支持一种语言。你可以宣传你的想法会带来怎样的好处，但如果你想支持某些特定平台，
别无选择，只能遵守该平台的意愿。
是否会有大量的位操作？
文件格式和协议相关的工作往往会需要对字节和位操作。您将需要转换格式到更高级的格式，然后再序列化成一个紧凑的格式。一些算法也会需要对数据进行位操作。最低级的线路协议也会根据你的行为对比特流进行操作
。
做这样的工作，你需要一个能够很容易地进行位操作并且能够提供合适数据类型（比如无符号整数类型）的语言。但也并非所有的二进制操作都这么麻烦，某些二进制结构就很简单，甚至经过高级包装的函数都可以对它们
进行操作。你需要仔细审查自己的工作对二进制操作的需求，然后选择一个不太麻烦的编程语言。
是否涉及到某些特定领域？
不是所有问题的最佳语言都是一样，有很多非常具体的领域存在的专业语言。比如：人工智能、文本解析、数据转换、专家系统、数学、财务分析等等。领域特定语言往往以节省大量的编码工作，而不会产生大的缺陷，所
以你应该尽可能使用它们。在这里，你不妨选择专业语言来代替你熟悉的编程语言。
领域特定语言的使用在一定程度上也限制了你可以在项目中使用的其他语言。一些被翻译成另一种语言，而另一些则可以作为可调用模块。无论哪种方式，你还需要某种方法来整合。
如果存在一个优秀的库也适用这一原则。无论它依赖哪种语言，我都建议你去使用它！
结论
要作出一个明智的选择，你会需要了解足够多的语言。如果你仅仅关注某一门编程语言，你会被这门语言以及它的思想牢牢拴住。但相比于语言来说，它们的风格可能更重要。良好地组合静态和动态语言/函数式和命令式/
高级和低级语言，再考虑具体领域环境的特点，你才能评估出最适合答案。在选择语言之外，你还需要足够的经验来最佳地利用你最后确定的语言。
当然上面也只是给你一个粗略的参考。很不幸的是第一条规则，也就是团队熟悉什么语言，通常才是实际上左右语言选择中的最终结果的因素。尽可能地把项目分解开来，然后给每一个组件寻找一个最合适的语言，至少以
我多年经验来看，组合使用多种语言从没有带来过什么坏处。
你可能会认为，只考虑上述因素也并不一定能确定下语言。事实上，这样通常注意是排除不合适的语言而不是增加新的选择。项目按组件拆分，给每个组件选择最合适的语言，最终你选择语言的标准会越来越严格，直至剩
下一两个最佳答案。但如果你不分解项目，你能得到只是一两个相当糟糕的选择，通常按模块分解项目会是更好的选择
