不要和一种编程语言厮守终生：为工作正确选择

Posted 2020-06-28 Ejnstein

我们程序员在着手一个项目时，需要做的关键决定之一就是选择一种语言，或一组语言，用于实施该系统。这一决定不仅会影响系统的实现，也会影响设计。例如，我们应该使用面向对象的语言还是过程语言？选择什么语言对项目以及作为项目一部分的程序的生命周期有着深远的影响，很多次，我们基于一些非常善变的因素，没有思考太多就去选语言：这语言是我惯常用来实现这类系统的；这语言我了解得最透彻；这是我最喜欢的语言，我很享受于用这种语言编程；等等。

既然这个决定会导致深刻而长远的结果，那么我们是不是在做这个抉择时应该更加务实？很多时候，我们会盲目地偏颇于我们选择的语言。而且，有时候我们之所以不喜欢选择这种语言的原因可能正是为什么我们要选择那种语言的原因。

如果我们能够放开胸怀，坦诚地对待自己持有的偏见，那么我们就可以减轻一些类似在装修时硬要将方钉钉进圆形孔的痛苦。虽然我们没有什么秘诀来为项目选择完美语言，但还是可以遵循一些原则，帮助我们做出一个更好，更合适的语言选择。

没有完美的语言

这一点对任何人，甚至是新手而言，都是在意料之中的，并且我们很多人都愿意承认，“当然，这种语言并不是完美的语言，”但与此同时，我们很多人还是会说，“这语言是最好的编程语言”。说一种语言是项目的最好语言的关键是项目的背景，也就是说，最好的语言只存在于一定的范围内。这就是我们的第一条原则：

没有完美的语言：每一种语言都有它的优点和缺点。

例如，许多通常使用运行时语言，如Java或Python的开发人员，声称C或C ++令人透不过气来，会因为关注例如内存管理这类低层次的细节，或关心编译时类型检查的严格粒度，而扼杀分置于开发人员的职责。这是事实，只要我们正在开发的项目不关注看似琐碎的任务，如内存管理或发生在单一循环中的copy-assignment的数量。

相反，如果我们工作在一个项目，或项目的一部分，那么对于代码应该如何高效以及程序的关键性安全的偏见需求是自然而然的，这些看似繁琐的细节可能正是我们正在寻找的粒度水平。在这种新的背景下，Java或Python的运行时性质似乎过于漠不关心或过于心不在焉。相反，我们希望当内存分配和释放的时候，能够严格控制有多少move-assignment和copy-assignment被执行，并在编译时捕捉尽可能多的错误，而不是让错误渗入运行时（表现为运行时异常）。

虽然在理论上“没有完美的语言”这一点听起来是显而易见的，但是我们作为开发人员的行为通常会背离这个概念：我们说我们知道我们最喜欢的语言是不完美的，但我们还是继续对我们开发的项目使用这种语言，不管它是否适合。此外，当其他的开发人员质疑我们选择的语言时，我们会坚决捍卫我们的选择，而不愿意从他或她的反驳中看见事实的真相。请记住：每一种语言都有它的优点和缺点。了解你掌握的语言的优点和缺点，然后根据实际情况做出选择。

你不喜欢一种语言的原因可能就是你应该使用它的原因

这似乎违反直觉，但有的时候，我们之所以不喜欢一门语言可能正是使用某种语言的原因。还是上面的例子，在我作为一个C ++开发人员的经验中，很多时候因为有那么多不同的概念要跟踪（内存管理和对象寿命时间，C ++编程三原则等），以致于完成项目的一个简单功能都会变得繁琐不堪。在用C ++开发几周之后，使用Python，Java或另一种“更高级”的语言，简直就像上天的恩赐：但真的是这样的吗？

有时候，可能我们不喜欢一门语言的原因正是我们要使用该语言的原因。如果我正在开发一个驱动程序或一些关键性安全，实时的系统，上面表述的繁琐不堪的原因可能正是这个语言的最大优势。例如，C ++提供了一种机制用于表达当对象被复制时被执行的逻辑，这在效率和严谨性井然有序的时候是非常宝贵的。

这可能看上去都很好都很棒，因此我们很难确切指出在某个背景下，某种你看不顺眼的语言可能反而更有帮助。那么，我们该怎么知道哪些你不喜欢的语言是有帮助的呢？这就引出了我们的第二条原则：

对自己要诚实：知道自己为什么不喜欢一门语言，不要教条化自己的憎恶。

例如，在上面那个C ++的例子中，我之所以不喜欢长时间地用C ++编程，是因为这语言要求思想严谨，否则很容易犯错，就像是被困于丛林中（过多地关注树木，而不是树林这个整体）。这种严谨会妨碍开发人员去质疑，如，“我要在堆栈上或堆上创建对象吗，或者部分在堆栈上，另一部分在堆上？”或“要让这个类可扩展，应该通过模板参数还是通过继承？”等决定。在其他语言中，开发人员只需分别创建一个对象以及使用面向对象的继承就可以完成这些任务，然后进入到下一个功能，因为语言（或者，更准确地说，编译器或解释器）关注这些细节。

但是，如果我对自己诚实的话，我会承认，我之所以不喜欢C ++的这些功能，是因为它将表达这些细节的责任归咎于我。在其他语言中，我不仅不需要负责这些细节，而且我也没有责任表达这些细节：它们被抽象远离开发人员。在一个这些细节是必不可少的上下文中，我不喜欢C ++的原因正是我应该使用这种语言的原因。

这是否意味着，我们应该愁眉苦脸地使用这些会让我们对这语言恼怒的功能？也没有必要。或许你可以换个角度：不要将这些功能当作缺点，也许我们应该拥抱它们，将它们当作完成任务的必需品。我们不应该说“这真是一个悲剧，”而应该说，“谢天谢地，我居然能用这种语言做到这一点。”请记住：在某些背景下，这些功能将是上天的恩赐，而在其他情况下，它们 才是累赘。至于为什么不喜欢某一门语言的功能，请诚实地告诉自己。

越熟悉其他语言，越好

对于这一点，就是我们要说的第三个原则：

如果你拥有的唯一工具是一个锤子，那么你看每一个问题都像是钉子。

这条规则并不适用于软件工程，但它尖锐地表现了许多软件开发的情况。很多时候，我们选择一种语言，或一种语言支持的工具（如Java的JMS，Python的ASYNCIO，Rails的Ruby等），是因为我们知道它们存在。如果我们唯一熟悉的语言是Java，那么我们会将我们碰到的所有问题都适应到Java的上下文中。例如，“我需要为一个通信应用创建一个路由框架。在Java中我该怎么做呢？”这就限制了可供我们使用的工具，并人为地限制我们为完成工作选择合适工具的余地。

解决这个问题的方法是扩大你的视野，了解其他语言的的功能和错综复杂之处。正如Andrew Hunt和David Thomas在《The Pragmatic Programmer》中给出的建议，一个好的做法就是，每年学习一门新的语言。这可不没有听上去那么容易，学习一门语言对不同的人将意味着不同的事情。还有一个衍生问题是，我们对正在进行中的项目往往只会使用这一种语言，从而使得学习的另一种语言显得毫无用处。例如，假设我是一个android开发人员，基本上每天只用Java，那么学习C＃可能就会显得不合时宜地浪费时间。

不要被假象所蒙蔽。学习其他语言的优势体现在我们能从不同的角度去看问题，并且使用最适合该问题的工具。为了做到这一点，我们必须学习其他语言的相关警告，以及开发人员使用这些语言解决问题的方式。例如，如果一个开发人员想用C ++执行元编程，那么他或她可以使用C ++中的Template Metaprogrammming（TMP），但他或她也可以使用Java中的反射。理解其他语言是如何解决类似问题的，可以减少我们认为它毫无用处的风险。

再说一个例子，如果我们需要能够改变一个类的运行时特征，那么一个深入熟悉C ++错综复杂性的C ++开发人员，可能会试图编造一个延伸这个编译时语言的界限的解决方案。而另一个C ++开发人员，由于对Java也有一定的了解，就能够说，“我喜欢C ++，但Java的运行时反射更适合解决这个问题。”

因为有如此之多的编程语言任开发人员择选，因此，优先安排学习什么语言很重要。不妨从当今最流行的语言入手（可参考《most popular languages on Github》，《Language Trends on Github》，《The 9 most popular computer languages》，《according to the Facebook for programmers》等）。

语言是手段而不是目的

这是第四条，也是最后一条原则，听上去可能最哲学，但也可以说是最重要的：

编程语言是一种手段，而不是目的。

除非你是一个语言标准的作者或是一个编译器的作者，否则你就应该将编程语言当作是一种手段而不是目的，目的是完成项目：最终的目标是要完成项目，而不是使用特定的语言。这并不意味着每个开发人员就无权要求他或她喜欢或不喜欢的语言（实际上，如果我们对自己诚实的话，这些好恶反而能够让我们受惠；参见上面的第二条原则），但我们不应该自欺欺人作出这样的决定，如，“这对我来说是使用该语言这一功能的一个很好的机会”，除非该语言的功能真正适合项目的需求。

重要的是要记住，语言只是表达如何解决手头问题的一种方法：请确保你选择了最能表达解决问题域的语言。

其他需要考虑的地方

下面是一些我们在选择语言的时候，需要补充考虑的地方：

考虑语言如何与其他语言的交互。例如，如果你认定Python是完成大部分项目的最好语言，但在你的项目中有一个定义良好的组件，需要极高水平的粒度或效率（更适合用C或C++ ），这并不意味着你不能在这个项目上使用Python。相反，考虑使用Python，特定组件用C或C ++写，然后使用Python C API接口此组件。请注意，要制定这样的解决方案，我们需要知道Python有一个C API；因此，了解最流行语言的这些功能是很有帮助的。

中间件可以允许使用多种语言。例如，如果有两个必须进行通信的应用程序，如移动设备和一个服务器应用程序，但这并不意味着它们必须使用相同的语言（当然也可以相同，如果你判断认为这是最好决定的话）。如果这个移动设备是一款Android手机，而服务器应用程序非常适合作为一个Python应用程序的话，那么使用一个消息代理，如RabbitMQ，可以让你在通信的同时使用这两种语言：Android应用程序可以使用Java RabbitMQ API，而服务器应用程序可以使用Python RabbitMQ API。

拥抱其他语言的古怪之处。如果你是一个Java开发人员，那么你会使用包来分隔源代码的逻辑单元；如果你是一个Python开发人员，那么你会使用Python的包结构做相同的事情；如果你是一个C ++开发人员，那么你会使用命名空间或前缀的类名（即“DZone_MyClassName”）。了解你正在使用的语言的特别之处，并拥抱它们：在罗马，就入乡随俗。否则的话就像是因为你更喜欢单词用意大利语发音，而用意大利口音说德语，这样就显得不伦不类了。当然也有可能一种语言的一个功能长期存在，但是这样的话，其中必有其原因：确保自己明白其中的道理。

译文链接：http://www.codeceo.com/article/do-not-marry-a-language.html
英文原文：Do Not Marry a Language: Selecting the Correct Language for the Job