Xref: utzoo comp.object:3595 comp.lang.c++:13668 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uakari.primate.wisc.edu!xanth!mcnc!rti!mozart!sherman From: sherman@unx.sas.com (Chris Sherman) Newsgroups: comp.object,comp.lang.c++ Subject: Re: C++ and waitresses (long) Message-ID: Date: 25 May 91 02:12:53 GMT References: <2325@media03.UUCP> Sender: news@unx.sas.com (Noter of Newsworthy Events) Organization: SAS Institute Inc. Lines: 123 Nntp-Posting-Host: foster.unx.sas.com 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.