Browse Books

From the Book: PREFACE: Why Should We Be Concerned 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 veryfarto go. It is not enough that you should understand about applied science in order that your work may increase man's blessings. Concern for man himself and his fate must always form the chief interest of all technical endeavours, concern for the great unsolved problems of the organization of labor and the distribution of goods-in order that the creations of our mind shall be a blessing and not a curse to Mankind. Never forget this in the midst of your diagrams and equations. -Albert Einstein Address, California Institute of Technology, 1931 Preface No doubt, right now you are standing in a bookshop deciding why you would want to buy this book instead of the plethora of other books you see on the shelf in front of you on C++, Java, and, to a lesser extent, Eiffel. Or you might have already bought it and wonder why you should read on. But this is just the preface, right And nobody reads the preface unless they are standing in a bookstore, so you can probably buy it now and save reading the rest of the preface! This book gives you three books in one, and it is no longer-and probably even shorter-than many of the single books. I share with many readers the experience that we don't very often make it through one of those 500-page megavolumes. 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. Structure of the Book Throughout this book we will follow a top-down course through the object-oriented paradigm, examining each of the languages in turn, drawing attention to their differences, strengths, weaknesses, and problems. In chapter 1, we examine some principles and concepts that will be useful in coming to some conclusions as to how our languages are suited to the task: without knowing what to expect of modern-day programming languages, we won't be able to form any opinions. Chapter 2 starts at the top of object-oriented languages, looking at objects, classes, and the basic entities in OO languages. Chapter 3 looks at the concept of modules, or how the basic entities are grouped in our languages, and how groups of classes can be packaged together. Chapter 4 examines the insides of these entities: the features. Chapters 5 and 6 examine how to use the basic entities to construct larger systems; that is, how to compose the entities with inheritance in chapter 5 and genericity in chapter 6. Chapter 7 covers the features providing exports and access control, how interfaces are defined, and how access to the implementations of classes is prevented. Chapter 8 examines how objects are initialized and destroyed, and looks at various other operators as well. Chapter 9 deals with casts and how they are not needed in well-defined type systems. Chapters 10 and 11 look at some compile-time and run-time issues. Chapter 12 contains some miscellaneous issues that do not fit in other chapters. Chapter 13 draws many threads together and looks at project organization, design, and other factors, and how our languages provide these features. Chapter 14 looks at specific issues from C that affect C++, or have been discarded from C++, and how Java and Eiffel do not suffer from these problems. About C++ Code Examples It is very difficult to develop examples in C++ to conform to how C++ can and should be written. By "can be written," I mean can it be compiled by most compilers on the market today. By "should be written," I mean, is it written to be conformant with the latest draft standard and the way the gurus say it should be written, which might not be accepted by any compiler on the market. (By the way, the International Standards Organization ISO points out that a draft standard is not a standard!). By including C++ examples, one is wide open to criticism that the examples are not good examples. This sounds like a pathetic excuse on my part, but Al Stevens, a well-known writer about C++, including one of the Teach Yourself C++ books, says in a recent Dr. Dobb's article: We C++ writers have been in a quandary for some time now. The problem is rapid language evolution. If you write about the language the way that current compilers support it, your work is obsolete even as you write. If you write about the language the way the committee has defined it, few, if any, contemporary compilers can compile the programs in your work (because virtually no compiler compiles with the current proposed standard). And further: All the C++ books in my bookcase, including some fairly recent ones, use this style of code. However, if a brand new book uses this style of code, that book is labelled "old fashioned" before it goes out the door. Also: Listing Four is a fully compliant (with the proposed Standard) C++ program that a legacy C++ compiler would not compile but that a compliant compiler-if one was available-would compile. Herb and I have been told by a reputable authority that this is how C++ programmers should be taught to program. Listing Four is politically correct. Thus I am sure you will have no problem finding detractors who will say this book is not valid because the examples do not conform to one compiler or another (at one time or another), or to the standard, or to someone's notion of politically correct. So I make no apology for this-it is something that no one can get right! I do include the examples because they help illustrate what I am talking about, in the spirit of a picture is worth a thousand words. Acknowledgments Around 1996 I had an inkling that my Internet paper might grow into a reasonable book project, but did not take the idea too seriously until Geoff Eldridge voiced the idea and was encouraging after that. Geoff runs a well-respected Internet site disseminating much useful information on OO technology, and has also been instrumental in getting wide circulation for my original paper examining C++. Soon after that Bertrand Meyer also expressed interest in publishing such a work in the Object-Technology Series. He has been very encouraging, but has not unduly influenced the project as the designers of one of the languages this book examines. I am not always complementary of his language, and the freedom to perform this work and yet to have an outlet is much appreciated. John Potter has also been most encouraging and arranged part-time employment in his Object Technology Group with the Microsoft Research Institute at Macquarie University (MRI). He has given me many projects to do that have provided insights documented here, and helped test others. The frequent discussions at MRI have been most illuminating, and have certainly helped straighten out some areas of this book, although any areas of inaccuracy are my responsibility only. In this group is David Clarke, with whom I have shared an office, many type-related discussions, and an absurd sense of humor; David Holmes, who is a leading expert on concurrency in Java, and who provided many detailed and helpful comments on an early draft; James Noble, who knows much about prototyping languages and patterns; Jon Tidswell, who offered much support and taught me a lot about computer security in a very short conversation; Ryan Shelswell, who we lost to higher callings in Scotland, but who also contributed many insights. Although this group is being disbanded mid-1999, I'm sure you will hear a lot from these talented young people in the next millennium (if we survive the millennium bug catastrophe that is!). I should also mention Professor Jan Hext who, as I mentioned, I first knew at Sydney University where he taught me Simula in an honors course, and so set my sights on OO, even before the term was known, and who gave some good advice on the pitfalls of publishing a book. Paul Greenfield has also been a common factor in my continuing education, from being a tutor at Sydney University to one who I have continually worked with in several different jobs. He showed how you can be a practical engineer with high-level concepts. Don Gregory has also been a good friend, encouraged several endeavors, and published an early form of this book as a paper in his A Series Journal. Owen Reddecliffe was another person who proved to me that high-level languages were practical and could be extremely efficient, and the fact that he wrote a compiler for an ALGOL-like language in 4,000 lines of Basic is an education in itself. That being said, during the preparation of this book, my mother unexpectedly passed away from complications after heart bypass surgery, and like anyone who has lost a parent, I wish there were a way I could express my thanks to her more directly and regret the many missed opportunities. She was the epitome of love and would find great distress in how modern technology is used to amplify mankind's greed and hatred. This book is therefore dedicated to: Lois Nellie Joyner She gave me life My passage into the world But more than organic fact we are here for a higher purpose She was a channel of love Bringing everyone together and back together again In this broken world love is silly and feeble-minded but where she is now love reigns in strength If all could grasp her love beyond reason the world would be beyond war, guns and aggression beyond the hate of those less fortunate or different The world should learn from her love, her compassion These she has left us and let us pray that they shall never be gone. Ian Joyner 30 July 1998