各位读者，看到Dijkstra，是否觉得特别熟悉？是不是想到了Dijkstra最短路径，GOTO有害论，信号量和PV原语，银行家算法，哲学家就餐问题？今天从谦卑的程序员谈起，和科技创业者聊聊，一起思考谦卑如何让我们做好科技创业工作。

图片来源：The humble programmer | ACM Turing award lectures

也可以访问

E.W.Dijkstra Archive: The Humble Programmer (EWD 340)

1 The Humble Programmer

图灵奖获得者荷兰计算机学家Edsger Wybe Dijkstra在1972年8月14日的获奖演说“谦卑的程序员”(The Humble Programmer)中，探讨了程序员心理与计算机编程之间的关系。 Dijkstra一直强调，编程的本质任务就是驾驭计算机科学的极端复杂性。他认为编程是唯一要求掌握最底层到最高层的9个数量级上细节差异的人类活动。演说中他肯定了Fortran,Algol, LISP等语言，而对于PL/I，他认为是失败的。他在演说中强调如何建立可靠的软件，如何在编程时就尽力避免引入错误，而不是以后再去消除错误，这不单是具有技术上的意义，而且在经济上十分重要。狄克斯特拉的上述观点赢得了愈来愈多的人的理解和支持。在五十年后的今天，很多见解仍然是真知灼见。

图片来源：Edsger Dijkstra quote: The competent programmer is fully aware of the strictly limited...

Dijkstra因为最早指出“goto是有害的”以及首创结构化程序设计而闻名于世。他对计算机科学的贡献非常广泛，在程序设计技术、算法和算法理论、编译器和操作系统诸多方面都有很多创造。他发表的题为“智力低下的程序员”(The Humble Programmer)的图灵奖演说，刊于Communicationof ACM，1973年10月，859~866页。也可见于《前20年的ACM图灵奖演说集》(ACM Turing Award Lectures-The First 20 Years:1966-1985, ACMPr.)17~32页。

下面是重要的一些言论。

Those who want really reliable software will discover that they must find a means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper.

We should confine ourselves to intellectually manageable programs.

We must not forget that it is not our business to make programs; it is our business to design classes of computations that will display a desired behaviour.

It is a usual technique to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

The question: "Can you code this in less symbols?" or, "Guess what it does?" - as if this were of any conceptual relevance!

As long as machines were the largest item in the budget, the programming profession could get away with its clumsy techniques.

As a result of a long sequence of coincidences I entered the programming profession officially on the first spring morning of 1952, and as far as I have been able to trace, I was the first Dutchman to do so in my country.

We must be very careful when we give advice to younger people: sometimes they follow it!

The major cause [of the software crisis] is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. In this sense the electronic industry has not solved a single problem, it has only created them, it has created the problem of using its products.

FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes.

LISP has been jokingly described as "the most intelligent way to misuse a computer". I think that description a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.

When FORTRAN has been called an infantile disorder, full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease.

If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with.

Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.

Compare more succinct phrasings cited above.

The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer.