note for Bjarne

source

The key questions are always: "What do I want to do?" and "How do I know that I have done it?".


Strategies for testing enters into my concerns from well before I write the first line of code, ...

... often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable.

The purpose of a progamming language is to help build good systems, where "good" can be defined in many ways. My brief definition is, correct, maintainable, and adequately fast. Aesthetics matters, but first and foremost a language must be useful; it must allow real-world programmers to express real-world ideas succinctly and affordably.

Also, complainers are always louder an more certain than proponents - reasonable people acknowledge flaws. I think I know more about the problems with C++ than just about anyone, but I also know how to avoid them and how to use C++'s strengths.

We need relatively complex language to deal with absolutely complex problems. I note that English is arguably the largest and most complex language in the world(measured in number of words and idioms), but also one of the most successful.

This leads to a constant pressure on users not to use the most powerful C++ features and to myths about why they should be used "carefully", "infrequently", or "by experts only". That, combined with backwards-looking teaching of C++, has led to many failures to reap the potential benefits of C++ as a high-level language with powerful abstraction mechanisms.

"class-oriented programming"

Reasoning about the behavior of a program has to be rooted in the (static) structure of the source code. The focus should be on guarantees, invariant, etc. which are closely tied to that static structure. This is the only way I know to effectively deal with correctness.

Testing is essential but cannot be systematic and complete without a good internal program structure - simple-minded blackbox testing of any significant system is infeasible because of the exponential explosion of states.

So, I recommend people to think in terms of class invariants, exception handling guarantees, highly structured resource management, etc. I should add that I intensely dislike debugging (as ad hoc and unsystematic ) and strongly prefer reasoning about source code and systematic testing.

Pros: flexibility, generality, performance, portability, good tool support, available on more platforms than any competitor except C, access to hardware and system resource, good availability of programmers and designers.

Cons: complexity, sub-optimal use caused by poor teaching and myths.

Done is better than perfect.
原文地址:https://www.cnblogs.com/zhaorui/p/20080106_note_for_Bjarne.html