1. 编程的艺术就是处理复杂性的艺术。
2. 优秀的程序员很清楚自己的能力是有限的,所以他对待编程任务的态度是完全谦卑的,特别是,他们会象逃避瘟疫那样逃避 “聪明的技巧”。——1972年图灵奖演讲
3. 计算机科学是应用数学最难的一个分支,所以如果你是一个蹩脚的数学家,最好留在原地,继续当你的数学家。
4. 我们所使用的工具深刻地影响我们的思考习惯,从而也影响了我们的思考能力。
5. 实际上如果一个程序员先学了BASIC,那就很难教会他好的编程技术了:作为一个可能的程序员,他们的神经已经错乱了,而且无法康复。
6. 就语言的使用问题:根本不可能用一把钝斧子削好铅笔,而换成十把钝斧子会是事情变成大灾难。
7. 简单是可靠的先决条件。
下面是Dijkstra遗孀和子女发出的通告:
>Grateful for most that has befallen him, has peacefully passed away,
> Edsger Wybe Dijkstra,
>our husband and father.
>
>We hold him very dear.
>
>The cremation will take place on
>
>Saterday, August 10th, 12:30 PM at
>Somerenseweg 120
>Heeze
>the Netherlands
>
>Maria C. Dijkstra Debets
>Marcus J. Dijkstra
>Femke E. Dijkstra
>Rutger M. Dijktra
>
>Please forward this message to whomever you feel missing in the
>recipient list.
最后,请重温Dijkstra在1968年发表的那篇短文:
Go To Statement Considered Harmful
For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.
My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the "making' of the corresponding process is delegated to the machine.
My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
Let us now consider how we can characterize the progress of a process. (You may think about this question in a very concrete manner: suppose that a process, considered as a time succession of actions, is stopped after an arbitrary action, what data do we have to fix in order that we can redo the process until the very same point?) If the program text is a pure concatenation of, say, assignment statements (for the purpose of this discussion regarded as the descriptions of single actions) it is sufficient to point in the program text to a point between two successive action descriptions. (In the absence of go to statements I can permit myself the syntactic ambiguity in the last three words of the previous sentence: if we parse them as "successive (action descriptions)" we mean successive in text space; if we parse as "(successive action) descriptions" we mean successive in time.) Let us call such a pointer to a suitable place in the text a "textual index."
When we include conditional clauses (if B then A), alternative clauses (if B then A1 else A2), choice clauses as introduced by C. A. R. Hoare (case[i] of (A1, A2,···, An)),or conditional expressions as introduced by J. McCarthy (B1 -> E1, B2 -> E2, ···, Bn -> En), the fact remains that the progress of the process remains characterized by a single textual index.
As soon as we include in our language procedures we must admit that a single textual index is no longer sufficient. In the case that a textual index points to the interior of a procedure body the dynamic progress is only characterized when we also give to which call of the procedure we refer. With the inclusion of procedures we can characterize the progress of the process via a sequence of textual indices, the length of this sequence being equal to the dynamic depth of procedure calling.
Let us now consider repetition clauses (like, while B repeat A or repeat A until B). Logically speaking, such clauses are now superfluous, because we can express repetition with the aid of recursive procedures. For reasons of realism I don't wish to exclude them: on the one hand, repetition clauses can be implemented quite comfortably with present day finite equipment; on the other hand, the reasoning pattern known as "induction" makes us well equipped to retain our intellectual grasp on the processes generated by repetition clauses. With the inclusion of the repetition clauses textual indices are no longer sufficient to describe the dynamic progress of the process. With each entry into a repetition clause, however, we can associate a so-called "dynamic index," inexorably counting the ordinal number of the corresponding current repetition. As repetition clauses (just as procedure calls) may be applied nestedly, we find that now the progress of the process can always be uniquely characterized by a (mixed) sequence of textual and/or dynamic indices.
The main point is that the values of these indices are outside programmer's control; they are generated (either by the write-up of his program or by the dynamic evolution of the process) whether he wishes or not. They provide independent coordinates in which to describe the progress of the process.
Why do we need such independent coordinates? The reason is - and this seems to be inherent to sequential processes - that we can interpret the value of a variable only with respect to the progress of the process. If we wish to count the number, n say, of people in an initially empty room, we can achieve this by increasing n by one whenever we see someone entering the room. In the in-between moment that we have observed someone entering the room but have not yet performed the subsequent increase of n, its value equals the number of people in the room minus one!
The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the values of some well chosen variables, but this is out of the question because it is relative to the progress that the meaning of these values is to be understood! With the go to statement one can, of course, still describe the progress uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock). The difficulty is that such a coordinate, although unique, is utterly unhelpful. In such a coordinate system it becomes an extremely complicated affair to define all those points of progress where, say, n equals the number of persons in the room minus one!
The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program. One can regard and appreciate the clauses considered as bridling its use. I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs, but whatever clauses are suggested (e.g. abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be maintained to describe the process in a helpful and manageable way.
It is hard to end this with a fair acknowledgment. Am I to judge by whom my thinking has been influenced? It is fairly obvious that I am not uninfluenced by Peter Landin and Christopher Strachey. Finally I should like to record (as I remember it quite distinctly) how Heinz Zemanek at the pre-ALGOL meeting in early 1959 in Copenhagen quite explicitly expressed his doubts whether the go to statement should be treated on equal syntactic footing with the assignment statement. To a modest extent I blame myself for not having then drawn the consequences of his remark
The remark about the undesirability of the go to statement is far from new. I remember having read the explicit recommendation to restrict the use of the go to statement to alarm exits, but I have not been able to trace it; presumably, it has been made by C. A. R. Hoare. In [1, Sec. 3.2.1.] Wirth and Hoare together make a remark in the same direction in motivating the case construction: "Like the conditional, it mirrors the dynamic structure of a program more clearly than go to statements and switches, and it eliminates the need for introducing a large number of labels in the program."
In [2] Guiseppe Jacopini seems to have proved the (logical) superfluousness of the go to statement. The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.
References:
- Wirth, Niklaus, and Hoare C. A. R. A contribution to the development of ALGOL. Comm. ACM 9 (June 1966), 413-432.
- BÖhm, Corrado, and Jacopini Guiseppe. Flow diagrams, Turing machines and languages with only two formation rules. Comm. ACM 9 (May 1966), 366-371.
Edsger W. Dijkstra
Technological University
Eindhoven, The Netherlands
分享到:
相关推荐
他的经典言论揭示了他对编程艺术的独特理解和对计算机科学本质的深刻见解。 1. **编程的艺术是处理复杂性的艺术**:Dijkstra强调了编程的核心挑战在于如何有效地管理和简化复杂性。在编写代码时,程序员的目标是...
这些论文是该领域的精华,被广泛引用并荣获了Edsger Dijkstra Prize,这奖项旨在表彰在分布式计算理论方面做出杰出贡献的学术工作。下面将对这些论文进行简要介绍和分析,展示它们所涵盖的关键知识点。 1. ...
这个算法的名称来源于它的发明者,荷兰计算机科学家 Edsger Dijkstra。以下是Dijkstra算法的详细介绍: 基本思想 Dijkstra算法以起始点为中心向外层层扩展,直到扩展到终点为止。 在这个过程中,始终保持从起点到...
Dijkstra算法,全称为迪科斯彻算法(Dijkstra's algorithm),是一种用于图搜索问题的算法,由荷兰计算机科学家艾兹格·迪科斯彻(Edsger Dijkstra)在1956年提出。该算法主要用于在加权图中找到单个源点到其他所有...
Dijkstra算法是由荷兰计算机科学家Edsger Dijkstra于1956年提出的,它是一种解决单源最短路径问题的有效方法。在MATLAB中,我们可以利用Dijkstra算法来找到图中所有点之间的最短路径。 Dijkstra算法的基本思想是...
Dijkstra算法是图论中一种经典的最短路径算法,由荷兰计算机科学家艾兹格·迪科斯彻(Edsger Dijkstra)于1956年提出。该算法主要用于解决单源最短路径问题,即从图中的一个顶点(源点)出发,找到到达其他所有顶点...
该算法是由荷兰计算机科学家Edsger W. Dijkstra于1959年提出,目的是为了寻找图中的最短路径。 在计算机网络中,Dijkstra算法通常用于路由更新路由表。路由更新路由表是指路由器在接收到新的链路状态信息后,重新...
在 Rust中 Edsger Dijkstra 的Shutting-yard 算法的示例实现。 此实现处理: 二进制+, -, *, /, 和^(指数)运算符 一元+和-运算符 括号 关联性(大多数运算符左侧,取幂右侧) 分流 Rust 包括一个基于正则表达式...
银行家算法(Banker's Algorithm)是一种避免死锁和确保系统资源分配安全性的算法,由艾兹格·迪杰斯特拉(Edsger Dijkstra)提出。这个算法是在操作系统中用来管理多个进程请求和使用有限资源的一种方法。它被称为...
Dijkstra算法是一种经典的最短路径算法,由荷兰计算机科学家艾兹格·迪科斯彻(Edsger Dijkstra)于1956年提出。它主要用于寻找图中从一个顶点到其他所有顶点的最短路径。在本示例中,Dijkstra算法结合了C++的STL...
Dijkstra 算法是解决图论中最短路径问题的一种常用算法,由荷兰计算机科学家 Edsger Wybe Dijkstra 于 1959 年提出。该算法可以用于寻找有权图中从一个节点到其他所有节点的最短路径。 在给定的 Matlab 程序中,...
In computer science, Prim s ... Prim in 1957 and rediscovered by Edsger Dijkstra in 1959. Therefore it is also sometimes called the DJP algorithm, the Jarník algorithm, or the Prim–Jarník algorithm.
Dijkstra)在1956年提出,是解决单源最短路径问题的经典方法。在游戏开发、网络路由、地理信息系统等领域有着广泛的应用。 该算法的核心思想是从起始节点开始,逐步扩展到相邻的未访问节点,每次扩展时选择当前可...
**Dijkstra算法**是图论中的经典算法之一,由荷兰计算机科学家艾兹格·迪科斯彻(Edsger W. Dijkstra)于1956年提出,主要用于解决单源最短路径问题。该算法从一个源节点出发,逐步扩展最短路径,直到遍历到图中的...
Dijkstra算法,由荷兰计算机科学家艾兹格·迪科斯彻(Edsger W. Dijkstra)于1956年提出,是一种解决单源最短路径问题的有效算法。在图论中,这个算法主要用于寻找网络中从起点到终点的最短路径,特别适用于加权有向...
Dijkstra算法,由荷兰计算机科学家艾兹格·迪科斯彻(Edsger W. Dijkstra)于1956年提出,是一种用于寻找图中两个节点间最短路径的著名算法。在计算机科学中,尤其是在图论、网络路由和路径搜索等领域,它扮演着至关...
Dijkstra算法是一种经典的图论算法,用于寻找图中两点间的最短路径。在这里,我们将深入探讨这个算法及其在C++和MATLAB中的实现。 Dijkstra算法是由荷兰计算机科学家艾兹格·迪科斯彻(Edsger Dijkstra)在1956年...