程序员们为什么需要研究编程艺术

作者：辛普.卡姆登
翻译：PurpleEndurer，2011-05-13 第1版

　　导读：辛普.卡姆登鼓励程序员们回顾编程行业历史，同时密切关注行业最新发展，积累知识，从而理解这个行业的博大精深。

　　对于工作在第一线的一般程序员而言，讨论计算理论就像在枪林弹雨中谈论硝的化学性质一样：可能都是正确的，但与摆在面前的问题并不直接相关（不解燃眉之急）。当我们要解决的旧应用程序系统Web用户界面的一个新问题已经有了最后期限时，为什么要浪费时间想像Haskell（哈斯克尔）和 Alan Kay（阿兰.凯）死斗的结果呢？我们为什么要关心我们是否正在使用一个Monad或异常返回一个错误状态？“orthogonal（正交）”到底是什么意思呢？不要给我一份研究报告，只要把能工作的代码给我就行了。于是“明日复明日”。

*PurpleEndurer注：关于Monad，可参考：
http://zh.wikibooks.org/wiki/Haskell/%E7%90%86%E8%A7%A3monads

　　在许多项目经理看来，涉足计算理论的程序员们造成的危险甚至比浪费时间更大：他们采用的新方法对项目构成了威胁。这种态度并非全无道理。每一个承诺会彻底改变软件开发的新想法，在炒作消退，在程序员可用工具箱中找到适当位置之前，似乎都对业界产生相当的伤害。把这些理论加以转换，试图把每一个问题都硬塞进新模式，不管这适合与否。正如进化论的一个骇人听闻的误用为纳粹易做图提供了一个理由。例如，面向对象的误用，导致了在修饰名上的各种各样的编程陋习（愿上帝温宽恕我的灵魂）。

　　编程的历史，点缀着挫折和摇摆。我记得Dijkstra“Go To语句是有害的”的著名论断，这个论断让许多的程序员为了避免使用GOTO而创造出了各种怪诞扭曲的代码，即使其中有一些迫切需要的。对结构化编程和其他规则的盲目服从危害甚大，我在ANSI小组委员会工作时，曾有人提出了反对意见“编程并非总是具有结构性”，我回答说：“我不赞成结构编程。”每个人脸上的无声震动使我估计会立即被除名。如果我的朋友和导师肯.李斯特（Ken Lidster）没有发言和解释，我确实可能会落得这个下场。肯.李斯特说，我的意思是反对结构化编程原则的教条主易做图释。他是对的，尽管当时我觉得他已经淡化了我的大胆断言。

　　不过，对编程理论追求的我们确实让我们有所改进。如果不是所有这些应用于改善软件开发实践中的智慧，我们都会被束缚在把机器指令打在纸带上或在Windows的Visual Basic中画窗体。“必须有一个更好的办法！”谢天谢地，总有人把这句话挂在嘴上。

　　编程语言的开发人员并不只是在同一条件下改进工作的那些人。尽管有狂热的风险，熟练的程序员通过突破严格界定的责任框框，在他们的领域中使用他们的技能，也还可以增强他们的贡献（希望他们的职业生涯也是如此）。特别是当它只是在于他们的视野之外，“软件开发作为一门学科，我们如何能够提高？”这个问题可能会产生显著的回报。危险在于之前的学习和缺乏自我评价。因为Alexander Pope（亚历山大.蒲柏）在《Essay on
Criticism（批评论）》有一段名言：

A little learning is a dangerous thing;（一知半解，为害不浅；）
Drink deep, or taste not the Pierian spring. （知识渊远，学无止境。）

　　专业程序员应该深刻体会。通过培养了对本行广泛而深刻的认识，积累历史知识，同时密切关注最新发展，他或她智慧将会得到增长，去伪存真，让每个工具物尽其用。

　英文原文链接

补充：综合编程 , 其他综合 ,