Python是工程，不是艺术

本文节自《Python学习手册》，供学习参考

周末无事在家看看新到的技术书，讲的如何精进python语法学习，其中对Python功能性定位的一段文字我觉得非常好，这里摘抄出来供大家参考。

编程并不事关聪明与深奥，它的关键是让你的程序能够清晰地表达它的意图。

当Python 于20世纪90年代初期出现在软件行业的舞台上时，曾经引发其拥护者和另一个受欢迎脚本语言Perl的拥护者之问的冲突，而今天这已成为有关编程语言争论的一个经典例子。

我们认为今天这种争论是令人厌倦且没有根据的，因为开发人员都很聪明，而且可以得出他们自己的结论。

然而，这是我在培训课程上时常被问到的问题之一，同时也表明了人们选择使用Python的主要理由之一；因此我在这里再对这几个问题多说几句。

故事是这样的：“你可以用python 做到一切用perl能做到的事，但是，做好之后还可以阅读自己的程序代码。”

这就是问题所在，两者的领域大部分重叠，但是Python 更专注于产生可读性的代码。

就大多数人而言，python 强化了可读性，转换为了代码可重用性和可维护性，使得Python 更适合用于那些不是写一次就去掉的程序。

Perl 程序代码很容易写，但是可能会很难读。

由于多数软件在最初的创建后都有较长的生命周期，所以很多人认为Python 是更有效的工具。

这个故事反映出两门语言的设计者的背景。Python 出自训练有素的数学家之手，他似乎自然而然地创造出来一门具有高度一致性和连续性的正交语言。

Perl语言由一位语言学家孕育，他创建了一种接近自然语言的编程工具，并拥有着上下文敏感性和广泛变化性。

就像著名的Perl 所说的格言：“完成的方法不止一种。”

有了这种思维，Perl 语言及其用户社群在编写代码时，已经历史性地被鼓励脱缰式的表达式自由化。一 个人的Perl代码可能和另一个人的完全不同。

事实上，编写独特、充满技巧性的代码，常常是Perl 用户引以为傲的事。

但是，做过任何实质性的代码维护工作的人，应该都可以证实，表达式自由度是很棒的艺术，但是，对工程项目来说就令人恶了。

在工程世界中，我们需要最小化功能集和可预测性。而表达式自由度会造成维护的噩梦。

不止一位Perl 用户向我们透露过，太过自由的结果通常就是程序很容易重头写起，但修改起来就不是那么容易了。这对工程来说显然就不是那么理想了。

比如：当人们在绘画或雕塑时，他们主要是为自己所做。其他人日后去修改他们作品的可能性很低。这是艺术和工程之间关键的差异。当人们在编写软件时，他们不是为自己写。

事实上，他们甚至不是专门为计算机编写的。实际上，优秀的程序员知道，代码是为下一个会阅读它而进行维护或重用的人编写的。

如果那个人无法理解代码，在现实的开发场景中，就毫无用处了。

换句话说，编程并不事关聪明与深奥，它的关键是让你的程序能够清晰地表达它的意图。

这种对可读性的关汪就是很多人认为 Python 最有别于其他脚本语言的地方。

因为Python 的语法模型几乎会迫使用户编写具有可读性的代码，所以Python 程序会引导用户向完整的软件开发储环流程前进。

此外，因为Python 强调了诸如有限互动、代码统一性，以及特征一致性等理念，它会更进一步促进首次编写后能够长期使用的代码。

长期以来，Python 本身专注于代码质量，提高了程序员的生产力以及程序员的满意度。

Python程序员也变得拥有奔放的创意，我们之后也会看到，语言本身的确为某些任务提供了多种解決办法。有时甚至比今天它能做到的更多，这也是本书中我们会直面的一个问题。

事实上,这个边栏也可以被解读为一篇警戒寓言：编码质量其实是脆弱的，与其依赖于技术，不如更多地依靠人。

Python 已经历史性地鼓历优秀的工程方式，这是其他脚本语言通常所不具备的，但是接下来的品质故事需要你来书写。

至少，这是许多使用Python 的人之间所达成的某些共识。当然，你需要通过学习Python 的内容来形成自己的观点。