Python是工程,不是艺术

When Python first emerged on the software scene in the early 1990s,
it spawned what is now something of a classic conflict between its proponents and
those of another popular scripting language, Perl. Personally, I think
the debate is tired and unwarranted today—developers are smart enough to draw their own conclusions.
Still, this is one of the most common topics I’m asked about on the training road,
so it seems fitting to say a few words on the topic here.

当Python九十年代初出现时,曾激起Python的支持者与另一门时髦语言Perl拥护者的之间的经典冲突.如今这场争论已成为过去.

个人认为: 这场争论是很令人厌烦的,也是毫无根据的。开发者都很聪明,知道如何选择。现在为止,这仍然是一场最出名的主题.

在我培训的过程中,经常会被问及,因此有必要就这个话题说几句。

The short story is this: you can do everything in Python that you can in Perl,
but you can read your code after you do it. That’s it—their domains largely overlap,
but Python is more focused on producing readable code.
For many, the enhanced readability of Python translates to code reuseability and maintainability,
making Python a better choice for programs that will not be written once and thrown away.
Perl code is easy to write, but difficult to read.
Given that most software has a lifespan much longer than its initial creation, many see Python as a more effective tool.

很浅显的是: Perl能做到的,Python都能做到,但你必须在写之后要读懂她.显然,这是他们之间大的交集。

显而易见:Python更关注于代码的可读性,在大多数情况下,提高代码的可读性转化为:代码的重用性及可维护性.

这样一来,使得Python成为了一个很好的选择: 不会写了后就丢弃。 Perl代码很容易写,但很难读。

鉴于软件都有很长的生命周期,远比初始开发要长,因为很多人视Python为更有效的工具。

The somewhat longer story reflects the backgrounds of the designers of the two languages,
and underscores some of the main reasons people choose to use Python.
Python’s creator is a mathematician by training; as such, he produced a language with
a high degree of uniformity—its syntax and toolset are remarkably coherent. Moreover,
like math, its design is orthogonal—most of the language follows from a small set
of core concepts. For instance, once one grasps Python’s flavor of polymorphism, the
rest is largely just details.

这很大程度反映了两门语言设计者的背景,并体现了很多人选择使用Python的原因.

Python的缔造者是个训练有素的数学家,这就使得其发明的语言具有高度的统一性:

她的语法和工具集都带有显著的连贯性。更有甚至,像数学一样其设计具有正交性:

即大部分的语言都遵循一组小的核心概念。例如,一旦你掌握了多态,其他大部分都是细节,仅此而已。

By contrast, the creator of the Perl language is a linguist, and its design reflects this heritage.
There are many ways to accomplish the same tasks in Perl, and language
constructs interact in context-sensitive and sometimes quite subtle ways—much like
natural language. As the well-known Perl motto states, “There’s more than one way to
do it.” Given this design, both the Perl language and its user community have historically
encouraged freedom of expression when writing code. One person’s Perl code can
be radically different from another’s. In fact, writing unique, tricky code is often a
source of pride among Perl users.

相比而言, Perl的创立者是个语言学家,因此其设计反映了这种语言的特性。

在Perl中,做同样的任务,可以有很多种方法,语言的结构受语境交互影响。

有时是非常敏感的,非常像自然语言。恰如一句著名的Perl座右铭所说:

条条道路通罗马! 鉴于这种设计,不仅Perl语言本身以及Perl用户社区,

都鼓励并提倡在写代码时,追求自由的精神。因此一个人写出来的代码

很可能与他人截然不同! 事实上,Perl开发者常以编写独特的,很有技巧的代码为荣!

But as anyone who has done any substantial code maintenance should be able to attest,
freedom of expression is great for art, but lousy for engineering. In engineering, we
need a minimal feature set and predictability. In engineering, freedom of expression
can lead to maintenance nightmares. As more than one Perl user has confided to me,
the result of too much freedom is often code that is much easier to rewrite from scratch
than to modify.

但是那些曾经维护过大量代码的人可以证明:自由表达的精神对艺术而言非常棒。

但对工程而言,就非常令人讨厌了。从工程的角度,我们需要最小化功能集及可预测性。

在工程领域,自由表达会导致维护的噩梦。不止一个Perl用户向我吐露:

太过于自由的结果就是:程序很容易重头写起,但修改起来就很难了!

Consider this: when people create a painting or a sculpture, they do so for themselves
for purely aesthetic purposes. The possibility of someone else having to change that
painting or sculpture later does not enter into it. This is a critical difference between
art and engineering. When people write software, they are not writing it for themselves.
In fact, they are not even writing primarily for the computer. Rather, good
programmers know that code is written for the next human being who has to read it in
order to maintain or reuse it. If that person cannot understand the code, it’s all but useless
in a realistic development scenario.

鉴于此:当人们对雕像涂抹漆画,出于纯粹美学的角度,他们可以随意涂抹.

至于今后某人不得不改变他的漆画或者创意,都不在其考虑的范畴。

这就是艺术和工程最关键的区别。当人们写代码时,他们并不能纯粹为自己而写.

事实上,他们甚至不是专门为计算机而写的。当然啦,优秀的程序员知道:

代码是为今后维护甚至重写的人而写。如果负责维护的人完全不能理解代码,

那么在现实中,这些代码几乎毫无用处。

This is where many people find that Python most clearly differentiates itself from scripting
languages like Perl. Because Python’s syntax model almost forces users to write
readable code, Python programs lend themselves more directly to the full software
development cycle. And because Python emphasizes ideas such as limited interactions,
uniformity, regularity, and consistency, it more directly fosters code that can be used
long after it is first written.

这就是很多人发现Python区别于另一门脚本语言Perl最显著的地方。

因为Python的语法模式强迫了用户去写可读的代码,Python语言会引导他们朝完整的软件开发流程前进。因为Python更强调:

有限交互性、一致性、规则性以及统一连贯性,会更进一步导致:Python自首次编写后,可以运行很长一段时间。

In the long run, Python’s focus on code quality in itself boosts programmer productivity,
as well as programmer satisfaction. Python programmers can be creative, too, and
as we’ll see, the language does offer multiple solutions for some tasks. At its core,
though, Python encourages good engineering in ways that other scripting languages
often do not.

长期以来,Python专注于代码的质量也提升了程序员的生产力,和开发者的满意度。

Python的程序员会变得更富有创造性,并且我们以后会明白,对某些项目而言:

这门语言的确提供了多种解决方案。就核心而言,Python提倡工程的开发方式是其他脚本语言所不具备的。

At least, that’s the common consensus among many people who have adopted Python.
You should always judge such claims for yourself, of course, by learning what Python
has to offer. 

这是很多采用Python者之间的共识。当然你自己也能判断:Python到底为你提供了什么。

NOTE:
英文文章摘自《Learning Python》Python is engineer,not art部分.

时间: 2024-11-08 18:53:53

Python是工程,不是艺术的相关文章

python代码 程序员编程艺术 1.1

<程序员编程艺术:面试和算法心得>http://taop.marchtea.com/ https://github.com/julycoding/The-Art-Of-Programming-By-July/tree/master/ebook/code/python 1.1 旋转字符串 1: def simpleShift(str, n): 2: tmpStr = str[n:] + str[:n] 3: return tmpStr 4:   5: def LeftShiftOne(str):

更好的处理 Python 多工程 import 依赖

话说, 这段时间需要开发一个项目, 新项目对现有的几乎所有项目都有依赖. 豆瓣现存的几个大项目,基本都是围绕豆瓣主站shire的依赖, 也就是说, 其他项目对shire的单项依赖,  这些项目在需要主站shire模块的时候, 无一例外的将shire的工程路径加入到其他工程的sys.path中, 熟悉Python Import的人一定马上会意识到, 这个并不是什么好方法, 因为这样会造成Python Import的搜索路径产生一些不确定因素, 也就是Import  搜索空间污染, 比如说, 我在a

python获取工程路径下的文件方法

如下可以获取工程路径与文件存放的位置 import time, os, random import subprocess import re PATH = lambda p: os.path.abspath(os.path.join(os.path.dirname(__file__), p)) # 获取当前文件所在的路径 cur_path = os.path.dirname(os.path.realpath(__file__)) print(cur_path) # 获取工程所在的路径,如果加入目

python代码 程序员编程艺术 2.1

首先一般考虑"万能的"暴力穷举(递归.回溯).但因为穷举时间复杂度通常过高,所以需要考虑更好的方法,如分治法(通过分而治之,然后归并),以及空间换时间(如活用哈希表). 此外,选择合适的数据结构可以显著提升效率,如寻找最小的k个数中,用堆代替数组. 再有,如果题目允许排序,则可以考虑排序.比如,寻找和为定值的两个数中,先排序,然后用前后两个指针往中间扫.而如果如果已经排好序了(如杨氏矩阵查找中),则想想有无必要二分.但是,如果题目不允许排序呢?这个时候,我们可以考虑不改变数列顺序的贪心

工程脚本插件方案 - c集成Python基础篇(VC++嵌入Python)

序: 为什么要集成脚本,怎么在工程中集成Python脚本. 在做比较大型的工程时,一般都会分核心层和业务层.核心层要求实现高效和稳定的基础功能,并提供调用接口供业务层调用的一种标准的框架划分.在实际中根据需求会拆分的更细.外部的表现形式就是一个核心动态库,带着一堆业务业务动态库.通过一个调度程序把这些链接起来,外加一堆配置文件,就形成一个完成的项目. 这种模式在一个团队开发中,工作职责比较容易划分.制定API接口后,开发工作基本可以并行实现,包括后期的功能测试(白盒.黑盒).不管工程使用什么语言

工程脚本插件方案 - c集成Python基础篇

工程脚本插件方案 - c集成Python基础篇 序: 为什么要集成脚本,怎么在工程中集成Python脚本. 在做比较大型的工程时,一般都会分核心层和业务层.核心层要求实现高效和稳定的基础功能,并提供调用接口供业务层调用的一种标准的框架划分.在实际中根据需求会拆分的更细. 外部的表现形式就是一个核心动态库,带着一堆业务业务动态库.通过一个调度程序把这些链接起来,外加一堆配置文件,就形成一个完成的项目. 这种模式在一个团队开发中,工作职责比较容易划分.制定API接口后,开发工作基本可以并行实现,包括

1-了解Python

为什么使用python: 软件质量: 可读写.一致性.软件质量 支持软件开发的高级重用机制 提供开发者的效率: 代码只有java或C++的1/5~1/3 无须编译链接,提高了程序原的效率 程序的可移植性: 用户图像界面.数据库接入.基于Web的系统等 标准库的支持: 组件集成: 可以调用C或C++的库 可以被C和C++程序调用 可以于Java组件集成 软件质量: 简洁和高可读性的语法极简主义的设计理念:尽管实现某一编程任务通常有许多种方法,往往只有一种方法是显而易见的python采用模块化设计.

Python学习之ImportError 错误详解

本文和大家分享的主要是Python 的 ImportError 错误相关内容,一起来看看吧,希望对大家学习python有所帮助. 问题 错误:ImportError: No module named XXX 在Python的工程中,偶尔会遇到文件无法引用的情况,即PyCharm IDE支持文件跳转,但是当文件执行时,找不到模块. 例如,错误如下: Traceback (most recent call last): File "utils/average_clinic.py", lin

Python图像处理(1):替换OpenCV

快乐虾 http://blog.csdn.net/lights_joy/(QQ群:Visual EmbedLinux Tools 375515651) 欢迎转载,但请保留作者信息 先前构造图像处理开发环境的时候,用一个别人编译好的安装包将OpenCV安装到了c:\python27\lib\site-packages目录下,但这个OpenCV没有符号表,无法进行C/C++的代码调试.我们用VS编译的OpenCV替换它. 首先修改OpenCV的Python接口工程,将其输出到python的库目录下,