Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!dgcad!gary From: gary@dgcad.SV.DG.COM (Gary Bridgewater) Newsgroups: comp.lang.c++ Subject: Re: C++ Not Ready for Commercial Use Message-ID: <1177@svx.SV.DG.COM> Date: 17 Oct 89 08:14:32 GMT References: <24.UUL1.3#913@acw.UUCP> <1989Oct15.193756.6114@paris.ics.uci.edu> Reply-To: gary@svx.SV.DG.COM () Organization: Data General SDD, Sunnyvale, CA Lines: 184 My comments are in support of Doug, an additional rebuttal of Scott. I wanted Doug's comments as well since they are quite good. Sorry for the length. In article <1989Oct15.193756.6114@paris.ics.uci.edu> schmidt@zola.ics.uci.edu (Doug Schmidt) writes: >In article <24.UUL1.3#913@acw.UUCP>, guthery@acw (Scott Guthery) writes: >++ When thinking about using C++ for a real programming project consider the >++ following: >++ 1) C++ is *NOT* a superset of C. >This is true, however it is not clear a priori that this situation is >an egregious oversight on the part of C++ designer. > ... Agree but ... C is not a superset of anything. So what? This is a strawman argument. C++ is not a light blue Chevy truck. So what? C++ uses C syntax with extensions and restrictions. The extensions could confuse a C programmer who didn't know C++ but C could confuse a C programmer. There is a yearly contest based on that fact. So what? The extensions also provide in-line code which is a very powerful optimization tool (or will be when the bizarre length restrictions are removed). The restrictions bring C closer to what many of us wanted in C - strong type checking. >++ 2) C++ has been under development for over 10 years and it >++ still isn't done. >The same can be said for COBOL, FORTRAN, Ada, Modula 2/3, C, etc. C++ >isn't Latin, i.e., it is not a *dead* language. In fact, I'm hard >pressed to name any significant/popular programming languages that >*haven't* undergone revision over the years. Can you? Right - that means you have to keep up with the language just like you have to keep up with the O/S, the hardware, and the general stuff that makes the practice of software development more than a hobby. So what? >++ 3) An incompatible Release 2.0 just came out this year; existing >++ C++ projects must either be rewritten or use two different >++ incompatible compilers for the same langauge in their builds. >Naturally, it is an *empirical* question whether existing C++ projects >must be re-written. For example, no one is holding a gun to C++ >developers, forcing them to upgrade to 2.0. Hmmm. An ANSI release of C (almost) came out this year that made some horrors of the existing C incompatible or at least obsolete. Many people ran around yelling that the sky was falling. It wasn't. In this case, Doug, 1.2 and 2.0 are more incompatible than you say. Or so we have found. We may have used more of the "grey" features. But they don't link together due to mangler differences, in any case. You might get away with having disjoint versions of both. But, again - So what? We have a ton of code in 1.2. We are converting it to 2.0. We are commited to it because 1) it is better than C in many ways and 2) it is more portable than C across the platforms we want to run on. Our programs are so complex that we felt we had to have more power than C was going to give us. We could have made it portable (at a fair cost in performance) in C but it is doubtful if it would be working by now. >++ 4) C++ experts are still arguing about how many features of C++ >++ do work and should work. > >Ditto for Ada, C, and any other popular language. Discussion and >dialogue are healthy. There's an apt cliche here: > > `while you're green you're growing, once you're ripe you start to rot!' > >There is no point trying to freeze the language in an incomplete >state. If you don't feel comfortable using it currently, simply wait >about 3 years, and try again! I can't expand on that - agreed. >++ 5) Release 3.0 of C++ is under active development; still more >++ features will be added and existing featurres "improved"; no >++ guarantees about upward compatibility with 2.0 have been made. > >If you want guarantees, use Ada ;-) (ironically, however, the Ada 9x >committee is wrestling with many issues that C++ designers do, e.g., >backward compatibility, avoiding `creeping featurism,' etc.). Or pick a cpu and write assembler. It absolutely, positively won't change as long as you own that computer. I guarantee it. So what? >++ 6) C++ violates much of Wirth's advice about how programming languages >++ should be designed & developed; > >Wirth had many key insights regarding language design. However, he is >certainly not infalliable. For proof, ask yourself why Pascal has >failed to become a serious industry standard for programming >languages? The short answer is that it lacked many features that >proved necessary when writing `real' applications in an efficient and >portable manner. There is a thin line between parsimony and >inadequacy when designing programming languages... And our application was not to write a compiler. So Wirth's insight is interesting but inapplicable. We considered PASCAL - we all agreed it had many of the features we needed. But each platform had one or more relatively incompatible flavors of it. >++ programming languages are not just >++ bags of tricks and features to be added to at will but this is how >++ C++ is being developed. >Please provide concrete evidence for your claims, otherwise the >discussion becomes a raging polemic... One programmer's bag of tricks is another programmer's livelihood. X windows is just a bunch of tricks, and widgets and toolkits and looks-and-feels. RISC processors are just a bunch of tricks and gadgets. Unix and the unix commands are just a bunch of tricks and stuff glommed together. So what? >++ 7) According to its author, C++ is designed for programs >++ measured in thousands of lines of code. The author goes >++ to say that if the program is measured in tens of thousands >++ of lines of code "mere progrmming language structuring >++ facilities can provide little relief." He's absolutely right. > >So, what's your solution here? Check out Fred Brook's `No Silver >Bullet' article. If you are looking for trivial panaceas to complex >problems you're not going to find it with either C++ or any other >programming language. The question here, however, is `does C++ >provide better support for good software engineering principles >compared to its alternatives?' When the alternative is C (as often >occurs today), then I think the answer is affirmative. So did we. And we still do. And we have hundreds of thousands of lines. And it is hard to keep it together but 1) c++ forced us to define very concrete interfaces so we can let people work on different parts without fear of incompatibilities and 2) when you debug and finish an object then all instantiations of it instantly work. Note that 1&2 depend on very strict typechecking to guarantee they are true - the only place we have gotten in trouble is where we tried to fool the mechanism and we are paying. It is harder to write bad c++ than bad c - not impossible, just harder. >++ 8) There is no software management methodology for inheritance, >++ overloading, or persistent state among other C++ features. >This is a failure of software engineering researchers, not necessarily >a failing of C++ designers. It will come. >++ 9) The current version of the language has only a operational >++ definition; the final version has no definition at all. >What exactly do you mean by this? It makes a good slogan, but is >rather content-free... Can you `prove' the final version has no >definition at all?! Right. This is just a rehash of #1. >++ 10) There are no industrial grade development, debugging, >++ software management, configuration control or proram analysis >++ tools for C++. >Sounds to me like there is a golden opportunity for some enterprising >developers to make a killing in the market. Luckily, it sounds like >you won't be among the competition ;-) See # 8. Companies are working on it. This is definitely a problem for the 40-50 mips workstations of the '90s, in case any hardware type drags out that hoary old "what are you going to do with all that power" line. Just think about all the meta-information it will take to manage object descritption mods. >++ There's no way a software project manager who cares about the quality, >++ deliverability, manageability, or long-term viability of his product >++ would commit a real software project to C++ in its current state. >Is this a statement of opinion, or a statement of fact? If the latter >then I'm afraid there are many counter-examples. We have been using one for two years. We care a lot about quality, also time to market, maintainability, extensibility and transportability. >++ fact I've got to wonder about the software engineering skills of >++ someone who would even think about committing a project to an undefined >++ programming language. >Great, please continue in search of the holy grail of programming languages. >If/when you find the perfect solution, please let us know! We think they are a wonder too. And by the way, take a peek at InterViews for a good example of the power of c++ to put together a reasonable system in a short amount of time. Also note the size of the diffs to get it to 2.0. And it works! Where's your X toolkit? And why wasn't this posted in comp.religion? We are discussing the living world of c++ here, warts and all. Sure it needs to get better, faster, smarter, more tangible, etc., etc. but so do any number of other facets of software development. Why not join us and help fix the things you see that need fixing? -- Gary Bridgewater, Data General Corp., Sunnyvale Ca. gary@sv4.ceo.sv.dg.com or {amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary No good deed goes unpunished.