zurück zur Hauptseite

Ian Joyner hat seine Untersuchungen zu Rolle und Eigenschaften von (objektorientierten) Programmiersprachen (in Analyse, Design, Implementierung) in Buchform herausgebracht.
(Ian Joyner arbeitet im Microsoft Research Institute (!) der Macquarie University, Australien.)

Ian Joyner: Objects Unencapsulated:
Java, Eiffel, and C++??, 1/e

Prentice Hall June 1999. 416 pages, ISBN 0-13-014269-7










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 mega-volumes.

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.


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 very far to 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.

Address, California Institute of Technology, 1931


By analyzing and comparing three different object-oriented languages, Objects Unencapsulated probes the core of object technology to examine how various language features affect software productivity. Objects Unencapsulated examines and compares the strengths and weaknesses of Java, Eiffel, and C++. Topics covered include: Objects, classes, modules, and types.; Features and interfaces; Inheritance and genericity; Concurrency and garbage collection. Grounded by his belief that true innovation demands constant re-evaluation, Ian Joyner strips away the superficial distinctions between these languages to find the essence of object-oriented programming. He explains the facts behind the many controversies that an object-oriented practitioner constantly faces. Ian Joyner is a member of the Object Technology Group at the Microsoft Research Institute at Macquarie University in Australia. He has been practicing and critiquing object-oriented software since 1979.

Object technology appears to be a bewildering field in constant turmoil. But the core concepts of object-oriented programming endure as a paradigm for advanced programming methodology. By analyzing and comparing three different object-oriented languages, Objects Unencapsulated probes the core of object technology to examine how various language features affect software productivity. Objects Unencapsulated examines and compares the strengths and weaknesses of Java, Eiffel, and C++. Topics covered include: 
  Objects, classes, modules, and types.
  Features and interfaces.
  Inheritance and genericity.
  Concurrency and garbage collection.

Grounded by his belief that true innovation demands constant re-evaluation, Ian Joyner strips away the superficial distinctions between these languages to find the essence of object-oriented programming. He explains the facts behind the many controversies that an object-oriented practitioner constantly faces. By explaining some essential theory in practical terms, Objects Unencapsulated exposes the principles of theobject-oriented paradigm.

Structure of the Book.
About C++ Code Examples.
Why Should We Be Concerned?

1. Language Principles.

Programming. Communication, Abstraction, and Precision. Notation. Tool Integration. Correctness. Types.
Flexibility, Correctness, and Reuse. Redundancy and Checking. Encapsulation and Implementation Hiding. Safety
and Courtesy Concerns. Implementation and Deployment Concerns. Why OO? On Programming Language
Evolution. The Usefulness of Mathematics. Legacy Systems.

2. Entities and Types.
From Bits to Semantics. Basic Structures: The Class. Usefulness of Grammars. Classes and Types. Structs (C++).
Typedefs (C++). Global Environments. Class Metadata. Obsolete (Eiffel). Invariants (Eiffel). Components.

3. Modules and Imports.
Namespaces (C++). Clusters (Eiffel). Packages (Java). Header Files (C++). Import (Java). ACE Specification (Eiffel).
Separate or Integrate?

4. Members and Features.
Basic Structures. Members (C++ and Java). Anonymous Parameters in Class Definitions (C++). Default Arguments
(C++). Local Entity Declarations (Java and C++). Inlines (C++). Pointers and References (C++). Declarations and
Definitions (C++). Scope. Constants. Static (C++). Once Routines. Class Variables and Redefinition.

5. Type Extension: Inheritance and Virtuals.
Basic Structures: Inheritance and Derived Classes. The Nature of Inheritance. Multiple Inheritance. Virtual Classes
(C++). Nested Classes (Java and C++). Polymorphism and Inheritance. Union. Enumeration Types. Name
Overloading. Virtual Functions (C++). Pure Virtual Functions (C++). Function Overloading (C++ and Java). Virtuals
and Inlining.

6. Type Extension: Generics and Templates.
Basic Structures. C++ Syntax. Constrained Genericity. Genericity and Code Bloat. An Alternative Form of
Genericity. Java and Genericity. Some Theory on Genericity. Genericity and Covariance.

7. Interfaces and Access Control.
7.1 Basic Structures. Friends (C++). Controlled Exports vs. Friends. Multiple Interfaces. External Assignment (C++
and Java). Export Controls and Nesting. Mutable Const (C++). Generalization.

8. Constructors, Destructors, and Other Operators.
Nameless Constructors (C++). Default Constructors (C++ and Java). Constructor Inheritance. Expanded Initialization
(Eiffel). Constructor Initialization (C++). Destructors (C++). Dispose (Eiffel). Operator = (C++). and -> (C++). Delete
and Delete (C++). Prefix and Postfix Operators (C++).


Ian Joyner:
My book is about the strengths and weaknesses of some major object technologies. It dispelssome of the myths of object technology and gives you ways to make the best use of it. I hope readers will find the many perspectives in it interesting and useful. If we really can't produce quality software economically, what is the point? My book is different to the many others because it is not just a glowing review and hype about objects. Yes OT is a good technology, but there is more to it than that. We still need to get many other things right. This book will not be popular with certain segments of the industry, because it gets to the truth, but I wrote it because I felt it needed writing, and the industry needs its message if computing is to become a respectable profession.

If you want the truth behind programming in general and object technology in particular, you cannot afford to miss my book.




Roger Browne (roger@eiffel.tm) - 15 Sep 1999

Don't worry about the weird title. This book is basically about three languages: Java, C++ and Eiffel. But it's not the old style of "comparative programming languages" book - mostly filled with syntax comparisons plus a bit about argument-passing conventions etc. Oh no, Ian's book is nothing like that!

Ian's book grew out of his " C++ report" which is available on the internet, but it has gone way beyond that in both breadth and depth.

Ian's book is an adventure story - an exploration in search of a good programming language, discovering the "big picture". Yes, the minutae of syntax are in there too, but only in the sense that they contribute to the usability of a language for the job of designing and implementing complex yet reliable software.

Ian's book is a journey - a journey of discovery, visiting a dark continent populated with blurb, spam, jargon and hype - constantly dodging the poison-tipped arrows fired from the entrenched viewpoints, and avoiding getting sucked into the vacuum of trendy fashions.

Ian's book is an intellectual feast - a satisfying intellectual meal for those hungry to learn. It's a wide-ranging saga, flitting here and there, touching on lots of subjects and exploring the really interesting ones in great depth.

But it's not a reference book. It's a narrative that you read from cover-to-cover, and will maybe reread every year or two. It's a book you can lend to your friends (and enemies) when they ask you why you program in Eiffel instead of Java or C++. 

Ian's not afraid to call a spade a spade. There are no sacred cows, there's no bowing to peer pressure, and there's no succumbing to political correctness. It's a refreshing read.

You won't agree with everything Ian has to say (especially if you consider C++ to be the epitome of programming bliss), but you'll come away from this book with a broader understanding of the issues surrounding serious modern software development and the tools we use to accomplish it.



Empfehlung eines fröhlichen Menschen:

   buy it (Eiffel users),
   borrow it (Java users),
   or steal one and ceremonially burn it (C++ users).


Diese Seiten sind nicht mit kommerziellen Interessen des Seiteninhabers verbunden!


Ich distanziere mich ausdrücklich von Inhalten der Seiten, auf die ich sogenannte 'Links' setzte,
wenn diese strafbar oder anderweitig rechtswidrig sind.

Für die Inhalte der gelinkten Seiten sind ausschließlich die jeweiligen Betreiber verantwortlich.