pkr@media03.UUCP (Peter Kriens) (05/23/91)
amount of time it takes to order a simple sandwich. They start asking you if you want onions, or mustard, on the rye, with lettuce, without tomatoes. I usually get confused because I am usually in a discussion while in a restaurant. I just say a sandwich, but then the waitress will continue to force me to chose me between an awfull lot of options. When I started studying C++ because I needed to teach it to a class, I got a funny deja vu feeling, remembering the American waitress. You can do it virtual, but you can also do it not virtual, but then you have problems there. You can make it static, but static in that context means something different in that context, you can use references or copying of values. It keeps forcing you to make decisions which hardly have anything to do with the problem domain, but are just a kind of goodies giving you certain optimisations in certain cases. C++ looks to me like a big bag of options, and you just pick what you like. Which I think is proven by the fact that in any discussion with a C++'er, you will always hear the answer that you can also do it that way in C++. It seems that people have added so much to the language, that it has become an Edsel, having features for all of us, but without identity. Am I alone in that fact that I do not like to chose all the time. I feel distracted because I have to spent so much time choosing and then later reworking because I made the wrong choice. The language does not seem to have a natural concept. When you look at different implementations made by different people they look completely different. From my experience in Smalltalk I found that people tend to build the same kind of solutions to the same kind of problems. It seems to me that that will hinder the reuse of software. If you look at the NIHCL library, it is build in a structure that is quite different from commercial available class trees. Will that not mean that it will be very hard to reuse generic code. When I look at other modern languages I see that they tend to remove the number of language options, but have a very generic simple concept. Lisp and Prolog use lists and atoms and Smalltalk has the basic object. All of these languages seems to be able to get away with no language defined keywords, allowing the user to built constructs from a very simple syntax. Do we need all those diverse tools while a small subset allows us to build the same kind of constructs. Would a small language not be much easier to learn and allow more reuse? Saving in training and building cost? Isn't this big bag of options making the language extremely difficult to learn, as I can also see in the classes I teached C++, and will it not make it impossible to get the compilers right. Will the amount of options make it impossible to validate a compiler? This way of thinking reminds of RISC versus CISC. They changed the CPU's to become much simpler, thereby offering more performance. Isn't C++ a CISL? And even the supposed biggest strength, type checking, seems to get in the way because every time I need to do something usefull, I need downcasting. And then I do not have any error check at all. If you look at the NIHCL classes, they even included a run time check for class when they need to downcast. Just like the const type, I threw them away after seeing how much I needed to remember that an object was const. I am very curious about the opinion of other people about this subject. I do not want to just criticize. Some parts of C++ are elegant and allow for nice code, but I really miss the idea behind the language. I hope I am not right in my judgement. It would be such a waste of all the efforts that go into the language currently. Peter Kriens pkr@media01.uucp
chased@rbbb.Eng.Sun.COM (David Chase) (05/24/91)
In article <2325@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes:
[a comparison of the wealth-of-choices available in C++ and American
restaurants].
I totally agree. Around here, we call it "mandatory flexibility".
You WILL be flexible, you MUST make these choices, you CANNOT defer
these decisions.
Glad to hear somebody else feels this way about the Emperor's New
Language. I've been using it for a year now, and I still think it
sucks. Where's my garbage collection? Where's my exception handling?
Where's my generics? Where's my type-safe down-casting? Why do I get
the feeling that the designers always had "fast" as their first
priority and "useful" as their second priority?
Oh well, not my job to tell people what tools to use. If lemmings
want a highway to a cliff, I'll see (as a compiler writer) that you
get the best damn highway I can build.
(Since I've recently observed a massive failure in reading for
comprehension over in comp.arch (the "what's in the '586 thread" --
it's quite amusing), I guess it is wise to point out that this is my
opinion, and not Sun's.)
David Chase
Sunjls@netcom.COM (Jim Showalter) (05/24/91)
>I totally agree. Around here, we call it "mandatory flexibility". >You WILL be flexible, you MUST make these choices, you CANNOT defer >these decisions. I'd be the last person in the world to defend C++, but I'm going to do it now... What keeps your project from adopting a standard that pre-makes these decisions to the maximum extent possible? Like any large and complex language, a style guide seems quite appropriate. You can even use tools to enforce whatever guidelines you come up with. Before I get flamed that guidelines are inflexible, let me add that all guidelines should be just that--GUIDES, not unalterable mandates. A common guideline is "Thou shalt not use GOTOs", and generally this is superb advice. Once in a while, though, you NEED a stinking GOTO to meet some too-tight performance constraint or to greatly simplify (yes, simplify) some arcane control structure. So, the right way to write this guideline would be "Thou shalt not use GOTOs in the default case, and in rare cases thou shalt use a GOTO after approval by some XYZ committee via waiver ABC". >Glad to hear somebody else feels this way about the Emperor's New >Language. I've been using it for a year now, and I still think it >sucks. Where's my garbage collection? Where's my exception handling? >Where's my generics? Where's my type-safe down-casting? Why do I get >the feeling that the designers always had "fast" as their first >priority and "useful" as their second priority? To be fair (I can't believe I'm doing this), I think Stroustrup did a remarkable job considering he needed to maintain compatibility with C. Of course, that means the putty shows pretty badly in the places where he had to graft things together the best he could, and it also means that some stuff just doesn't work right. As for the garbage collection, you're supposed to implement it yourself in your constructors and destructors. Get to work. ;-) (P.S. You want exceptions and generics? You a closet Ada geek, or what?) -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
brian@babbage.csus.edu (Brian Witt) (05/24/91)
In article <2325@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes: > You can do it >virtual, but you can also do it not virtual, but then you have problems >there. You can make it static, but static in that context means something >different in that context, you can use references or copying of values. It >keeps forcing you to make decisions which hardly have anything to do with the >problem domain, but are just a kind of goodies giving you certain >optimisations in certain cases. I've built an objective-C (TM) translator (version 4). I've looked at C++, and I've droolled at Eiffel. You use the right language for the appropriate job. If you want to write an application and the boss sez "use an object-oriented language" and Ada is too big, you choose C++. If you need reusable code for building a library to create a string of applications, choose obj-C because the generalness will promote reusability. If you really want type checking, and lists of "things" (parameter types) and don't mind drinking coffee during compiles, choose Eiffel :-). IMHO, C++ promotes building a typesafe object-based *application*. Longterm reuse is not high priority. We're looking at building an application for school here. We want lists of messages, and lists of site locations. Since these two "list content types" have nothing in common (superclass wise), we have to build two List classes, one for each kind of list contents we want to store. We really want parameterized types!!! Does GNU G++ suuport this??? > It seems to me that that will hinder the reuse of >software. If you look at the NIHCL library, it is build in a structure that >is quite different from commercial available class trees. Will that not mean >that it will be very hard to reuse generic code. >I am very curious about the opinion of other people about this subject. I do >not want to just criticize. Some parts of C++ are elegant and allow for nice >code, but I really miss the idea behind the language. I hope I am not right >in my judgement. It would be such a waste of all the efforts that go into the >language currently. Even Ada has its place. Many firms will fall in bed with C++. Many will succesfully produce products. It's the _final_ product that your customers sees that determines that success. However, there may be a lot of premature bald programmers around :-). > > Peter Kriens > pkr@media01.uucp -- ---------------------------------------------------------------- brian witt | brian@babbage.ecs.csus.edu You are what you click | (and if you click it twice...) Not representing Cal State Sacramento, the ECS dept, or Iraq
schwartz@groucho.cs.psu.edu (Scott Schwartz) (05/24/91)
brian@babbage.csus.edu (Brian Witt) writes:
and Ada is too big, you choose C++.
I dispute this. C++ has at least as much junk as Ada. More
complicated junk, too. If you include standard libraries in the
count, size is certainly a wash.oasis@gary.watson.ibm.com (GA.Hoffman) (05/24/91)
*sigh* "Real Programmers" Next append... gary a hoffman RISC Systems, Watson Research
pkr@media03.UUCP (Peter Kriens) (05/24/91)
Not so long ago I posted a message about my feelings ABout C++. Though there were not so many responses on the net, I received a lot of messages through direct mail. I will not mention the names because they posted it directly to me. I put > ahead of quotes. When I posted I expected a lot of flames for me having doubts about the effectiveness of C++. Surprisingly there was only one person who disagreed. He actually liked having many choices. This addresses the basic point of my previous posting: Is the attractiveness of choices depending on country? I know that the USA loves choices, Jim Showalter (well know in comp.object) had the following joke: > There's an old joke about a guy ordering in a super-ritzy restaurant, > and when it comes to the coffee he says he wants coffee and the > waiter says "Very good sir: Kona or French Roast?", the guy selects > Kona and the waiter says "Very good sir: cream or sugar?", the guy > selects cream and the waiter says "Very good sir: Guernsey or Holstein?". Which I think quite nicely reflects the C++ language. So the question is do we really win with options. I remember a story about why the Americans have been so succesfull in industry in the past centuries. While the English build everything custom, the Americans started to standardize. For example on ships the Americans used 2 or 3 types of pump while the English used about 20 different types. The Americans needed less people to train. The disadvantage was that they did not use the optimum solution for a certain case. I think this equals a computer language. Having only very few constructs, allow you to build everything though it may not be the most optimal construct for a certain problem. But that reminds me of the case where I tried to optimize a piece of code because it was used so heavily. I changed the sequence of code and just goto's to let the most used path become the sequential thread (thereby allowing the instruction queue to work most efficient). The end was that I just made things worse because the compiler stopped optimising. So it seemed that adding information to the function disallowed the compiler to make optimisations. This seems through in many cases. Adding informations makes reuse worse. And if we want to save this industry, we have got to find a way to increase the reuse of code. And do we really need all that optimisation? I have always been surprised about how much time people spent in optimising things. Since I started about 13 years ago I heard the same discussion about speed optimisation while in the mean time we have now computers that are about a 40 times faster. Where did that performance go? As far as I have heard and experienced there is usually only a small part of code responsible for your performance. I always like the rules of M.A. Jackson: rule 1 Dont do it. Rule 2, (for experts only) Dont do it yet. ---- Ok, the next point some people made was that C++ is basically such a difficul language because it needs to be compatible with C. Is that true? Is C++ really a natural extension to C? What is the concept of C, I think it is a (almost) device independent assembler (watch the typecast), definitely not a high level language.As an assembler it is a great tool, it allows you to work closely to the CPU and thereby taking care of highly efficient code (if you really know what you do). But what I do not believe is that C++ is the natural extension to this on the contrary. I think C++ is something that got stuck between C (the assembler) and the first floor (the higher level language). Some languages are already on the fourth floor... I would be very interested to hear from Bjarne Stroustrup. I would be surprised if he really liked what has become of his dreamchild. I think he started quite nice with the class construct (though why add that keyword, struct would have done just nice), but then so many things were added that were just goodies. Ending up with language that is neither usuefull as an assembler (ever looked at the code?) nor a high level language (try to teach it...). ----- I had one person telling me that he only had the down casting problem: > A few comments: the only siutation where I've gotten > into lots of typecasting is when I store a bunch of pointers > to objects as void* out of laziness (I have an array class that > works on void*, and it's easier to use that than to write a new > array class. I understand that templates will fix this, when they > are availible.). Funny, how people are willing to fix the shortcomings of something they have chosen. Why in the world would anybody want to write an Array class for different types? They will all use the same algorithm, dont they? So why should you be forced to spell out on which type you want it to operate? Besides this genericity problem, I experienced many times that in normal inheritance and especially multiple inheritance there is no alternative, not laziness, but is is the only solution without duplicating code. But I could be wrong about that. But every time I try to do something intelligent with inheritance I run into this type problem. Some people agreed with me on this point, and one added the fact that this is typical a C++ thing. For example, maybe people can show me a solution to the following problem struct Linked { Linked *next(); }; struct My {}; struct MyLinked : public Linked, public My {}; main() { MyLinked *x; x = (MyLinked*) x->next(); } (BTW, this compiled with an internal error in Zortech. it worked with an intermediate, so I guess it is ok?). It is a very easy problem, but it forces me to downcast the next procedure to a MyLinked. And I also understood that on certain implementations this might not work at all because of virtual bases etc. Help.... If I am right in understanding that this is basically the only way to do it, then I dont understand the type safety of C++, if you are forced to bypass it many times, it does not seem very usefull? -- I also got some questions why I complained about the const keyword. I tried to explain that though the concept is stated quite clearly, it seems that once you start using it, you end up changing a lot of old code and it propagates fast! If you start afresh I found it was mostly annoying, just another thing to distract you from the problem domain. --- One person made a very good comment about extendability: > However this messiness is also a strength. When c users needed > new features, there were a number of techniques that could be used to > implement needed constructs. I contrast it with Pascal, an elegant > minimal language. When pieces were found to be missing from Pascal, such as > string manipulation, it was very hard to add them in. In this country > C has become a dominant implementation language, and I attribute it to the > fact that users were able to do things in the language that the original > designers had never anticipated, whereas a minimal spanning language lacks > the redundancy that provides for improvisation. I completely agree with the fact that a language should be extendable. But strange enough I found that languages like C and C++ are definitely not extendable. Both languages have defined keywords which you definitely cannot change. You cannot implement your own if or virtual. I found that in Smalltalk all this is possible because there are no keywords in the language, just like Prolog. And what I understood from Lisp this is also the case. So if you talk about extending a language, then C(++) is definitely not an extendible language. The usuage is fixed (well as long as Bjarne can keep his hands of the definition, ehhh.. sorry which definition?). ---- A common remark, to which I agree, is that whatever I think about it, it will be the dominant language of the 90's. Somebody wrote: > programming. However, I think C++ will become the major language for > many environments, while alternatives like Eiffel, Objective-C, and > such will languish in relative obscurity, because of the ease of > moving to C++ from C and its wide availability. I do not agree with the fact that Eiffel and Objective-C will vanish. There will always be an audience which makes their choices on performance. If not, the Macintosh would have vanished long ago. One way or the other the industry seems to chose non-optimal solutions. We got stuck with MS-DOS, Windows and C++. I will use it, but I will always have a feeling that it could have been much easier if choices were made on performance instead of just marketing. Peter Kriens
dmg@ssc-vax (David M Geary) (05/24/91)
In article <1991May24.003350.25877@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
] I'd be the last person in the world to defend C++, but I'm going to
] do it now... What keeps your project from adopting a standard that
] To be fair (I can't believe I'm doing this), I think Stroustrup did
] a remarkable job considering he needed to maintain compatibility with
] C. Of course, that means the putty shows pretty badly in the places
There is only one conclusion to draw from Jim's comments:
Jim Showalter has become a pod person...dmg@ssc-vax (David M Geary) (05/25/91)
From uw-beaver!cornell!batcomputer!caen!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ucdavis!csusac!usenet Fri May 24 09:41:56 PDT 1991
Article: 3342 of comp.object
Path: ssc-vax!uw-beaver!cornell!batcomputer!caen!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ucdavis!csusac!usenet
From: brian@babbage.csus.edu (Brian Witt)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: C++ and waitresses (long)
Summary: C++ for applications; not longterm reuse
Keywords: C++, objective-C (TM), Eiffel, software reuse
Message-ID: <1991May24.015856.9979@csusac.csus.edu>
Date: 24 May 91 01:58:56 GMT
References: <2325@media03.UUCP>
Sender: usenet@csusac.csus.edu (News account (alt))
Organization: California State University, Sacramento
Lines: 52
Xref: ssc-vax comp.object:3342 comp.lang.c++:13245
In article <2325@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes:
] I've built an objective-C (TM) translator (version 4). I've looked at
] C++, and I've droolled at Eiffel. You use the right language for the
] appropriate job. If you want to write an application and the boss
Although this has been asserted by many, I have always felt this to be
a fallacy. Maybe my perspective is warped from too many years working
for large corporations, but decisions about programming languages are
rarely (IMHE) made by the right people for the right reasons.
] IMHO, C++ promotes building a typesafe object-based *application*.
] Longterm reuse is not high priority. We're looking at building an
I disagree. The problem with C++, as I see it, is that it retains
compatability with C. Many advocate using C++ "as a better C", and learning
OOP as you go along. This kind of thinking produces wannabe (and thinktheybe)
"OOP" programmers who really have a poor grasp of OOP techniques. Now in
a language such as Eiffel, you are *forced* to do *everything* in an
OOP manner, which, I believe is a good thing.
I think it is more correct to state that "longterm reuse is not a high
priority with many C++ *programmers*." However, most of the mechanisms
for longterm reuse are in the C++ language, and I have personally found
C++ very amenable to longterm reuse.
] Even Ada has its place. Many firms will fall in bed with C++. Many
[1]
] will succesfully produce products. It's the _final_ product that your
[2]
] customers sees that determines that success. However, there may be a
] lot of premature bald programmers around :-).
1) Yes, may firms will "fall in bed" with C++. Because it's the "right
language for the appropriate job"? Probably not. Most likely many
will choose C++ simply because it:
a) is well known and is a successor to the immensely popular C.
b) it is readily available, *now*, on most platforms.
c) AT&T is behind it, which is related to a) and b).
2) If you are in the software development business for the long term, then
I don't necessarily agree. IMHO, in addition to the final product, a
good metric of how successfully an application has been written is the
percentage of the application can be reused so that the next application
can be produced in the shortest amount of time, and be of the highest
quality.gyro@kestrel.edu (Scott Layson Burson) (05/25/91)
In article <2325@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes: >amount of time it takes to order a simple sandwich. They start asking you if >you want onions, or mustard, on the rye, with lettuce, without tomatoes. I >usually get confused because I am usually in a discussion while in a >restaurant. I just say a sandwich, but then the waitress will continue to >force me to chose me between an awfull lot of options. > >When I started studying C++ because I needed to teach it to a class, I got a >funny deja vu feeling, remembering the American waitress. You can do it >virtual, but you can also do it not virtual, but then you have problems >there. You can make it static, but static in that context means something >different in that context, you can use references or copying of values. It >keeps forcing you to make decisions which hardly have anything to do with the >problem domain, but are just a kind of goodies giving you certain >optimisations in certain cases. > >Am I alone in that fact that I do not like to chose all the time. I feel >distracted because I have to spent so much time choosing and then later >reworking because I made the wrong choice. The language does not seem to have >a natural concept. When you look at different implementations made by >different people they look completely different. From my experience in >Smalltalk I found that people tend to build the same kind of solutions to the >same kind of problems. It seems to me that that will hinder the reuse of >software. If you look at the NIHCL library, it is build in a structure that >is quite different from commercial available class trees. Will that not mean >that it will be very hard to reuse generic code. These are absolutely valid concerns. C++ is a strange beast indeed. I am very fond of its flexibility, but certainly was as bewildered as you when I first started to learn the language. I would go so far as to say that the community has not yet evolved a completely satisfactory sense of C++ style; perhaps some individuals have done so, but it certainly has not percolated out to everyone using the language. The thing to keep in mind about C++ is that even when you just want to write a program, you are forced to design a programming language to write your program in. C++ is so flexible that it really constitutes a metalanguage; well, as you point out, it's not just the flexibility but also the absence of high-level concepts which would create standard ways of doing certain things (e.g. built-in objects to represent classes). Don't get me wrong -- given the design goals of C++, which I agree with, I think it is very appropriate that it doesn't have things like builtin class objects, because a) it is not hard to implement them and b) it has been observed that different people who want class objects have different ideas about how they should work. In C++ as it stands, you can do it the way that best suits your particular problem. But you are quite correct that this makes the creation of generic code more difficult. There's the tradeoff. I think one answer is that there should be a definitive style guide for C++, one which is comprehensive enough that it comes to be considered as essential a desk reference as the reference manual itself. Does anyone know if someone is writing such a book? Perhaps I should. -- Scott Gyro@Reasoning.COM
jls@netcom.COM (Jim Showalter) (05/25/91)
schwartz@groucho.cs.psu.edu (Scott Schwartz) writes: >brian@babbage.csus.edu (Brian Witt) writes: > and Ada is too big, you choose C++. >I dispute this. C++ has at least as much junk as Ada. More >complicated junk, too. If you include standard libraries in the >count, size is certainly a wash. Could you elaborate? I would like a better definition of "junk" than is available above. Which of the following is junk?: - Strong typing - Separation of specification from implementation - Opaque types - Genericity - Exception handling - Namespace control/selective visibility - Overloading - Concurrency - Language standardization - Compiler validation -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
anders@verity.com (Anders Wallgren) (05/25/91)
In article <2326@media03.UUCP>, pkr@media03 (Peter Kriens) writes: > >One way or the other the industry seems to chose >non-optimal solutions. We got stuck with MS-DOS, Windows >and C++. I will use it, but I will always have a feeling >that it could have been much easier if choices were made >on performance instead of just marketing. > > Peter Kriens > > I think this is a little bit unfair. I'm very ambivalent about languages, because to a great degree, they are all isomorphic. It's just a matter of what is easier do to with a particular language. In my case, most of my formal academic training in computer science and software engineering was done with very high-level languages: lisp, clu, for example. The same goes for many of the people I work with. On the other hand, we use C and C++ exclusively in our work, simply because it is the most portable language we know of. There's nothing we would like more than being able to write our code in a higher-level language than C. This is _why_ I like C++ - it allows me to use many of the higher-level constructs that allow me to do a better job, software-engineering-wise, while still having (or at least approaching) the portability of C itself. I don't know why you chose C++, but I definately didn't pick it because of 'marketing', or 'performance' for that matter. I choose it because it is an extension to an environment that allows me to write portable code, but do it with a tool that is more than a 'high-level assembler' (which is still a pretty good characterization of C). anders
connolly@livy.cs.umass.edu (Christopher Connolly) (05/25/91)
In article <1991May24.015856.9979@csusac.csus.edu> brian@babbage.csus.edu (Brian Witt) writes: >In article <2325@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes: >> You can do it >>virtual, but you can also do it not virtual, but then you have problems >>there. You can make it static, but static in that context means something >>different in that context, you can use references or copying of values. It >>keeps forcing you to make decisions which hardly have anything to do with the >>problem domain, but are just a kind of goodies giving you certain >>optimisations in certain cases. I agree wholeheartedly. The language is probably too big for its own good, and its bigness results from an obsession with backward compatibility and efficiency. >IMHO, C++ promotes building a typesafe object-based *application*. We've been through this before - I don't see what's "safe" about being able to cast pointers back and forth at will. As has been pointed out previously, the programmer who lies to the compiler is asking for trouble, but this fact doesn't make C++ "typesafe". >for each kind of list contents we want to store. We really want >parameterized types!!! Does GNU G++ suuport this??? Irrelevant -- Kriens is talking about language issues, not implementation issues. >Even Ada has its place. Many firms will fall in bed with C++. Many >will succesfully produce products. My experience so far suggests that a more accurate statement might be "Many will successfully produce `.H' files.". Certainly, there will be successful products implemented in C++, but in a major industrial site that I work at, there is an alarming trend: People who have been charged with writing C++ code have, by and large, been producing specs, class declarations and function prototypes in #include files. So far, even after several months, precious little actual code has been written. The problem appears to be not knowing where to start and how to implement. I think Kriens' points apply directly to this situation. They are faced with too many choices and are afraid to commit themselves. I am fairly convinced that this would not have happened if the project's language had been C. I am not saying that this is going to be a universal phenomenon, but I think it will be frequent. -C. Connolly
aarsten@idt.unit.no (Amund Aarsten) (05/25/91)
In article <2325@media03.UUCP>, pkr@media03.UUCP (Peter Kriens) writes: > Am I alone in that fact that I do not like to chose all the time. I feel > distracted because I have to spent so much time choosing and then later > reworking because I made the wrong choice. The language does not seem to have C++ is a great language when you have a clear idea of what you want to do. To me, it sounds like you want a prototyping tool, which means you'd probably be better of with another language (Smalltalk/Lisp/Scheme etc.). C++ is not the best language for everyone, every language has strong and weak points. For instance, I don't think Lisp is a very good choice for doing 3D graphics! All the 'options' are not necessarily a bad thing; to me, it's clearly better to have choices open than having all the desicions made in advance (in the language), because the choices made in the language aren't always the right ones for your needs. This means you end up fighting against the language, which I have been doing in every other language I have used. As compilers get smarter, one might envision several of C++'s keywords becoming obsolete. This has already happened to 'overload'. I wouldn't mind at all having the compiler figure out which functions need to be virtual, even just the destructors would be a great releif... However, I don't think C++ ever will become everyone's programming language (Bjarne Stroustrup mentioned this in a discussion of the future of computing in BYTE magazine). It is great for systems programming and complex applications, especially when used with e.g. a UI toolkit. > way because every time I need to do something usefull, I need downcasting. If I end up needing downcasting, I rework my design and usually end up with a better one. Amund
davew@panache.cs.umd.edu (David G. Wonnacott) (05/25/91)
In article <2326@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes about the difficulties of using a language or eating in a restaurant that offers many choices. In defense of the way of life here in the U.S.A., let me point out that there are some advantages of the long menu of C++ features. For example, consider inheritance. Smalltalk has one inheritance mechanism. C++ forces the programmer to choose between public or private inheritance (some compilers may allow "protected" inheritance for orthogonality, but I do not see it listed in section 11.2 of my A.R.M.). I have seen smalltalk programmers confuse the use of inheritance to share behavior (i.e. for subtyping) with the use of inheritance to share implementation. Some are not aware of the difference between these concepts, and some simply have a hard time telling which is being used in a given piece of code, since they are both expressed by the word "subclass." A C++ programmer is forced to choose public or private derivation, but this choice should be easy once you have learned to use public derivation to share behavior, and private derivation (or inclusion of private data members) for sharing implementation. If you do not know whether you are creating a subclass to share the behavior or implementation, I suspect that the language is not the problem. If you have not learned which C++ mechanism to use for each of these needs, blame your teacher (my apologies to my students who learned C++ from me in the dark days before I figured this out). Furthermore, other C++ programmers who look at a class derivation can tell quickly whether the subclass is meant to be used in a context where the superclass is expected. The compiler even prevents the use of an object of a privately derived class where a base class type object is needed. Unfortunately, the compiler can not ensure that a publicly derived class is a subtype of its base. A C++ programmer who learns Smalltalk or CLOS or as a 2nd language may be distressed to find that there is no way to express the distinction between a subtype and a subclass that can not be substituted safely for its base. One could add a "publicSubclass" message to Smalltalk, to make this distinction clear, but that is no help for existing code. On the other hand, a friend of mine who does most of his programming in Lisp Flavors complains that C++'s multiple inheritance mechanism is not flexible enough: there's no way to control method combination. This friend is Canadian -- but perhaps he likes complicated menus because his mind was warped by going to school here in the states ;-) On another point: >Why in the world would anybody >want to write an Array class for different types? Because an array of floats is not the same type as an array of strings: I can store the value "hello world" on one, but not the other. Just as I can use "hello world" as an argument to a function with string parameter, but I can not use it as an argument to sqrt. Declaring the variable types can be a pain, but static type checking is a fast relatively easy way to detect a lot of bugs. This is especially important in a large project with many programmers. > They will >all use the same algorithm, dont they? So why should you >be forced to spell out on which type you want it to >operate? You shouldn't. Thats what a parameterized type is all about. You define array<type> once, and the system lets you create objects of type array<float> or array<String>. The need for a parameterized type mechanism is not unique to C++: Any statically typed language that allows the creation of new types (such as Ada, Eiffel, TS, or C++) must provide one, or the programmer will be forced to do all sorts of gross things to circumvent the type system. Given that C++ is statically typed, do you think a parameterized type mechanism should be added to it? Or would you rather not complicate the language definition, and go on without a good way of defining linked lists? In summary, there are good reasons to have some of these features in the language definition. There is more flexibility in a system that provides a few powerful mechanisms for you to build on, but there are times when it is better to build a variety of options into the compiler. It is hard to add static type checking to a dynamically typed, but extensible, language. If a language definition provides only one mechanism for something like inheritance, the use of that mechanism for several purposes may lead to confusion of these purposes, or at least difficulty in deciding which is meant in a given piece of code. It may or may not be harder to learn to use these mechanisms than to learn to use one mechanism for several purposes, but at least the confusion decreases as you become familiar with them. I am not saying that C++ is the perfect tool for all purposes. There are definitely some choices that are, to say the least, very annoying. For example, the need for the programmer to declare methods or superclasses "virtual," based on a guess about how the class will be used. But this is necessary to maintain the efficiency of C++ -- just because efficiency is not important to you, don't assume it isn't important to anyone else. The argument that computers are 40 times faster than they were 13 years ago isn't relevant unless people expect less than 40 times as much -- how many machines had to push around each bit of the image of each character they displayed, or clip their output to fit into a certain region on the screen in 1978? How many PC's were expected to run several 100K+ programs concurrently? > I will use it, but I will always have a feeling >that it could have been much easier if choices were made >on performance instead of just marketing. This is an inaccurate desription of the work of Bjarne Stroustrup and others within AT&T. I believe that Stroustrup's decisions are based on his estimation of the technical merits, not the marketability, of different options. You may not agree with his design goals (micro-efficiency, preservation of "the character of C" in C++), but don't accuse him of putting sales before technical merit unless you have some evidence of his doing so. Please note again that I do not think C++ is the right tool for every problem. I suspect Stroustrup does not believe this either. I often use Lisp or Smalltalk, but when I do, there are things I miss from C++. Please also note that, with the exception of the paragraph preceding this one, this message is not meant as a flame of the original posting, but a discussion of the reasons for some of the choices available in C++. -- David Wonnacott davew@tove.cs.umd.edu Although the moon is smaller than the earth, it is further away.
schwartz@groucho.cs.psu.edu (Scott Schwartz) (05/25/91)
jls@netcom.COM (Jim Showalter) writes: | Could you elaborate? I would like a better definition of "junk" than | is available above. I don't have a highly precise definition in mind. The notion involved is the difficulty of implimenting and using the language. Junk is not necessarily a derogatory term, it just reflects a presumption that every feature has to justify being there. | Which of the following is junk?: | [long list] Yes, all of that, and lots more. Junk is about both features and utility. If there are lots of features, that's junky. If it takes lots of rules to explain a feature, that's junky. If there are lots of associated special cases, that's junky. If the feature doesn't do its purported job well, that's junky. Just counting pages in the language reference may not be a good metric; you have to read the pages and see what they say. Naturally these sort of judgements are subject to debate, but to a first approximation I don't see that Ada is substantially more junky than C++.
sherman@unx.sas.com (Chris Sherman) (05/25/91)
In <2325@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes: >amount of time it takes to order a simple sandwich. They start asking you if >you want onions, or mustard, on the rye, with lettuce, without tomatoes. I >usually get confused because I am usually in a discussion while in a >restaurant. I just say a sandwich, but then the waitress will continue to >force me to chose me between an awfull lot of options. If we are talking personal experiences, I can go into a restaurant, concentrate on the menu for a few seconds, look deep into myself, and rattle off a list of things that I want. It's not too hard, and experience helps. >C++ looks to me like a big bag of options, and you just pick what you like. Cars are that way too. >Which I think is proven by the fact that in any discussion with a C++'er, you >will always hear the answer that you can also do it that way in C++. It's nice if someone can think for only a few seconds, and come up with a solution every time, instead of possibly wracking their brains for hours grappling with a less capable language. >It seems >that people have added so much to the language, that it has become an Edsel, >having features for all of us, but without identity. The identity is that it does have many features, and you can choose to use none of them, unlike other languages which offer limitations only. >Am I alone in that fact that I do not like to chose all the time. 1,000,000,000 Cobol programmers can't be wrong!!! >I feel >distracted because I have to spent so much time choosing and then later >reworking because I made the wrong choice. Does this mean that you can line up maybe 5 ways of doing something, determining which is best in terms of coding complexity, speed, memory usage, etc, and implement it? I have had a few classes while in college that included discussions of good/fair/bad algorithms and when to use them. It is nice to have a language which lets me do any of them easily (more or less). >From my experience in >Smalltalk I found that people tend to build the same kind of solutions to the >same kind of problems. That means that a programmer has to be schooled in only one kind of thinking, which implies no innovation, right? (yeah, I know, but still....) >It seems to me that that will hinder the reuse of software. Sticky subject. Good programmers can produce reusable software, even in assembler. Do we have to reduce languages down to the least skilled programmers? >When I look at other modern languages I see that they tend to remove the >number of language options, but have a very generic simple concept. Makes the programs easier to grade by instructors, really. >Lisp and >Prolog use lists and atoms and Smalltalk has the basic object. All of these >languages seems to be able to get away with no language defined keywords, >allowing the user to built constructs from a very simple syntax. Apples and oranges. If you need this type of programming environment, great. But if you were going to write an operating system, would such an approach be as easy? Every language has its own place and its on concepts. The trick is knowing which is good when. Oh, btw, if they have terms other than 0 and 1, then they have keywords. >Do we need all those diverse tools while a small subset allows us to build >the same kind of constructs. Would a small language not be much easier to >learn and allow more reuse? Saving in training and building cost? Assembler is small, but you don't see huge applications being built in it all the time. Maybe I don't understand what you mean... Does C++ imply a large set of complicated tools??? Won't you have a large set of tools after years of programming in anything? Do you like starting from scratch with every new project??? >Isn't this big bag of options making the language extremely difficult to >learn, as I can also see in the classes I teached C++, and will it not make ^^^^^^^ taught maybe...tsk tsk. :-) >it impossible to get the compilers right. Will the amount of options make it >impossible to validate a compiler? Chess is hard to get good at, but many have fun trying... Emacs has a large set of options, but many swear at/by it. Ada was validated in a sense, right? >This way of thinking reminds of RISC versus CISC. They changed the CPU's to >become much simpler, thereby offering more performance. Isn't C++ a CISL? C? The RISC and CICS debate is a different issue. The debate centers around ease of implementation, testing, heat dissipation, die size, compiler technology, marketing concerns, and a whole mess of other things. With the C/C++, we are talking aesthetics, ease of use, etc. We already know that just about every problem that can be solved in one language can be solved in another (in possibly a totally different way), is it how pretty the code looks that is the issue here. (BTW, we are not talking speed of computation or execution in this discussion.) >I am very curious about the opinion of other people about this subject. I do >not want to just criticize. Some parts of C++ are elegant and allow for nice >code, but I really miss the idea behind the language. I hope I am not right >in my judgement. It would be such a waste of all the efforts that go into the >language currently. I think the idea is that there are some people out there who are power hackers. They want a language that can let them hack at a power level. They want maximum options so they can explore new solutions... They want maximum control... They want a lump of clay that can me molded into anything. I think most of the other languages try to mold you. -- Chris Sherman .................... sherman@unx.sas.com | ,-----------------------------------------' / Q: How many IBM CPU's does it take to execute a job? | A: Four; three to hold it down, and one to rip its head off.
jls@netcom.COM (Jim Showalter) (05/25/91)
>My experience so far suggests that a more accurate statement might be >"Many will successfully produce `.H' files.". Certainly, there will >be successful products implemented in C++, but in a major industrial >site that I work at, there is an alarming trend: People who have been >charged with writing C++ code have, by and large, been producing >specs, class declarations and function prototypes in #include files. Within reason, this is actually a promising development. Instead of the classic "I don't have time to design it--we're already behind schedule, so start TYPING [is THIS where the phrase "strong typing originated? ;-)]" approach, C++ does bring with it a more disciplined tendency to emphasize specification over implementation. Considering that the design is really expressed via the specs, and considering that the implementation of the average method is such a no-brainer it could almost be automated, I think focussing on the specs is the proper thing to do. However, see caveats below... >So far, even after several months, precious little actual code has >been written. The problem appears to be not knowing where to start >and how to implement. I think Kriens' points apply directly to this >situation. They are faced with too many choices and are afraid to >commit themselves. This is the downside to emphasizing specification over implementation: you can run pretty short of implemented code. This quite understandably makes managers nervous, and in some cases it can crater a project. That is why the projects I've been involved with that were successful also did a lot of PROTOTYPING. Think of the spec as the theory: the prototype is the experiment that either validates or repudiates the theory. A methodology that emphasizes the design-a-little/code-a-little/demo-a- little/incorporate-feedback/repeat loop tends to produce better results than one that emphasizes design at the expense of implementation, or implementation at the expense of design (or, as is sometimes the case, documentation over everything...). I would urge the people on your project to PRETEND like they've ironed out the design, pick some critical threads through the architecture and implement them (yes, write actual CODE, perish the though), and then gather feedback on that prototype to help them further refine the specs. Not only will this give everybody a better feeling of where the project actually is, but it will help to overcome the fear and inertia, since the stuff in the prototype is not the "real" code (and may even be discarded), so don't get all bound up in knots worrying about making it perfect. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jls@netcom.COM (Jim Showalter) (05/25/91)
>] I'd be the last person in the world to defend C++, but I'm going to >] do it now... What keeps your project from adopting a standard that >] To be fair (I can't believe I'm doing this), I think Stroustrup did >] a remarkable job considering he needed to maintain compatibility with >] C. Of course, that means the putty shows pretty badly in the places > There is only one conclusion to draw from Jim's comments: > Jim Showalter has become a pod person... ARGHH!! Actually, I got off to a bad start earlier in this and a few other groups because I wound up coming off like a zealot and a bigot when I'm not. I don't damn C++ out of hand, and I certainly feel it is a preferable alternative to C if that's the only alternative available. There are features in C++ (and Eiffel, and others) I want to see migrated into Ada. On the other hand, I still regard Ada as the best choice for engineering large complex systems if that choice is available to you, and I have the success stories and experience to substantiate that claim. I think Ada has been shortchanged because people have this innate belief that anything coming out of the DoD can't be any good, and it's sad because the reality is that it IS good, it DOES work, and, besides, the DoD didn't have all that much to do with the language besides providing the funds--it was really dreamed up by a handful of clever Frenchmen and reviewed by literally thousands of experts. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jls@netcom.COM (Jim Showalter) (05/25/91)
>Maybe my perspective is warped from too many years working >for large corporations, but decisions about programming languages are >rarely (IMHE) made by the right people for the right reasons. I'm interested in both what you think the right reasons are, and who you think the right people are (no flame--I'm honestly curious). >Now in >a language such as Eiffel, you are *forced* to do *everything* in an >OOP manner, which, I believe is a good thing. Which can be both a blessing and a curse. It makes no more sense to me to claim that everything is an object than it does to claim that everything is a function. I have seen many cases where people have force-fit entities in the problem space into objects in the solution space (because they had no choice) when it was truly unnatural to do so. A common example of this is objects that have names like "Database_Manager" because they're really not objects at all--they're really just processes or control structures or top-most application code--but they had to be turned into SOME kind of "object" to conform to the OO paradigm. Every time I see an example of the English language being tortured like this to accomodate the strictures of the programming language, it is a red flag for me. Some things are objects, some things are not objects. C++ at least acknowledges that fact, and permits a more hybrid style of programming. Languages that do NOT permit hybidization are as restrictive and constraining as the ones they are intended to displace. My objective is to write software that is as understandable as possible. If that means I have both objects and other kinds of things in my code, then so be it: I'd rather have a more intuitive solution that is not Politically Correct[tm] than a "pure" OO solution that is artificially slanted to the paradigm du jour. > Most likely many > will choose C++ simply because it: > a) is well known and is a successor to the immensely popular C. > b) it is readily available, *now*, on most platforms. > c) AT&T is behind it, which is related to a) and b). d) isn't Ada ;-) -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
purtill@morley.rutgers.edu (Mark Purtill) (05/25/91)
gyro@kestrel.edu (Scott Layson Burson) writes: >I think one answer is that there should be a definitive style guide >for C++, one which is comprehensive enough that it comes to be >considered as essential a desk reference as the reference manual >itself. Does anyone know if someone is writing such a book? Perhaps >I should. You could write one, but I doubt that it would be "definitive". People can't even agree on how to *indent* C; do you really expect them to agree on how to *use* C++? ^.-.^ Mark Purtill purtill@dimacs.rutgers.edu (908)932-4580 (O) ((")) DIMACS, P.O. Box 1179, Rutgers U., Piscataway, NJ 08855 (908)220-6905 (H) ********** Note new area code! We are now (908) rather than (201)! **********
aipdc@castle.ed.ac.uk (Paul Crowley) (05/26/91)
In article <May.25.12.25.28.1991.5590@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes: >gyro@kestrel.edu (Scott Layson Burson) writes: >>I think one answer is that there should be a definitive style guide >>for C++, one which is comprehensive enough that it comes to be >>considered as essential a desk reference as the reference manual >>itself. Does anyone know if someone is writing such a book? Perhaps >>I should. > You could write one, but I doubt that it would be >"definitive". People can't even agree on how to *indent* C; do you >really expect them to agree on how to *use* C++? I think some sort of C++ style guide would be a good idea. Plenty of companies have _rules_ (not guidelines) on how to indent your programs, what names to give your procedures and variables, and so on. C++ offers potential for obfuscation that leaves C standing, and some sort of guidebook would not only help others read your programs (in some cases _allow_ others to read your programs) but also help you program large things since if you know you did 99% of it in the suggested style, you can hold the program in your head more easily and you know the object you designed last year doesn't do weird things. I'd especially appreciate advice on where to put your pointers. And I've already thought of the joke about this and my signature. ____ \/ o\ Paul Crowley aipdc@castle.ed.ac.uk \ / /\__/ Part straight. Part gay. All queer. \/
jls@netcom.COM (Jim Showalter) (05/26/91)
> Sticky subject. Good programmers can produce reusable software, even in > assembler. Do we have to reduce languages down to the least skilled > programmers? Arguably, yes. If the bulk of the programmers out there aren't able to use the advanced features of a language (any language) effectively, they do not benefit from such features. One can argue about the need to educate programmers and increase the mean level of expertise, and that is all a fine and wonderful objective, but the simple fact is that it 1) may not work and 2) takes a lot of time and effort. In the meantime, what does one do for non-expert programmers NOW to make them more productive? It seems to me that if one is truly interested in affecting the overall productivity of the software industry, the best place to focus one's efforts is on helping the average to sub-average programmer, not developing increasing abstruse languages for the elite who can really make use of their features. An alternative strategy I've seen adopted at a number of sites is to admit up front that not everybody is equally talented (and that, in fact, many people truly would prefer NOT to be expected to be top-notch software designers and architects) and divide responsibilities accordingly. A project really only needs a handful of architects (in fact, too many architects get in each other's way), so why not structure things so that you only HAVE a handful of architects? Similarly, a project needs more subsystem-level technical leads and spec designers, and a large number of coders, testers, integrators, documentors, and configuration managers. Some people find this ranking and classification of people offensive, but I think that is more an artifact of the hacker mindset than anything else--certainly software seems unique among pursuits in its relentless emphasis on egalitarianism at the expense of sound management. Face it: not everyone is an architect, and it is actually rather cruel to expect them to pretend to be (and it affects the quality of the resulting design). > Chess is hard to get good at, but many have fun trying... But few achieve the level of master or grandmaster. Note how nicely this reinforces my previous comments. > I think the idea is that there are some people out there who are power > hackers. They want a language that can let them hack at a power level. > They want maximum options so they can explore new solutions... They want > maximum control... They want a lump of clay that can me molded into > anything. Indeed. There are proportionally MORE people, however, who are NOT these so-called power hackers and who are simply confused and dismayed by having so many options made available to them. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
jgro@lia (Jeremy Grodberg) (05/27/91)
In article <2326@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes: >For example, maybe people can show me a solution >to the following problem > > struct Linked { Linked *next(); }; > struct My {}; > struct MyLinked : public Linked, public My {}; > main() { MyLinked *x; x = (MyLinked*) x->next(); } > (BTW, this compiled with an internal error in Zortech. > it worked with an intermediate, so I guess it is ok?). > >It is a very easy problem, but it forces me to downcast >the next procedure to a MyLinked. I solved this problem with macros, and will be able to solve it with templates when my compiler supports templates. The key is to make Linked a template class which take and returns pointers to whatever class you want. In one implementation I created, there were 2 template classes. The first template class defined an object with pointers to the derived class, and some operations on those pointers, and the second template class made a list of objects of the first template class. Many people complain about how complex C++ is, and how useless or counter-productive C++'s strong type checking and implicit conversion is. For myself, I have found ways to use them that have gone very far in having the compiler validate my code, and have made me much more confident that my code actually works. Yes, I spend a lot of time cleaing up warnings from the compiler, but once I do, I usually have very few bugs. C++ takes time to learn, but so does any object oriented language. Object oriented concepts are hard to learn and use well, because there are a lot of possibilities which serve immediate needs, but few are good for future growth; it takes practice to learn how to make good choices. I think that once the industry gets more collective experience, the complexity of C++ will not be a problem, but rather a bonus. When I learned C, I was glad there were people around to tell me about standard C coding style, and standard ways of doing things, because I didn't have any way to choose among various essentially equivalent options. We have the problem with C++ that there is no standard way. But C++ has only been in widespread use for 1 year, and the language isn't finished yet (with templates and exception handling a must-have on most people's feature list). Now is the time to explore the possibilities of the language, and learn its unique advantages. If you don't want to do that, then you can just write ANSI C with mandatory function prototypes, and compile it under C++, for no added complexity, and no need to use lint. And I also understood >that on certain implementations this might not work at >all because of virtual bases etc. Help.... If I am >right in understanding that this is basically the only >way to do it, then I dont understand the type safety >of C++, if you are forced to bypass it many times, >it does not seem very usefull? > >-- >I also got some questions why I complained about the >const keyword. I tried to explain that though the >concept is stated quite clearly, it seems that once you >start using it, you end up changing a lot of old code >and it propagates fast! If you start afresh I found >it was mostly annoying, just another thing to distract >you from the problem domain. > >--- >One person made a very good comment about extendability: > >> However this messiness is also a strength. When c users needed >> new features, there were a number of techniques that could be used to >> implement needed constructs. I contrast it with Pascal, an elegant >> minimal language. When pieces were found to be missing from Pascal, such as >> string manipulation, it was very hard to add them in. In this country >> C has become a dominant implementation language, and I attribute it to the >> fact that users were able to do things in the language that the original >> designers had never anticipated, whereas a minimal spanning language lacks >> the redundancy that provides for improvisation. > >I completely agree with the fact that a language should >be extendable. But strange enough I found that languages like >C and C++ are definitely not extendable. Both languages have >defined keywords which you definitely cannot change. You >cannot implement your own if or virtual. I found that in >Smalltalk all this is possible because there are no keywords >in the language, just like Prolog. And what I understood from Lisp this >is also the case. So if you talk about extending a language, >then C(++) is definitely not an extendible language. The >usuage is fixed (well as long as Bjarne can keep his >hands of the definition, ehhh.. sorry which definition?). > >---- > >A common remark, to which I agree, is that whatever >I think about it, it will be the dominant language of >the 90's. Somebody wrote: > >> programming. However, I think C++ will become the major language for >> many environments, while alternatives like Eiffel, Objective-C, and >> such will languish in relative obscurity, because of the ease of >> moving to C++ from C and its wide availability. > >I do not agree with the fact that Eiffel and Objective-C >will vanish. There will always be an audience which makes >their choices on performance. If not, the Macintosh would >have vanished long ago. > >One way or the other the industry seems to chose >non-optimal solutions. We got stuck with MS-DOS, Windows >and C++. I will use it, but I will always have a feeling >that it could have been much easier if choices were made >on performance instead of just marketing. > > Peter Kriens > > -- Jeremy Grodberg "Show me a new widget that's bug-free, and I'll show jgro@lia.com you something that's been through several releases."
dlw@odi.com (Dan Weinreb) (05/27/91)
Sometimes there are two ways of doing something, and there are tradeoffs between them. Is this uniquely American? I haven't done any work overseas; perhaps I'm just provincial. In your country, are all sorts always done with quicksort, never with insertion sorts or heapsorts? Are all computer programs written in one language? Do all (or none) programmers always use languages with (or without) lots of runtime checks? It had never occurred to me before that there was something American about the concept of choosing between engineering alternatives based on tradeoffs. I do agree that it is best when you can change your mind about which choice to make, late in the game, with minimal alteration of your program. There are certainly areas in C++ where the language could be better in this regard; but to have designed it to be better in this regard might have meant compromising on one of the other goals of C++. It's easy for you to complain about things you don't like; it's harder to come up with an alternative proposal that meets the same criteria that the design of C++ set out to meet. By the way, it's easy for you to say the "Lisp just has lists and atoms". The baby Lisp that your learned about in school probably really does just have lists and atoms. Real Lisp dialects that are used for serious work have quite a few data types, including arrays and objects and several kinds of numbers and so on. And this is true of the European proposed standards, not just the American ones.
dlw@odi.com (Dan Weinreb) (05/27/91)
In article <31061@dime.cs.umass.edu> connolly@livy.cs.umass.edu (Christopher Connolly) writes: I agree wholeheartedly. The language is probably too big for its own good, and its bigness results from an obsession with backward compatibility and efficiency. It is precisely because of its backward compatibility and its efficiency that C++ is becoming so popular and successful. If you don't care about those things, of course, you are free to use another language. (Here in America, we have choices! :-) >IMHO, C++ promotes building a typesafe object-based *application*. We've been through this before - I don't see what's "safe" about being able to cast pointers back and forth at will. As has been pointed out previously, the programmer who lies to the compiler is asking for trouble, but this fact doesn't make C++ "typesafe". He said that it "promotes" it, not that it enforces it. You might prefer a language that didn't provide any way to override the type system. To me, that would be like riding in a car in which the seat belts welded shut. I always wear seat belts, but I do like the ability to override them from time to time when the need arises. My experience so far suggests that a more accurate statement might be "Many will successfully produce `.H' files.". Plenty of companies have already produced substantial products written in C++. Continued arguments about how it cannot happen, or will never happen, are rather unconvincing.
dlw@odi.com (Dan Weinreb) (05/27/91)
In article <1991May24.205554.10284@ugle.unit.no> aarsten@idt.unit.no (Amund Aarsten) writes:
for everyone, every language has strong and weak points. For instance, I don't think
Lisp is a very good choice for doing 3D graphics!
I suppose you said this thinking that it was obviously true, that
doing 3D graphics in Lisp would obviously be a joke. Actually, the
Symbolics Graphics Division has been producing and selling for years a
group of 3D graphics products written in Lisp. Of course, I'm talking
about a serious heavy-duty production Common Lisp, not a "you can
write a Lisp interpreter in 100 lines of code" toy of the sort that
many textbooks describe. The Symbolics Graphics Division tools were
used to produce some lovely 3D animated graphics, including quite a
lot of TV commercials.
(I realize that this has nothing to with OOP, but I could not let
that remark go by without comment.)pkr@media03.UUCP (Peter Kriens) (05/27/91)
Nick Sherman responds to my wiatress posting > >Which I think is proven by the fact that in any discussion with a C++'er, you > >will always hear the answer that you can also do it that way in C++. > It's nice if someone can think for only a few seconds, and come up with a > solution every time, instead of possibly wracking their brains for houre. > 1,000,000,000 Cobol programmers can't be wrong!!! A: I feel that you are confusing the fact that solving a problem is important and that your brain energy should be directed to the problem domain, and not in figuring out which is the optimum solution of the language. Almost all problems I see in the C++ group arise from the complexity of the language. You state that certain things are hadr/impossible to do in another language, while I can't see why you need to wrack your brains if there is usually a natural solution. > >I feel > >distracted because I have to spent so much time choosing and then later > >reworking because I made the wrong choice. > > Does this mean that you can line up maybe 5 ways of doing something, > determining which is best in terms of coding complexity, speed, memory usage, > etc, and implement it? I have had a few classes while in novation, right? ( > yeah, I know, but still....) First I often found that writing a class offered me better insight of where the problems were. In other environments this didn't cause as much trouble changing the design as it cost in C++. It seems you cast code in concrete >>When I look at other modern languages I see that they tend to remove the >>number of language options, but have a very generic simple concept. > Makes the programs easier to grade by instructors, really. Yes, but if a language is easy to teach, while not minimising the possibilities, isn't that a good thing? I believe there is something like Occam's razor which states that a simpler theory while still encompassing all the facts is better than a more complex... I guess this also applies to languages. >>Lisp and >>Prolog use lists and atoms and Smalltalk has the basic object. All of these >>languages seems to be able to get away with no language defined keywords, >>allowing the user to built constructs from a very simple syntax. > A after years of programming in anything? Do you like starting from scratch > with every new project??? Did you ever use one of these environments? It seems that reuse in these language is completely automatic. And why? I think because other people were able to built constructs, that are very easy to understand and reuse, the language does not get in the way. Especially in Smalltalk, you start on top of a big system. This would be bad if you could not change, but because the language does not contain keywords (or reserved words) you could even implement a false,true and maybe, on the same level as the original true and false. So I definitely do not like to start from Scratch, that is why I do not use C++. >>Isn't this big bag of options making the language extremely difficult to >>learn, as I can also see in the classes I teached C++, and will it not make > ^^^^^^^ > taught maybe...tsk tsk. :-) It is always nice to be criticized in an area where you are at a disadvantage because English is not your native tongue. Really relevant here. >>This way of thinking reminds of RISC versus CISC. They changed the CPU's to >>become much simpler, thereby offering more performance. Isn't C++ a CISL? > C? I meant Language... > The RISC and CICS debate is a different issue. The debate centers around > ease of implementation, testing, heat dissipation, die size, compiler > technology, marketing concerns, and a whole mess of other things. With the > C/C++, we are talking aesthetics, ease of use, etc. We already know that > just about every problem that can be solved in one language can be solved > in another (in possibly a totally different way), is it how pretty the code > looks that is the issue here. (BTW, we are not talking speed of computation > or execution in this discussion.) Do you mean pretty or readable and even more understandable? Because if you mean that I think C++ is at a big disadvantage. What I mean is that Matrix A = B + C, looks nice, unless you know there is a problem and you start looking what is happening, if you can find it. > I think the idea is that there are some people out there who are power > hackers. They want a language that can let them hack at a power level. > They want maximum options so they can explore new solutions... They want > maximum control... They want a lump of clay that can me molded into > anything. I think most of the other languages try to mold you. I agree that some people want a language like C++, but my question is will this contribute to better systems which are developed in a shorter time and will need less maintenance. I have been manager of 14 software people and I know how easy it is to get carried away with the fact that you overload the + operi]ator... But I dont think it has anything to do with productivity and quality. IMHO I think that you focus on the language itself instead of a language as an efficient tool to implement solutions. Peter Kriens pkr@media01.uucp
rockwell@socrates.umd.edu (Raul Rockwell) (05/27/91)
Amund Aarsten:
for everyone, every language has strong and weak points. For
instance, I don't think Lisp is a very good choice for doing 3D
graphics!
but then there's AutoCAD.
Raul Rockwellrsargent@alias.com (Richard Sargent) (05/27/91)
In article <31061@dime.cs.umass.edu> connolly@livy.cs.umass.edu (Christopher Connolly) writes: >My experience so far suggests that a more accurate statement might be >"Many will successfully produce `.H' files.". Certainly, there will >be successful products implemented in C++, but in a major industrial >site that I work at, there is an alarming trend: People who have been >charged with writing C++ code have, by and large, been producing >specs, class declarations and function prototypes in #include files. >So far, even after several months, precious little actual code has >been written. This is funny! If you look at the world of Information Systems (where I actually started many years ago), this is exactly what they DO want to achieve. The claim there is that people start coding TOO SOON, before they understand the problem fully. The studies done by various groups (I can't recall exact attributions) seem to all agree that you want to push as much "correctness" into the earliest stages of the development cycle, since fixing things during testing "costs" about 1000x (!) what it would have cost to found the problem earlier in the design cycle. Personally, I find the number 1000 to be too large to want to take on faith, but that is what I have read. Probably, it is true for a major system for a major company, such as American Express, or perhaps Exxon, etc. Most projects I have ever been involved leave me claiming the cost factor is closer to 100x than 1000x, but it is still a huge factor. > The problem appears to be not knowing where to start >and how to implement. I think Kriens' points apply directly to this >situation. They are faced with too many choices and are afraid to >commit themselves. I am fairly convinced that this would not have >happened if the project's language had been C. > I am sure that this wouldn't be the case if they were using C. I fear that they would have been implementing from day 1, and then spend many extra months "debugging", including revising some significant design decisions. I have done it both ways. I much prefer getting it right, up front. Check out some of the Software Engineering studies/discussions.
diamond@jit533.swstokyo.dec.com (Norman Diamond) (05/28/91)
In article <1991May25.051758.9731@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >>My experience so far suggests that a more accurate statement might be >>"Many will successfully produce `.H' files.". > >Within reason, this is actually a promising development. Instead of >the classic "I don't have time to design it--we're already behind >schedule, so start TYPING [is THIS where the phrase "strong typing >originated? ;-)]" approach, C++ does bring with it a more >disciplined tendency to emphasize specification over implementation. Yeah, this used to be called top-down specification, design, and development. But now it is derisively referred to as "waterfall model." In my first job, I architected a software system by specifying the interactions of various objects. (That language had process objects and monitor objects. Classes were also available for encapsulation but were parts of the processes or monitors that owned them. I specified the calling sequences of all of the messages from processes to monitors for that system.) Anyway, I was criticized for not including any pseudo-executable pseudo-code in the architecture. Yeah, that weekend's work (one Saturday and one Sunday) was far from complete, and I was criticised for it. Ever since then, I have watched this industry move backwards. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it. Permission is granted to feel this signature, but not to look at it.
rh@smds.UUCP (Richard Harter) (05/28/91)
In article <1991May27.042830.674@odi.com>, dlw@odi.com (Dan Weinreb) writes: > Sometimes there are two ways of doing something, and there are > tradeoffs between them. Is this uniquely American? I haven't done > any work overseas; perhaps I'm just provincial. In your country, are > all sorts always done with quicksort, never with insertion sorts or > heapsorts? Are all computer programs written in one language? Do all > (or none) programmers always use languages with (or without) lots of > runtime checks? It had never occurred to me before that there was > something American about the concept of choosing between engineering > alternatives based on tradeoffs. One of us (at a minimum) is missing the point, which I perceive as being about defaults. The, ah, object of the game is to minimize the making of unnecessary decisions, thus reducing both the amount of code to be written and the amount of intellectual labor. Compare a frame (in AI jargon) versus a class. When I instantiate an object using a frame all attributes are filled in with default values. If I set the value of a specific attribute, the default values of all attributes dependent on the specified attribute are adjusted accordingly. [Suitable disclaimers for various implementations are included here by default. :-)] To take your example, in many applications it doesn't particularly matter what kind of sort I use -- I just want my data sorted. What you have omitted in your discussion of tradeoffs are the costs of making and implementing tradeoff decisions. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
jls@netcom.COM (Jim Showalter) (05/28/91)
diamond@jit533.swstokyo.dec.com (Norman Diamond) writes: ]>In article <1991May25.051758.9731@netcom.COM> jls@netcom.COM (Jim Showalter) writes: ]>>>My experience so far suggests that a more accurate statement might be ]>>>"Many will successfully produce `.H' files.". ]>> ]>>Within reason, this is actually a promising development. Instead of ]>>the classic "I don't have time to design it--we're already behind ]>>schedule, so start TYPING [is THIS where the phrase "strong typing ]>>originated? ;-)]" approach, C++ does bring with it a more ]>>disciplined tendency to emphasize specification over implementation. ]>Yeah, this used to be called top-down specification, design, and development. ]>But now it is derisively referred to as "waterfall model." If you read the rest of my post, I am not a big fan of the classical waterfall model, since I regard it as completely unrealistic and doomed to failure (I prefer to call it "top-down omniscient"). No theory can be considered valid until checked by experiment: designs MUST be tested by prototyping, and feedback must be accomodated. My bias is toward a disciplined process of specification, prototyping, refinement of specification, and iteration until a stable set of golden specifications is arrived at. The .h file disease is often due to the unwillingness of anybody to write any actual code until the entire design is "done", despite the fact that the design can't very well be done until it has been verified--and it can't be verified until it has been prototyped. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
schwartz@possum.den.mmc.com (Michael Schwartz x1-6820) (05/29/91)
1) I'm glad to see that language bigots are getting the worst of this. We can't afford to be language bigots anymore. So many solutions to problems seem to involve (a) inventing a language for describing the solution and (b) compiling that language to a reasonable target (e.g., Ada, C++, C, assembly). 2) If you believe in very large programming projects (>1Megaline) you almost have to believe in Ada. It works. 3) If you believe in very large programming projects you have a hard time believing in assembly, fortran, and C. 4) There is no compelling reason to believe in C++ yet. But you have to admit it's fun (and there probably is such a reason somewhere) -- thanks Bjarne. 5) If you believe in very large programming projects you learn to give up believing in code delivery before specification delivery. In OOP terms, you must play object ping-pong before you believe your design will work. 6) Today's 're-usability' is just like yesterday's 'port-ability'. You may not close your eyes and expect it to work. Today's 're-usability' still has a huge, researchy library science aspect to be solved. Well, I feel better already. Michael -- schwartz@pogo.den.mmc.com "You'll find ... that the only thing mschwartz@mmc.com you can do easily is be wrong, DISCLAIMER: The opinions expressed are and that's hardly worth the effort" not necessarily those of my employer or myself. --the phantom tollbooth
nic@mrcu (Nick Chapman) (05/30/91)
Has anybody else noticed the ever-so-slight change in Jim Showalter's nifty signature ? Here's what it used to be : >**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ***************** >* Proven solutions to software problems. Consulting and training in all aspects* >* of software development. Management/process/methodology. Architecture/design/* >* reuse. Quality/productivity. Risk reduction. EFFECTIVE OO techniques. Ada. * Here's what it is now : >**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** >*Proven solutions to software problems. Consulting and training on all aspects* >*of software development. Management/process/methodology. Architecture/design/* >*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. * Is this why Jim thinks that C++ is such a great language, second only to the God of all languages, Ada ? :-) Nick. ------------------------------------------------------------------------------- Nick Chapman, GEC-Marconi Research Centre | INTERNET: nic@uk.co.gec-mrc Great Baddow, Chelmsford, Essex. CM2 8HN | Tel: +44 245 73331 x3245 ------------------------------------------------------------------------------- -- ------------------------------------------------------------------------------- Nick Chapman, GEC-Marconi Research Centre | INTERNET: nic@uk.co.gec-mrc Great Baddow, Chelmsford, Essex. CM2 8HN | Tel: +44 245 73331 x3245 -------------------------------------------------------------------------------
jls@netcom.COM (Jim Showalter) (06/06/91)
>Has anybody else noticed the ever-so-slight change in Jim Showalter's >nifty signature ? Hmmmm--must be a typo... Actually, yes, it's true--I added C++ to the list. Part of this is due to an economic pragmatism that seems to be afflicting me now that I don't have a steady paycheck (a reporter once asked Willy Sutton, the bank robber, why he robbed banks, to which Willy Sutton replied "Because that's where they keep the money."...I feel somewhat like this when it comes to C++). A far more significant reason for the change, however, is that the stuff I know about engineering large complex systems is pretty much language independent, so why limit myself to Ada shops? If Ada shops need help with their software engineering process, it's a sure bet that C++ shops do too. Note that this in no way indicates a change to my bedrock conviction that Ada is the superior technical choice between the two languages for engineering large complex systems. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
kelley@elmer.Berkeley.EDU (Michael Kelley) (06/07/91)
In article <1991Jun6.004107.25123@netcom.COM>, jls@netcom.COM (Jim Showalter) writes: > > [ stuff deleted ] > > Note that this in no way indicates a change to my bedrock conviction that > Ada is the superior technical choice between the two languages for engineering > large complex systems. > -- Could you expand on this, Jim? Given that C++ is slated for both parameterized types and exception handling, will your conviction still hold? It seems to me that Ada has an edge on C++ for its concurrency support (the rendezvous), but falls way behind C++, not having late binding (virtual) functions. Or is it just a practical matter of C++ still paying out too much rope to hang a project with? Comments? Mike Kelley Tandem Computers, Austin, TX kelley@mpd.tandem.com (512) 244-8830 / Fax (512) 244-8247
jls@netcom.COM (Jim Showalter) (06/07/91)
>> Note that this in no way indicates a change to my bedrock conviction that >> Ada is the superior technical choice between the two languages for >engineering >> large complex systems. >> -- >Could you expand on this, Jim? Given that C++ is slated for both parameterized >types and exception handling, will your conviction still hold? It seems to me >that Ada has an edge on C++ for its concurrency support (the rendezvous), but >falls way behind C++, not having late binding (virtual) functions. Or >is it just a practical matter of C++ still paying out too much rope to >hang a project with? Comments? Ada has a proven track record, including successes on some of the most ambitious projects ever attempted. Compilers for the language are validated, the language definition is stable, and industrial strength tools that scale to multi-million line projects are commercially available. A number of textbooks and training materials are available that discuss how to use Ada for real systems. Ada was designed from the ground up for optimal software engineering support and does not suffer backward compatibility with a dangerous, non-engineering oriented hacker language. Ada was also designed for maximum readability and maintainability (yes, you can write wretched code in Ada, but you have to be perversely motivated to do so: you don't have to work hard to write readable code in Ada, since the language doesn't fight you in that effort but, rather, aids you as much as possible). Ada provides fewer of the options that were discussed on a different thread in this group, so learning one idiom is usually sufficient. Ada isolates the programmer from hardware peculiarities except when the programmer specifically asks to be not isolated--addresses, registers, and other such non-portable entities are conveniently abstracted away in the general case. The culture that has grown up around Ada is software engineering oriented, as opposed to the culture that grew up around C (and from who's ranks the C++ culture is being drawn). To put it another way, I would argue that C++ will be the equivalent of Ada for engineering large complex systems when it has a stable language definition, the compilers for it are validated, there are industrial strength tools available for it that scale cleanly to projects of arbitrary size and scope, there is a solid base of experienced C++ software engineers (as opposed to hackers) as well as an extensive set of cultural artifacts (e.g. style guides, textbooks, etc), and there are a number of proven success stories of C++ being used on significant projects. Until that day (and I argue that that day is quite a ways off), I stand fast in my claim that Ada is a better choice than C++. -- **************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 **************** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *