Fish is the last one to see water

Fish is the last one to see water

 

By Liu weipeng (pongba)

C ++'s Luo Yun (http://blog.csdn.net/pongba)

Toplanguage (http://groups.google.com/group/pongba)

 

Is your light on? The last page shows a pair of large color inserts:

Fish always see water at the end.

In fact, there are many extensions to this sentence. The most famous one is:

If you have a hammer, everything looks like a nail.

However, the meaning of the last sentence is misleading, because the expression of this sentence is easy to touch the essence of the problem: that is, everything looks like a nail, because peopleTends to solve problems in the existing framework; More importantly,In this process, it is difficult to perceive the existence of framework constraints.Just as the fish cannot detect the existence of water. The essential reasons behind all these are:

People have strong adaptability.

This proverb should be one of the motto of the problem solver: ignoring the constraints of existing frameworks can easily lead to sub-optimal solutions.

Ordinary people follow the rules, and the good people ignore the rules and create rules by great people.

To ignore or even create rules, you must first know the existence of the rules. The recent "Journey" event demonstrates this point well: Many people will solve the problem under the existing framework, and it is difficult to realize the existence of the framework and break through it.

It is reflected in the programmer industry, and there are also many interesting phenomena:

#1 design mode

Design pattern has been regarded by many beginners as the guiding principle. It is worth learning to think that the exquisite things look really amazing. What's more, a smarter person may even learn things that are not complex enough, because the more complicated the things are, the more fulfilled they are. However, the fact is that,There are many people who make simple things complicated.Complex things are simpleThe man is very rare.

As mentioned in design patterns, most of the patterns are built on the premise of Smalltalk/C ++. This premise (framework) is unfortunately thrown into the wind by everyone, and those patterns are generalized to a universally applicable principle. The boss of Peter norvig has a famous PPT, which mentions that 16 of the 23 patterns in design patterns are placed under dynamic languages (especially lisp), and there is no such pattern at all, it is an obvious task that can be completed without any effort. The elders at C2 further generalized Peter norvig's remarks and proposed that "the design pattern symbolizes the lack of built-in support for languages, it also lists a comparison table of "Design Patterns <=> language features. Jeff of codinghorror is also blended with each other. He says, "design patterns are actually Roadways of language evolution." (a large number of repeated use of design patterns means that they should be integrated into the built-in support of languages ).

In any case, one thing is certain, that is, the built-in support (concise) of first-class is always better than the patch-type solution (winding around ). The new version of JavaScript adds direct support for multi-method (visitorpattern) -- generic function -- is an excellent example. Of course, rubyers certainly won't forget to follow lispers to call a closure method to handle all Iteration Processes, defeat the clumsy iteratorpattern in an all-round way, and drop Java in the stone age by the way.

All in all, there are serious problems with the design pattern's qualitative nature. Many people regard the design pattern as a sophisticated weapon, just as they are capable of solving mathematical problems. In fact, the design pattern is a patch, which often means that the language is not powerful enough. Its use means a large number of sample code irrelevant to the programming purpose to be achieved.

The famous head first series "head first design pattern" is also a solemn reminder in the near-ending part of the book (Jeff thinks this reminder should be placed in the front of the large font ):

Do not think that the design mode is not good enough or powerful enough. It is king to complete the task in the simplest way possible.

(But it is worth noting that simplicity does not mean embarrassment .) This is also true for the so-called code-free, code-free, and design model.

#2 Language Competition

Language competition is a permanent topic of the programmer community. Flame war is a trigger. One of the reasons for the language competition is that people are easy to think under the language framework they are familiar with, and form a serious bias, only to see the advantages of their own language, even those that are not good are aware of the benefits.

#3 Use of Languages

The more familiar a programmer is with a language, the more tired it is. For him, the characteristics of this language are fish water and woodworking hammers. When a problem occurs, some language features will first pop up in your mind, with both solutions available. Of course, in the statistical sense, this is not a bad thing. It may be helpful to solve the problem quickly most of the time. However, in those 20% cases, the harm caused by such ideas may be 80%.

For example, programmers familiar with Java/C #/C ++ may think that the concept of "iterator" is very intuitive and even very beautiful; and the book introducing this concept will certainly not come up and give yourself a piece of cold water to say that the appearance of the iterator is really no way to patch. Therefore, we feel that this is a wonderful thing, because many times we use "enough" to define good or bad. As long as it is still usable, we can feel "good ". However, in fact, as mentioned above, I will refer to the iterator pattern section in design patterns, and then the chapter on iteration In the examples header, we will find that a simpler iteration scheme does not need to define additional iterator classes and inheritance systems at all.

Another good example of thinking being constrained by language is "API Archaeology: C-style Java API", which mentions that a guy designed such a Java API:

Int enumerate (thread [] list); // list all the threads in the current threadgroup

The best way to avoid thinking from being bound by a language is to "learn other languages ".

#4 C ++

C ++ is added for two reasons. I. This blog used to write c ++. II. C ++ has special characteristics in all languages. In C ++, there are countless idioms and techniques. Countless books describe these technologies with the spof of countless bits and bring them to perfection. However, I recently asked two questions in a "one-to-one" Interview with Bjarne's boss (interview with the en edition:

1. What is the first principle of learning C ++?

2. What is the first principle of using C ++?

What is the answer?

1. What is the first principle of learning C ++?

Focus on basic (Fundamental) concepts and technologies, rather than specific language features, especially the detailed language details in C ++.

Someone will ask, is it still called learning C ++? Learning a language naturally starts with its language features, right? Otherwise, where can I start? The key to this problem is to realize that we certainly need to master the language features, but the focus is to see the concept of supporting design and programming (concept) behind the features from the language features ). For example, the concepts supported by classes, inherited concepts supported, supported concepts supported by virtual functions, and supported concepts supported by templates... the general conclusion of this argument is that learning programming focuses on learning basic concepts and accomplishments. These are things that remain stable for a long time. If you devote yourself to learning specific details, the finer you learn, the easier it will be to eliminate them. Bjarne's statement is: Once you have mastered the basic concepts and need to use the details, the details will naturally be fall into places.

2. What is the first principle of using C ++?

Change your(Pongba Press: language-independent)The design concept (concept) is directly mapped to a class or template in C ++.

That is, I suggested in my article a while ago, "Do not think about the language and use the language to implement it ". The advantage of language thinking is obvious: it can avoid being disturbed by language details as an existing framework, and avoid being entangled in implementation details too early, so it is easy to find the most intuitive solution, even if you find that the language has become a stumbling block, you can change the language or clearly know what trade-offs you have made.

Conclusion

Think out of the box.

Related posts

From tag Programming

• Toplanguage group discussion Selection [4] (2007.12-2008.1)
• Beautiful code and beautiful team-preface to beautiful code (personal)
• Joel Spolsky has no responsibility to give a speech at Yale.
• Toplanguage group discussion Selection [3] (2007.11-2007.12)
• Toplanguage (2007.10-2007-11)
• Error-handling: why, when, and how
• Toplanguage discussion selections (2007.8-2007.10)

From tag essay

• Negative Environment
• East-West reading: Reading Notes on Walden Lake (1)
• Why are we so easy to get cheated?
• Reading the years of Gu Long (1)
• About Mr. Tan haoqiang's c ++ Programming Tutorial

(More ..)