In article <·················@netcom.com>, ·······@netcom.com (james brister) writes:
|> In article <··········@jabba.ess.harris.com> ···@trantor.harris-atd.com (Mike McDonald) writes:
|>
|> [ talking about the C++ designers ] ....
|>
|> What a load of crap. The primary consideration was bit-level
|> compatabilty with C. The idea was to add as much OO to C as possibly,
|> but impose no penalty if a programmer chose not to use the OO features.
|> And they succeeded.
Aside from the penalties of using an inherently error-prone language
whose syntax makes easy-to-read code impossible to write, you mean?
You might have said "no penalty other than those imposed by C itself...."
|> Someday you people will get a clue that C++ was not designed to be
|> answer to the world's OO needs.
You certainly didn't need to tell me that! Nonetheless, regardless of
intent, C++ is having a major impact on the world's impression of what
OO means. For this reason alone, it behooves OO proponents to try to
make C++ into something we can be proud of, or at least reasonably happy
with as a medium for doing work.
If you don't like the compile time
|> contraints or inheritance restrictions (better than Smalltalk though,
|> from what I hear) or any other failings that many of you (with
|> self-important ideas on what a language should be) will whine about,
|> then don't use it.
No, it isn't better than Smalltalk. It's quite a bit worse (IMHO,
speaking as someone who has done real work using both C++ and Smalltalk,
as well as Lisp/CLOS). I am currently doing Smalltalk work - I worked in
C++ for a while after Lisp opportunities ran out, but the pain level was
pretty high. I was happy to find work using Smalltalk, and I sincerely
hope that it lasts a while.
Go use eiffel or Modula-3 or LISP where the
|> abstraction gets better, but the run-time penalties get bigger.
You are mistaken. The full explanation is lengthy, so I won't burden
the list with it, since most readers probably already know the story.
Briefly, though: the runtime penalties in Lisp only exist as tradeoffs
against development time and effort. In general (there may be specific
exceptions, particularly with regard to some lisp implementations - it
is very important to distinguish implementation artifacts from design
issues here), the performance "penalties" that you pay for efficient
Lisp development can be removed. The development penalties that you
pay for runtime efficiency in C/C++ are inherent and unavoidable.
|> This all sounds like a lot of sour grapes to me. C++ and LISP weren't
|> meant to compete in the same programming arena--I'd no sooner choose
|> C++ to write a symbolic math package than I'd use LISP to write a
|> network transport package.
I wouldn't choose C or C++ to write anything. I would happily use Lisp
for any programming task, other factors being reasonably equivalent.
|> Perhaps you won't get a clue. Too bad.
|>
|>
|> James (LISP *AND* C++ programmer and proud of it)
|> --
|> James Brister ·······@vix.com
|> decwrl!vixie!brister
In article <··········@pulitzer.eng.sematech.org> ······@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes:
For this reason alone, it behooves OO proponents to try to make C++
into something we can be proud of, or at least reasonably happy
with as a medium for doing work.
I'd settle for
doesn't-make-me-want-to-pull-all-of-my-hair-out-at-least-once-a-day.
For a good time, ask someone who thinks that C++ is cool for OO programming
how they deal with method combination. 9 out of 10 of them won't know what
you're talking about. The 10th will explain to you that it's a stupid
idea. Not addressed by C++ ==> not worth knowing :-)
--
Rick Busdiecker <···@lehman.com> Please do not send electronic junk mail!
Lehman Brothers
388 Greenwich Street "A little rebellion now and then is a good thing"
New York, NY 10013 - Thomas Jefferson