Path: utzoo!utgpu!attcan!uunet!ncrlnk!ncrcae!ncr-sd!hp-sdd!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Objective-C vs C++
Message-ID: <6590068@hplsla.HP.COM>
Date: 2 Nov 88 19:40:25 GMT
References: <8335@nlm-mcs.arpa>
Organization: HP Lake Stevens, WA
Lines: 67

> At USENIX/C++, I said that C++ is too complex.  Much recent net
> discussion has added support to this claim.  C is basically simple
> (declarations and operator precedence are awful, of course).  C++ is
> incredibly complex.  The number of caveats which productive C++
> programmers must grasp is simply too large: must have virtual
> destructors, can't have virtual constructors (makes sense, but it is
> obscure); when one must use [] on delete, and when they are not needed;
> only use multiple-inheritance when you have the source of all classes
> back to their roots because a client can introduce bugs which a C++
> compliler won't catch; etc. etc. etc.
> 
> I am not convinced that Objective-C is a good way to go: lack of strong
> typing for example.  However, it is certainly a MUCH smaller addition
> to C than C++.

Well, I programmed in ObjC for a couple years, and pretty much all your
C++ gripes have their analogies in the ObjC language too, although one
might not realize it until one starts trying to write serious code in
ObjC.

Additionally, ObjC is "simple" because it lacks the complete feature
set that C++ is striving for that is needed to solve "all" common
programming problems.  But if you're writing serious code you still
have to address these needs.  In ObjC you have to do this by writing hack
C code or assembly code based on an understanding of ObjC's underlying
implementation in the C language.  So you have to understand a
hell of a lot of the implementation of ObjC in order to write
serious programs in the language.  Which in my experience makes
ObjC much more complicated to deal with any time.

Also, when things go wrong in your programming, C++'s failure modes
come much closer to being C-like in nature -- "what you program
is what you get."  In ObjC its because the phyla tables get
confused, or wrong code is generated or something, and all of a
sudden your problem to be debugged has no apparent correspondence
to the code you programmed.

And among object oriented languages, only C++ seems to have the
runtime efficiencies to make it viable for most commercially 
developed code.

Certainly, anyone who intends to become shall we say "professional"
at writing Object Oriented code is going to have to become
proficient in a lot of "new" issues that don't come up as often
in C code writing -- memory management schemes, garbage collection
schemes, multiple inheritance, container schemes, try/recover
schemes, constructors, destructors.

Part of this difference comes from the C++ implied claim that there
is not just one best way of doing these tasks -- that in more
critical cases programmers are going to have to make informed
choices as to what memory management schemes to use, whose libraries
to use, or when to write their own libraries.  So C++ allows these
choices.  And multiple vendors are writing compilers and libraries
for C++ to support these choices.  Whereas ObjC only gives you
one choice.

Some people who seem to be pretty happy working with ObjC are
those people who are using ObjC to encapsulate window graphics
routines written in C or assembly.  In these cases most
of the processing time is spend in the low level graphics
routines so that the ObjC overhead is less of a problem.

I think many "standard" programming tasks will prove to be too
slow when written in ObjC unless one seriously hacks at ObjC's
underlying implementation in C.  This has been my experience.
And this leads to some pretty gross code.