Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!labrea!rutgers!bellcore!faline!thumper!ulysses!andante!alice!bs From: bs@alice.UUCP (Bjarne Stroustrup) Newsgroups: comp.lang.c++ Subject: Re: Should C++ follow C's footsteps? Summary: It should Message-ID: <8980@alice.UUCP> Date: 28 Feb 89 01:37:30 GMT References: <4800051@m.cs.uiuc.edu> <8902@alice.UUCP> <486@ubbpc.UUCP> Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 137 Let me just make a few points about C++, C compatibility, and C++ language evolution: [1] C++ will remain as compatible with C as possible It may even become more compatible than current implementattions are. The cfront implementation is by and large compatible with K&R C. As promised in my book, the C++ definition is now being revised with the view of removing gratuitous incompatibilities with the proposed ANSI C standard. The reason for compatibility is not that C is perfect but that in areas such as expression evaluation and statement syntax C is good enough (my opinion is that though C certainly isn't perfect, it is better than it is often given credit for and better than many suggested `improvements'). There are a couple of hundred thousand programmers that will NOT appreciate having to re-learn the basics to gain a marginal improvement. If we introduce anything genuinely different at this level it is likely to affect the object layout and/or function call mechanism so that link compatibility becomes an issue. Furthermore, since C isn't just going to go away there is the need to maintain many millions of lines of C for many years to come; having compatibility at the function, statement, expression, and object layout levels is important to many people. Dealing with two similar but subtlely different languages on a daily basic is not pleasant. Except for the specific C++ features, C and C++ should be identical in almost all respects and the remaining differences should all be detected by the (C++) compilers. [2] C++ will not change incompatibly or radically. I'm sorry to disappoint the many people that seem to think that C++ can be radically improved by a few quick changes (often changes that is incompatible with both C and C++). C++ may be a relatively new language (only about 5 years of serious use), but C++ is not silly putty and cannot be radically changed without seriously inconveniences thousands of users. Also, if I had wanted to create a language that was radically different from C++ I would have done so. C++ was based on C, uses a compiler based (``strong'') static type checking strategy, and preserves low-level features (and efficiency) by design, not accident. [3] C++ will grow C++ will be enhanced by features such as exception handling and parameterized types, but the growth will be gradual with great concern for compatibility. The things that could affect C++'s usefulness and growth most seriously now are rampant featurism, incompatible implementations, and changes without concern for existing C++ users. [4] C++ is not intented to FORCE people to change. It is intented to allow and encourrage people to learn and to change if and when they want to and at a pace they are comfortable with. Moving from `plain C' style programming to more powerful techniques in stages is possible and for many people the only way. This is not the only way of doing things, it is not meant to be. A more rapid change of style is possible with C++ and there are no shortage of `pure object-oriented' languages and systems for people who don't like compromises, static type checking, or whatever. As far as I can see people condemming C++ for not forcing programmers to use `object-oriented programming' mis a key point about C++ and some suffer from dangerous paternalistic tendencies. They might also ask themselves whether their favorite language/system today have more or fewer users because of C++'s growth/acceptance/fame/notoriety. By and large I think C++'s effects on the spread other languages and systems supporting object-oriented programming, etc. have been minimal and positive. [5] Education is the key The key bottleneck for C++ use is education. It is also the hardest to overcome. C++'s growthrate ensures that. Major problems with education are the lack of a sufficiently well defined standard, the relative lack of tools for novices, and the widespread tendency of not accepting C++ for what it is but considering it as an imperfect copy of something else. The two former problems are rapidly being remedied the third could be critical. C++ is not (just) C C++ is not Modula2 with a funny syntax C++ is not Ada minus Army backing C++ is not a crippled Smalltalk C++ is not yet another dialect of Lisp For people wondering what C++ actually is and what C++ might become, I can recommend the proceedings from the two USENIX C++ conferences. My opinions and those of dozens of others can be found there. [6] We are working on a preliminary to standardization. As I have mentioned here and elsewhere before, we need stability and a wide agreement on the definition of C++. To this end I'm working on a revised language definition and individuals from a couple of dozen different organizations are helping me. The aim is a good language specification by August. Such a language specification can be a good basis for a more formal (and necessarily much longer) standardization process. This process - and also the ANSI standardization of C - may introduce incompatibilities (with early C++ implementations). These incompatibilities are neccesary (to avoid implementation dependencies in the language specification and fights with ANSI) and hopefully (and apparantly) minor. These problems should be faced sooner rather than later to minimize the inconvenience of users. [7] Tools and libraries are fertile areas for improvements C++ has been defined as a classical language with only minimal standard libraries, NOT as an integrated system. This is both a strength and a weakness, but was certainly deliberate. Many are now working on creating libraries, tools, and complete programming environments for C++. This is good and it was expected. This will allow a wide array of techniques to be applied to help programmers in addition to what the language itself provides. I expect the language features, libraries, tools, and environments to have at least additive effects for the programmers. Some of these tools etc. will support some programming styles, some design methods, some philosophies, etc. better than others, some will help novices and some experts. My hope and expectation is that the relative diversity of style and opinion that C++ accomodates or even encourrage will be reflected in these tools, etc.