This book also tells you about the commonalities, differences, strengths, and pitfalls of these languages and gives you an honest appraisal of how they measure up to what you need to write quality software. This book is a critical look because it is critical that we address the issues that continue to make programming an unnecessarily difficult task; that is, a look into aspects of current programming practice that ensure the continuation of the “software crisis.” In doing so, it is critical of many aspects of popular programming languages, and as such it delivers a message that will not be well received in some quarters. However, we must realize that no technology is absolute. We must throw down the gauntlet in order to progress.

This book will not teach you any of these languages in themselves, as it concentrates on features they have in common or how they are different. This book will give you a deeper understanding, as I have gained over the years of developing it, of programming language features, not only of the languages presented here, but of many others as well, and of the many controversies and arguments, mostly bogus, that programming languages give rise to.

Many books on programming languages are guides of how to avoid the traps and pitfalls of the language. Of course, many new programmers want to learn these secrets in order to enter the ranks of expert programmers, and there is no shortage of books to capitalize on this desire. Warnings of potential traps is particularly the case with C++ literature, where Bjarne Stroustrup’s books give many warnings, and Scott Meyers’ books give even more, but they tend to justify C++ in that, if you know about these problems, everything will be all right. This book takes a different and perhaps less popular view, that warnings are not enough; languages must be designed from the ground up to be more solid. Car purchasers would not be impressed if the dealer warned that a car occasionally violently jerks to the left: if driving on the road from Amalfi to Sorrento, they would suddenly meet their doom. This book seeks to cut through the language and object-oriented (OO) hype and get to the truth about both.

One way hype becomes established is that people tend to fall in love with technology too quickly. We love our computers for the power we perceive they can give us. We particularly fall in love with the first technology we use. It is natural to love our first car, but the time comes when we must move on or be stuck with something that costs a fortune to maintain. This is of course what the enthusiast wants, but it is not appropriate for those who want a car just as a practical means of transport. The computer industry is already paying heavily to retain technologies well beyond their use-by date, an example being the year 2000 (Y2K) problem.

People also like to follow technologies that become well established, because they give a sense of belonging to a larger cultural group. This is not necessarily a bad phenomenon, except where the larger cultures overrun smaller groups, and where adherence to one technology damages new technologies and stifles innovation. This has often been a problem in science where protection of established false beliefs has often been used protect a power base. In computing, these power bases are particularly strong and financially lucrative. One thinks of Galileo as the quintessential victim of this phenomenon; the perpetrators of Galileo’s suffering were the most respected and “wise” people of the time.

This book takes the approach that technology must be constantly reevaluated in order to be improved; we must see and admit the flaws in our current technologies no matter how passionate we feel about them. Observed flaws, of course, come as a bitter pill to some who will throw up no end of smoke screens to cover the fact. Such defense is the basis of the religious wars that have become common in the industry, and these religious wars undermine the professionalism of the industry. This book focuses on the technology of programming languages and takes three well-known languages as a basis for its comments. Other technologies, as well as the hype that is present in the industry, also need reevaluation.

Hype is very valuable to marketeers in raising the public’s consciousness of a particular product. I recently heard a fashion industry marketeer state, “A white shirt is a white shirt; but a hyped white shirt is a white shirt you want to buy.” We should not condemn those who use hype, since it is natural to resort to hype in a market where some products dominate due to strongly held loyalties, but we should not allow these loyalties or hype to prevent proper evaluation of technologies. The computer industry is an industry where the most strongly held loyalties can be observed; as consumers it is our responsibility to beware that hype is often used to create the illusion that something is what it is not.

The main goal of this book is to compare three languages: C++, Java, and Eiffel. To my knowledge, no other book compares languages in this way, although I can appreciate why as it is not a simple exercise. Originally, this was a paper only on C++, but when Java appeared it addressed many of the problems of C++, so a direct comparison of Java and C++ seemed like a good idea. Since I had started on Java, comparisons to other languages also seemed like a good idea. Eiffel was an obvious choice, since in many ways it is comparable to C++ and Java. I wanted to do others like Smalltalk, Beta, and Oberon, but these languages are somewhat different again, and three languages already provided more than enough material.

Another unique aspect of this book is that it takes a practical look at language features and how they relate to productivity on a software project. My purpose has not been to produce an academic treatise or thesis on the theoretical aspects of languages, but to give practical reasons as to why certain language features are good or bad, or may lead to problems. Sometimes this ties in with theory, and it is my opinion that theory exists only to make practice easier and to enable things we have not previously thought of. Theory is not a straightjacket to constrain us; rather theory enables new things.

Many people are starting to feel burnt by the overenthusiastic adoption of what is known as object-oriented technology. My own start in OO was at Sydney University where we had an honors class presented by Professor Jan Hext on data abstraction, and in part of this class we learnt Simula. I was impressed by this language, as many others have been, including Bjarne Stroustrup and Alan Kay. Several years later I went on to do several large projects using Object Pascal. It was during one of these projects that C++ came to my attention, so I enthusiastically bought Bjarne Stroustrup’s first edition of The C++ Programming Language. As I read this I felt somewhat ill at ease, as concepts that I was very familiar with seemed to be buried somewhat beneath complexities that I, as an experienced OO practitioner of several years, had difficulty understanding. At this stage C++ was very simple compared to the C++ of today. Originally, C++ offered no real advantages over Object Pascal, as it then did not have multiple inheritance, templates, and so on. I did not want to judge a language without practical experience, as I reasoned that practical experience would probably make sense of some of the obscurities very quickly.

It was also around this time that Brian Henderson-Sellers recommended to me a book called Object-Oriented Software Construction by Bertrand Meyer. I found this book a very enjoyable read because it examined what the real objectives of software engineering are and then gave solutions. It explained much about what had gone right and wrong in my previous projects. One thing annoyed me about the book—it introduced yet another programming language that Meyer called Eiffel. I really wanted something that explained OO like this, but that applied it to languages I knew, like Object Pascal and the newer C++. I thought Eiffel was a bit like Knuth’s Mix assembler language in his Art of Computer Programming series. I did not like having to cope with yet another language. However, as I progressed through the book, I discovered that Eiffel was so clean and simple that it did not prove a distraction at all. Even though I made no real effort to learn it, by the end of the book, I felt it was quite familiar; not only that, but I had learned new advanced OO concepts like multiple inheritance, genericity, and garbage collection, which neither Object Pascal nor C++ offered at that time.

The opportunity to use C++ for real came while I was working for Unisys Corporation. A large project, UNIX X.500, had been done in C++. Even then, C++ was still quite primitive, with no multiple inheritance, templates, and such, and compilation was done with the CFront preprocessor. My colleagues had little experience with OO other than C++, but were enthusiastic that C++ was the ultimate language and said that I had not really done OO until I had done C++. It was not long before I found out why I had been ill at ease reading Stroustrup’s first edition. Practical experience did not explain the previously noted obscurities but turned up many pitfalls. After just a few weeks, I had two pages full of point notes of problems I had found. After a few months I wrote this up as a report and submitted it to an internal Unisys newsgroup. A few people who had been pushing C++ in their own departments came out in defense of C++. They really prompted me to find more flaws, and the paper became quite long. I then submitted it to Internet news groups in early 1992. Again this went through the test by fire, which gave me many more ideas. So I completely revised it into a second edition and resubmitted it to Newsnet in late 1992.

After 1992 I decided that I had spent enough time on this project and that I wanted to stick to software engineering. However, in 1996 I started to examine Java, which claimed to avoid the problems of C++, and, as mentioned earlier, this inspired me to reexamine my earlier evaluation of C++ in comparison to other languages. Thus the third edition of this critique was published on the Internet in late 1996.

After the third edition was published, many people commented that I didn’t really go far enough; there were many other problems in C++. They gave me lectures on some of the other problems and pointed me in other directions to research. They were right, and I found several sources of new material and things I hadn’t thought about before. I began adding this material to what was to become the fourth edition, but the paper was getting very long. When I restructured it into book format, I found it was over 150 pages, so I decided it could be possible material for a book. If you have read the previous three editions, you will find that the book preserves a lot of the original material, but rearranges it into a more logical learning order, and it adds a lot of fresh material—I hope you like the result. So it is worth buying, or at least borrowing from a friend.

One lesson I learned from this is that professions can afford to be far more self-critical. It seems that doctors are very willing to submit patients to procedures that they themselves might be reluctant to undergo. Many medical practices are inherently dangerous, and yet research is very slow to investigate alternatives. Many medical practices are based around fixing problems after they have happened rather than assessing a patient’s whole lifestyle to effect prevention in the first place. No wonder so many are turning to alternative medicine. The problem with this is that there is never a shortage of charlatans hoping to cash in. But there is truth behind such alternatives, which old professions too readily deny.

Unfortunately, the computing profession is also involved with safety and with enterprises that are critical, and yet too many computer professionals are unwilling to explore and encourage alternatives. If the human race is to continue to improve, then we need more resources spent on research, and everyday practitioners should become far more open-minded than they are now.

Professions are also overburdened with rules; unfortunately they are for the most part not the right ones. An example of this is secondary rules that make up for some deficiency in another rule or process, instead of addressing the root cause. Of course, this does not mean that we don’t need safeguards against fraud in professions and against those whose prime motive is to make money for very little effort.

The fact that many in computing defend the status quo with deeply flawed arguments shows that we have still very far to go.

Hinweis: