我将此文翻译如下。
从前，在伯尔尼，有一个不知名的专利审查员，在1905年，有收到了一份很让人失望的年度操行评价报告(www.norvig.com/performance-review.html)
E.W. DIJKSTRA ----Goto 语句是有害的(Goto Statement Considered Harmful)
这篇文章试图说服我们：为人熟知的 goto 语句应该从我们的程序设计语言里面消除，或者，至少程序员应该尽量不要用它（当然，我不认为它应该被消除）。文章没有清楚说明该用什么替换goto语句，也没有解释没有goto语句，if 语句如何运作。难道if后面都只跟一个语句，或者，只用做没有goto语句的算术？程序员如何来处理如下的情况：在到达了一个选择的结尾，程序需要转到其他地方执行。作者是所谓“结构化编程”风格的支持者，这种风格里，如果我没有理解错的话，goto被程序中的缩进代替。结构化编程是一个很好的学术实践，对于小的例子工作良好，但我怀疑这种方式对于现实世界的编程是否同样有效。Fortran语言在业界超过10年的实践表明，在现实编程中，goto语句非常有用，而且也是必要的：虽然它的存在会给程序调试带来一些麻烦，但它是一个事实上的标准，我们依赖与此。相比于学术上的纯粹主义者将其从我们的编程语言中剔除的观点，我认为goto语句带来的好处更多。
发表这篇论文可以说是浪费宝贵的版面(Publishing this would waste valuable
paper)。这篇文章如果可以发表的话，我保证不会被注意，而且也不会被引用。我有信心，从现在开始30年以内，goto语句将会安然的在我们的程序设计语言中生存并和今天一样被广泛使用。
写给编辑的一些注释：作者应该撤消这篇论文并投到不要审稿的地方。或者写信给编辑也不错，没有人会注意到。
(Confidential comments to the editor: The author should withdraw the paper and submit it someplace where it will not be peer reviewed. A letter to the editor would be a perfect choice: Nobody will notice it there!)
E.F. CODD----大型共享数据库的关系模型(A Relational Model of Data for Large Shared Data Banks)
这篇文章提出：数据库中的所有数据都可以用关系的形式表达----一些元组集合----而且在这个模型之上建立了数据的关系操作。文章提出的一些想法很有趣，而且也可能会有用。但是，这只是很初步的工作，而且没有在实现、性能和现实的用处上让人信服。这篇文章主要的观点是：表形式的表达是适用于通常的数据应用的。关于此论断，我有两个问题：表达能力和效率。这篇文章没有给出任何现实的、可以用关系模型来表达的例子。恰相反，我很怀疑，实践中的复杂情况是否可以通过关系来建模。这个模型的简单会让人们无法直接表达一些结构，比如层次结构，迫使人们使用用麻烦的外键（foreign keys）。在这用条件下，构建一个现实的模型需要大量的内部连接表，如此方能勉强给出一个现实的解决办法。也许，我们完全可以用两三个格式完好的文件来表达相同的模型。更糟糕的是，这篇文章没有任何有效的测试评估----没有使用真实或者导出的数据来比较文章提出的模型和传统方法在解决现实问题时到底是否更有用。使用特定格式的文件的好处是：数据可以根据操作的方式来布局。而这篇文章提出的模型，对于任意现实的数据库，使用者都要低效的使用大量的表的连接。虽然，我们也还并没有实验结果来指出此解决方案是不具备扩展性的。
这种形式化带来了不必要的复杂，使用了一般数据库从业者不熟悉的概念和符号。文章也没有告诉我们如何将这些晦涩的表达变成可执行的代码。
总之，缺少现实世界中的实例、性能测试和实现细节，我们只模糊的获得了一些使用不太熟悉的数学完成的推导，以及一点点（或者根本就没有）关于实践的结论。此文可以坦然地拒绝(It can be safely rejected)。
(To be continued...)
没有评论:
发表评论