图灵云服务器,别和一种语言厮守终生：为工作正确选择编程语言

该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

没有完美的编程语言

开发人员包括新手都会承认“这个语言当然不是个完美的语言”，但同时也会说“但这是最好的编程语言”，对此我们并不会感到惊讶。说一个语言是一个项目的最好语言关键点在于项目环境，只在某种特定环境中是最佳语言。因此我们的第一个选择原则是：

没有完美的语言，每个语言都有优劣。

举例说，许多常用运行时语言如Java或Python的开发人员声称C语言或C++让人不胜其烦，总让他们关注低级细节如内存管理或编译时类型检查的严格粒度。这点无可否认，只要我们所开发的项目并非真正的关注貌似琐碎的任务如内存管理或单一循环内的copy-assignments操作量。

相反，如果我们所做的项目或项目的一部分对我们的编码效率或安全关键有极端偏见，而这种偏见又是自然而然的事，那么这种看似繁琐的细节可能就是我们所要找的粒度水平。在这种环境下，Jave或Python的运行时性质似乎显得无动于衷或者事不关己的模样。相反，我们会希望最大程度地严格控制在分配或解除分配内存时，执行了多少move-assignments 或copy-assignments，在编译时上捕捉到尽可能多的错误而不是让错误渗透到运行时(或在运行时异常时显现)

虽然这一个原则在理论上显而易见，但实际上开发者又经常偏离这一原则：我们说我们知道我们最喜欢的语言不是完美语言，但是我们仍旧在开发的每一个项目上使用这个语言，不管是否真正适合。而且，当其他开发者质疑我们的语言选择时，我们又很教条式的捍卫自己的选择，而看不到对方的论点中的优点。所以记住：每一种语言都有优点和缺点。理解你所知道的(和你所不知道的)语言的优缺点并依此作出选择。

你不喜欢一个编程语言的原因或许正是你需要使用这种语言的原因所在

可能看似有反直觉，但有时，你不喜欢一个编程语言的原因或许正是你需要使用这种语言的原因所在。继续刚才的例子，我做C++开发人员的时候，经常有很多不同概念要跟踪(内存管理和对象寿命，执行编程三原则Rule of Three等等)，所以完成一个项目的一个简单功能也变得很冗长繁琐。这种类型的开发跟踪数周之后，你会发现用Python,Java或其他“更高级别”的语言会感觉像是受了恩惠；但是事实真是如此么？

有时，我们不喜欢一个编程语言原因或许正是我们需要使用这种语言的原因。如果我在开发一个驱动或者安全关键、实时系统，我上面所表达的繁琐的理由正是这个语言最大的优点。比如，C++提供了一种机制用来表达该对象被复制时所执行的逻辑，当效率或者精确度井然有序的时候，C++在这点上的作用无可估量。

这点看似很好，但有时又没办法理解为啥我们的憎恶在某种环境下会变成一种优点。所以，这种时候我们该如何抉择？这就引出了第二个原则：

坦诚面对自己：了解你不喜欢一种语言的原因，别对自己的憎恶教条化处理。

仍旧是上面C++的例子，我不喜欢长时间用C++编程，因为这个语言要求很高的精准度，很容易导致错误或，就像困于丛林中(只见树木不见森林)。这种精准度会阻碍开发人员去质疑一些决定，“这个对象要建立在堆栈上还是堆上？还是创建在堆栈的某一部分或是另外一个堆？”。在其他语言上，开发人员只要简单的创建一个对象，或用面向对象继承来各自完成任务，并直接转移到下一个功能，因为这些语言(或者更准确的说，编译器或注释器)能负责这些底层实现。

但是，如果诚实一点，我会承认我不习惯C++这些特性的原因是它让我来承担实现这些细节的责任。在其他语言上，我并不需要负责这些细节，也不懂得如何实现：这些细节已经从开发者身上抽离出来。在一些这种细节必不可缺的环境中，我不喜欢C++的原因正是我们需要用这个语言的原因。

所以用这种让我们恼怒的语言会让我们苦不堪言么？未必。或许可以换个角度：不是将这些功能视为缺点，或许可以拥抱他们，将他们视为完成任务的一种必须。不说“苦不堪言”，而说“谢天谢地我可以用这个语言来完成任务”。只需记住：在一些环境中，这些功能会是恩赐;而在其他环境中，又会很繁琐。坦诚面对你不喜欢一种语言特征的原因。