博文
计算机前辈Dijkstra被采访的视频中，摘录的部分字幕
|||
if in physics there's something you don't understand...
...you can always hide behind the uncharted depths of nature.
You can always blame God.
You didn't make it so complex yourself.
But if your program doesn't work,there is no one to hide behind.
You cannot hide behind an obstinate nature.
A zero is a zero, a 1 is a 1.
If it doesn't work, you've messed up.
I realized my previous projects had just been finger exercises.
I had to tackle complexity itself.
But it took a long time to muster the courage to do so.
At the end of the 60s, Dijkstra saw that the complexity...
...got the better of programmers.
And that it threatened the most prestigious projects.
That happened in 1969...
...just after the first successful moon landing.
I was at a NATO conference on software engineering in Rome...
... where i met Joel Aron, who was head of IBM's Federal Systems Division...
...which had been responsible for the software of the moonshot.
I knew that each Apollo flight required some 40,000 new lines of code.
I don't know what unit a line of code is...
...but 40,000 is a lot.
I was duly impressed that they got so many lines of code correct.
D--So when I met Joel, I said:"how do you do that?"
J--Do what? he asked.
D--Getting that software right.
J--Right? he said.
He said that in one of the caculations of the orbit of the lunar module...
...the moon had been defined as repelling instead of attracting.
They had discovered that error by accident...
Imagine, by accident...
... five days before the shot.
D--I went white and said:"Those guys have been lucky!"
J--"Yes", Joel Aron agreed.
Program testing can convincingly show the presence of bugs...
...bug it is hopelessly inadequate to show their absence.
Dijkstra knew personally how fright-engingly complex programs could become.
He had finished the operating system of Holland's biggest computer, the X-8...
under great pressure.
I feared that I wouldn't get it right.
That I would lose control of it.
For the X-8 in Eindhoven...
...we tried to design a multiprogramming system.
We ware working with a machine with a real-time interrupt...
...which really means that you cannot test your program.
(the old machine with no keyboard)
I knew that if we designed the program with insufficient care...
...we would end up with something...
...which, once entered into the computer...
...wouldn't work, and would make irreproducible errors...
...the cause of which we would be unable to determine.
That was the reason...
why we applied all possible control mechanisms in the development stage.
Elegance is not a dispensable luxury...
...but a factor that decides between success and failure.
One of the things I discovered as early as the 1960...
...is that mathematical elegance...
...is not a question of esthetics, of taste or fashion...
...but something you can translate into a technical notion.
The Concise Oxford Dictionary gives as one of the meanings of 'elegant'...
...'ingeniously simple and effective'.
In practice a program is manageable...
...if you make a truly elegant program...
...firstly because it is shorter than most alternatives...
...and consists of discrete parts...
...each of which you can replace by an alternative implementation...
...without influencing the rest of the program.
But also, curiously...
My first programming years were a bit strange compared to now...
...in that I programmed for non-existing machines.
My friends Bram Loopstra and Carel Scholten built the machine...
...and in the meantime I wrote the relevant software.
I was used to not testing a-program...
...because the machine to test it on wasn't finished.
I knew right away that you had to create something...
...that you could keep under your intellectual control.
https://blog.sciencenet.cn/blog-643407-512803.html
上一篇：vim+gdbvim PostgreSQL 9.1调试环境搭建
下一篇：Postgres中有关GiST索引的某些调用流程
