TITLE: what's wrong with OO (long) (Newsgroups: comp.lang.c++, 9 Jan 97) BJARNE: bs@research.att.com (Bjarne Stroustrup) > > Only where I couldn't find a solution that fitted in C++'s general > > framework and met my criteria for run-time efficiency, ease of > > implementation, ease of teaching, etc. (see D&E Chapter 4), did I > > feel compelled to try to invent something. BART: Bart Samwel > When I read this, a lot of questions pop up in my head. I'll ask only > one: You've only included features that didn't compromise ease of > teaching (at least, that's my interpretation of what you wrote). Why is > it then, that C++ contains so many hidden 'features' (or rather, > non-explicit rules) that confuse people, at least at my university? BJARNE: In addition to giving an answer to you[r] ``only one'' question, I will comment on some of the pretty strong statement[s] you made afterwards - lest silence should be taken for agreement, lack of counter arguments, or arrogance. I'm not sure which hidden_features/non-explicit_rules you are referring to, but I do have some experience with the teaching, learning, and use of C++ that might be relevant. First, here is the way I phrased the "learning" criteria in "The Design and Evolution of C++": If in doubt, pick the variant of a feature that is easiest to teach This is a secondary rule for choosing between alternatives. It is tricky to apply because it can be an argument for logical beauty and also for sticking to the familiar. Writing tutorials and reference manual descriptions to see how easy they are for people to understand is a practical application of this rule. One intent is to ease the task for educators and support personnel. It is important to remember that programmers are not stupid; simplicity mustn't be achieved at the expense of important functionality. It is one of about twenty such rules of thumb I rely on. C++ is a language primarily aimed at creating production software. Like all such languages, it together with its associated libraries, tools, and programming techniques is too large to learn quickly (unless you happen to be experienced in rather similar languages and techniques - and most students and programmers are not when they first encounter C++). Consequently, it must be learned in stages starting with some suitable subset (and a suitable subset of tools, libraries, programming techniques). Many are too ambitious and try to learn too much too fast. In particular, many programmers focus on learning every obscure language detail rather than overall principles because mastery of programming language details is what has traditionally been valued in many programming communities. That way, people get lost in details. That, together with the common mistake of chosing "all of C" as the initial subset of C++ to learn have led many into trouble. These problems are avoidable. In particular, only a relatively small part of the common C and C++ subset needs to be understood before one can approach the abstraction mechanisms that are the essential part of C++. Traditionally, C++ has been blessed with a mass of useful libraries, and cursed by the absence of a good standard library. The lack of a standard library supplying basic types (such as string, list, and map) reinforced the bias of some teachers and some teaching materials towards low-level features and techniques that don't rely on standard library facilities. C++ now has a nice standard library and most implementation now are shipped with a reasonable approximation to it. However, the effects of its initial absence (primarily my fault) still lingers in teaching methods and teaching materials. C++ caught on very fast. This led to people "joining the bandwagon" without actually understanding what the important ideas were. Many times, I have cringed seeing what riduculous statements were made about C++ and its proper use. For example, an early textbook proudly gave an airplane derived from an engine as its first example of object-oriented programming. Naturally, that author had never written a real C++ program in his life or a real program in any other programming language supporting object-oriented programming. Fortunately, he later jumped on another bandwagon and is now pushing some other OO language. I have no idea if any of this apply at your university, but I have seen all of those phenomena repeatedly. Usually, people manage in the end, and if not they try something else - which they may or may not find more suitable. I provide more details about learning and teaching C++ in "The Design and Evolution of C++" (D&E) and on my homepages. C++ can be - and often is - taught effectively to people of a wide variety of backgrounds and with widely varying needs. BART: > As far as I'm concerned, C++ is not a language for teaching. It has too > many of these implicit rules to be logical, and the fact that it > doesn't have garbage collection and does have pointers really makes it > error-prone; especially for beginning programmers, this is not a good > thing. They should be writing WHAT should be done, and ALL that should > be done; they shouldn't be bothered with the 'how' part of programming, > like (with alternatives): memory management (garbage collection), > pointers (references), virtual functions (can be detected by the > compiler). They should not be bothered with implicit rules (like the > multiple inheritance rules, for instance) that they have to know of, > before using multiple inheritance. > > C++ is an excellent language as an extension to C, but C is altogether > obsolete and much too low-level, except for systems programming, and > other languages are now available for writing high-level software. > Many people make the (IMO huge) mistake of using C++ for high-level > software projects, leading to buggy results and, often, lots of core > dumps. Programmers are not perfect, and C++ expects them to be so by > providing too many ways of making mistakes. BJARNE: I'm not sure about what you call a "high-level software project" but C++ has been applied successfully often enough for your description of the results of using C++ to be a carricature. There has been failures involving every programming language that has ever been used for production code. Since there has been more use of C++ than for any other comparable language, I would expect there to have been more with C++. However, I use C++ software daily that doesn't dump. There are many C++ programs out there that works correctly month in and month out. Reliability and mainatainability can be eased by a programming language (such as C++) but is the result of a more comprehensive process. C++ is a programming language, so it doesn't have expectations, but I - as its designer - never suffered from the delution that programmers were anywhere near perfect. Nor did I suffer from the delusion that I knew enough to put restrictions in place to constrain every programmer without exception or escape. BART: > Languages like Eiffel (my personal favorite) are much more suitable for > high-level projects; Eiffel, for instance, does not burden the > programmer more than needed, and has a clean, clear syntax that can > even be immediately understood by people that don't know the language. BJARNE: I do not personally find it so, and such claims reminds me unpleasently of the similar claims made for COBOL. A non-programmer can sometimes be convinced that he/she can read simple code, but it is far from obvious that this is relevant - or ever true - for production code (that will only be seen by programmers anyway). BJARNE: > > Much of C++'s success has to do with fitting into existing > > environments and being compact and fast (yes, I know that these are > > not the aspects of C++ that are currently emphasized in the > > MS Windows world). The speed and compactness of code generated from > > C++ depends on a few fundamental design decisions that I think were > > novel at the time: BART: > Speed and compactness is certainly a goal that C++ has achieved. But it > did not achieve one major goal: ease of use. BJARNE: I wonder how you would measure ``ease of use'' objectively. For starters: ``ease of doing what kind of work?'' ``ease for whom?'' C++ isn't the easiest programming language to learn and to use, but for a rather large range of systems, a large range of applications, and a large range of developer communities, it seems to be the easiest language out of those that can actually help get the work done. Had C++ not been relatively easy to learn and use reasonably well, it would have disappeared long ago. By relative I mean the amount of effort needed compared to the amount of benefit gained. BJARNE: > > C++ offers inline member and non-member functions with zero > > overhead compared to macros. BART: > You shouldn't bother programmers with inlining. Inlining can be done > automatically by the compiler. BJARNE: Not really. Some compilers can do some inlining well, but for larger programs the compiler is hampered by having incomplete information and by not having a particularly good idea of what optimizations are relevant in various part of the code. Explicit inlining is a pretty good way of giving programmers some control for the common cases where a compiler isn't smart enough without tying users up with proprietary and non-standard control features. Used well, inlining can make a major difference in speed and code compactness. BJARNE: > > C++ offers its form of dynamic (run-time) resolution, virtual > > functions, with low and fixed overhead compared to ordinary > > function calls (20% to 100% dependent of implementation). BART: > Virtual functions must be explicitly specified. This can be done by the > compiler. And, virtual functions must be specified in the ancestor > class; this means that when a class designer forgot to put that in > (and this happens often), I can't redefine the function correctly. BJARNE: Deciding which member functions should be virtual is a design decision, not an optimization. If a designer has provided a poor base class, you will typically have problems beyond what can be fixed by overriding. BJARNE: > > Over the years, C++ has evolved within a framework that was reasonably > > well understood early on. BART: > Well understood, yes. But the framework is now obsolete, and it has > some serious design flaws that also bother C++ users. BJARNE: Certainly there are flaws - I don't know of a language that doesn't have flaws, and I consider the idea of a widely-used flawless language nonsense. Once a language is used by diverse user communities, one person's serious flaw becomes another's essential feature. Some of the aspects of C++ that I dislike most are deemed essential by very competent system builders. However, C++ has no flaw and no feature lacking that is so serious that it cannot be managed with reasonable effort in a project - even if they can be a bother and experienced programmers recognize them as such. I do not consider C++ or its basic conceptual framework obsolete nor do I know an alternative that could replace it in the next few years. Like it or not, programming languages have lifecycles that span decades, and "obsolete" often means little more than "not in accordance with the latest fad." For most builders of real-world software a ten-year-old language is a newborn. ``OO'' itself is more than 25 years old and we are still learning about it - even those of us who have been part of the process through most of those years. The world is a whole lot messier than we would like it to be, and some of that messiness is reflected in every successful programming language. Good luck with your projects and the language you favor, and remember that the world is more complicated that any of us can imagine and that there are ways of succeeding that we would not personally have chosen.