Python 是工程,不是艺术

未匹配的标注

当 Python 在上世纪 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 提供了哪些东西,你应该自己去判断这些说法。为了帮助你开始,让我们进入下一章节。

本文章首发在 LearnKu.com 网站上。

上一篇 下一篇
讨论数量: 0
发起讨论 只看当前版本


暂无话题~