🚀 go-pugleaf

MKK2@psuvm.psu.edu writes:

>One thing that makes Obj-C "better" is that it lacks a large number of features
>that C++ has but doesn't need.  Computer science has been fighting the
>battle for a long time.  Should a language offer every possible feature,
>or should it offer a slimmed down subset of just enough features?

I am sure that you could find many C++ programmers who would agree
that the language is complex, and that there are features that could
be removed.  I doubt you could get them all to agree on which features
to remove.

The success of C++ in the industry (to date) is strong testimony to
the notion that the language needs the features it has.

>The Obj-C reference manual on my machine is only 36 very light weight pages
>long (though it assumes you know C 8-).  Just the index for C++ is longer than
>that.

It is quite true that, knowing C, and a little about OOP, Objective C
is quite easy to pick up and use.  Moreover, it provides an OOP
envioronment which performs reasonably well; quite adequate for all
but the most demanding applications.

But, with a few notable exceptions, the industry is putting its muscle
behind C++.  

I find this somewhat surprizing since programming in C++ is very
little like programming in C.  C is flexible and casual, and C++ is
rigid and formal.  Objective C shares the casual and flexible nature
of C.  Yet, most C programmers who are migrating to OOP are accepting,
even demanding the formality of C++ in favor of keeping the causal
environment of C and objective-C.

I know why I, and a few of my friends and associates made that choice;
but I can't speak for the whole industry.  We wanted formality because
we were tired of fighting the maintenance nightmares caused by the
casual nature of C.  We wanted the compiler to lay down strong typing
rules, const rules, rules about instantiating abstract classes, rules
about downcasting and upcasting.  We wanted our programs to be
difficult to compile, because the effort spent in getting a program to
compile is much more efficient than the effort spent in debuggin an
executable.  Every type-error or usage error that the compiler forces
us to remove, saves us the effort of debugging some terrible execution
failure due to type mismatch.  

I and my associates have not been dissapointed by the results.  We
rail and moan against the complexity and odd nature of the language,
but we spend a lot less time debugging.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++