Thinking like masters -- starting with "When will UML die ?"

I got a chance to ask Ivar: "When will UML die ". I have no intention to use this question to express my preferences to embarrass the masters, because it is a problem I have been thinking about. Solving problems with the father of UML is naturally the best. Ivar did not think that I was embarrassed by him. His sincere answer made me think deeply at that meeting. He said: "When does the object-oriented program die, UML will die ". A question looks complicated, but its answer may be very simple. An answer seems very simple, but it may be the most correct. A correct answer may be meaningless, but it may be the answer of the master.

 

Many of the things we seem to be taking for granted now have plagued masters. For example, we all know Program The basic logic of is sequence, branch, and loop. So, "why is order, branch, and loop the basic logic "? "As the basic logic, are they full ?" Who can answer me? How to answer me?
Is this a difficult problem? We know the answer, but even if we know the answer, we don't know why ". However, the real masters have demonstrated this problem. Edsgar wybe Dijkstra, the master who proposed "harmful to", wrote a "Note" for this ". How did he prove it? He said there are three ways of thinking that computers can understand. Enumeration, induction, and abstraction. However, it is important that Dijkstra further states that branch (IF) is a computer-based enumeration method and loop (for) is a method for induction. When He further explained "abstraction", he said, "At this stage, I find it difficult to clearly define the role of abstraction ".
Dijkstra is probably ready to complete this notebook. He proved "How and why can enumeration be implemented for branches" through mathematical methods ". That is to say, whether the branch is complete for the idea of "enumeration. Dijkstra wrote a lot of mathematical reasoning and said, "The above heavy proof also makes me feel worried! However, if I really want to prove the correctness of this program, I do not have a better solution ." Dijkstra argues that "in the past, the absurd proofs of the first Theorem in plane ry often make me feel the same anger, because the things demonstrated by these theorems are almost the same as those of the Euclidean principle itself '".
Oh! The reason for Dijkstra's anger lies in the fact that it seems so "obvious" and "taken for granted", but it needs to be proven by a very cumbersome process! It is as though we knew "1 + 1 = 2", but it proved to be boring and resentful. The proof process like Dijkstra laid the foundation for the discipline "program correctness proof". The proof result shows that the program structure is limited, such as order, branch, and loop. This theory of "limited structure" has created an era of "Structured Programming. In 《 Code In the preface, "We are still in this age and do not perceive the profound influence of this book ."
Yes. Because of the so-called "Object-Oriented Programming", its foundation is "Structured Programming + high-level abstraction in structure ". This "high-level abstraction" is "object ".
Dijkstra completed this note around 1970, and we have not escaped the original thought of the master for the next 40 years. However, the original creative idea of the master can be attributed to one sentence: "One of the three ways of thinking that can be used to understand a program, I mention the following: enumeration, mathematical induction, and abstraction." Why are these three types? Are there only these three types? Can there be more? The master did not explain it. He just "mentioned the following three types. Dijkstra left us space on the one hand. On the other hand, his "arguments" are complete enough to show that the basic logic must have at least "Order, branch, and loop ". In the past 40 years, there has been no breakthrough.
Ivar regards the death of UML as an abstract failure, or it is replaced by a higher abstraction. It is extremely correct, because UML is also built on the theory of some elements such as structured and abstract. Dijkstra's Reading Notes are included in the book "structural programming". The other two articles in the book are "hierarchical structure design" and discuss object-oriented programming; another article is "Data Structure notes", which discusses basic data abstraction. Department 3 Article The three Turing prize winners, a 40-year-old age, and 1/2 of the programming language categories, all bear this impact. However, Dijkstra still cannot argue, or has never explained "the uniqueness of the three basic logics". He just assumes "I think.
It also started with "I think", and there were Turing machines. If a hairy boy jumps out, "I think" the computer should be like a big stupid elephant eating pasta; a big stupid elephant needs a belly and a punch in the noodles. Oh, good. This boy will immediately be put out of the holy Hall of computer science. The problem is that Turing is such a hairy boy. Therefore, his idea is called "The creative idea of heaven ". But is it true?

the Abacus has been used for thousands of years. Who asked "Why can an abacus count "? Are these things basic storage structures, such as abacus, carry, and column? If we use an abacus, is it a computing unit? Is the abacus table an operation rule? The "0 ~ 9 ", is it the input/output interface? "We + abacus" is a complete computing system. The integrity of this computing system is explained by Turing using an assumption. Turing is simply describing a fact in an imaginary way, And the fact "looks" can be implemented by machines. So our computer age began. Does Turing prove "why is it a complete computer system to eat pasta? No, it is often difficult to prove initial problems. Often, his proof process or application process only triggers an imagination. Many of my thoughts on fundamental computer problems will be traced back to the level of philosophical thinking. Iopd and pdio problems, such as program = algorithm + structure problems. There are also some issues that can be traced back to human behavior and linguistics, such as language, syntax, semantics, and whether or not there is a pragmatic problem. Most of the time, what actually promotes computer development is not reasoning and solving specific problems, but abstracting the problems themselves. In the description of Dijkstra, abstraction is more like a weapon. According to Brooks, "the representation of data (data structure, one of the abstract results) is the foundation of programming." According to Dijkstra, "citing uninterpreted terms to describe the principle or theorem and the parallel similarity between the two (name-based) operations acting on unresolved operands ". In any case, we "Create a computer" for two purposes. One is "Let it calculate mathematics", and the other is "Let It think like a person ". Note: I do mean "computing mathematics". Mathematics is a theoretical discipline of mankind, "how to calculate", and the computing content. It is all set by ourselves. The ability of a computer is nothing more than the unknown object of "Mathematics. In fact, the "imperative" and "functional" or "declarative" that we are talking about now are just the "most basic calculation methods" we have set for computers ". In this "Computing System", "Mathematics" is not initially set.

How to compute by command, how to compute by function ...... If you have a clear understanding of this issue, we will also understand this type of language. Next we will talk about higher-order functions, currying, continuation, or generator-iterator, that is already the representation of a specific language, not the essence of "this type of language. For example, JavaScript 1.5 has not implemented a "generator object", but no one denies that it is a functional language. Conversely, the generator object is not an essential element of functional language. Lisp expresses all the "essential elements" of functional languages. However, the seven atomic operations of Lisp are also aimed at the structure abstraction of "list. For a "(sequential) Table", these seven atomic operations are required, and for another "(relational) Table", this is not necessarily the case. Therefore, these atomic operations do not need to be placed in the essential elements of the functional formula. The appearance of implementation methods for functional languages like Lua also proves this (3 ).

What are the remaining functions?

Is it necessary to learn a language or a language to really understand the secret of the function? Is it an operation method or an operation method to learn? After hearing the saying "continuous", we began to understand continuity, without asking why it appeared in the functional formula? Or is it necessary for a function? Or is it a "problem" of the function compute system itself "? We were lost in the appearance of various languages and concepts, and finally failed to think like a master about the abstract level of "computer is nothing more than eating pasta.

What we want to change is our thinking, and what we want to enhance is our ability. Most people only enhance their abilities without changing their thinking. That's why "we"-most people are not masters.
Thanks to Ivar. It's not just because he gave the answer to a question and his modesty and smile, but also thanks to him for telling us that the answer is not a false positive. The real answer is the reflection behind the answer.

Yes.

Original: http://blog.csdn.net/aimingoo/archive/2008/10/09/3037952.aspx