千万不要和一种编程语言厮守终生

发布时间：2025-11-05 13:24:07 来源：创站工坊 作者：域名

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

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

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

没有***的语言

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

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

例如，许多通常使用运行时语言，如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》等)。

语言是手段而不是目的

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

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

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

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

其他需要考虑的地方

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

相关文章