Re: True faiths ( was Re: The true faith )

[tshawke@qwest.com (Tom Hawker)]

Immanuel Litzroth <immanuell@enfocus.be> wrote in message news:<m2advh9oz5.fsf@enfocus.be>...
> 
> In this respect the articles...
> 
> Immanuel

I read through both of these articles.  I have also read through all
of the responses to this subthread.  I am not a C++ expert, but I have
a background in computer languages.  I would not have gotten a
"perfect" solution, but the problems associated with "owning" pointers
were obvious, and really should be so to anyone with a basic OO
background, which I guess eliminates most of the C++ programmers. ;-) 
My solution did not include transactions (the try/catch stuff),
because I would have assumed a failure to be catastrophic (an
oversight of the stated problem requirements).  Unwise, perhaps...

But all that aside, I am surprised that everyone seems to have missed
an underlying concept.  Most of this thread goes into all the funny
semantics of assigning, copying, and garbage collection behavior,
while overlooking the simplest fact of all:  the hassles come about
because you're dealing with a strongly typed language!  (Ada's limited
private types only make the contract cleaner to visualize, they don't
overcome the associated problems.  And don't get me started on the
supposed advantages of strong vs. weak/dynamic typing.)

GCed languages usually eliminate the problem of "assignment" because
there is no such feature:  they do dynamic typing/dynamic binding,
replacing references (virtual pointers) to objects rather than the
contents.  You have to write special methods to implement assignment,
and I have found only a handful of cases where that is desirable, let
alone necessary, and after years of thought I'm not certain about
those.  In such cases I've used "copy_from", where the argument is the
source whose state is copied into the receiver.  (Destructors for
releasing system resources are usually invoked manually or can be
through GC finalization mechanisms, which automate the necessary
cleanup even in cases that would otherwise be memory leaks.)

Now, all of the things said about "owned" versus "aliased" references
must be taken into account.  In my experience a dynamically typed
language will never have a slicing problem.  But ownership of
contained objects must still be managed.  Where the language doesn't
support assignment per se, then implicitly this means "owned" objects
must be copied (that is, cloned) in the usual way for the language
when assignment is implemented, which is what you'd expect.

Which leads to the discussion of copy semantics.  Either the language
or the type must define the semantics of what "copy" means.  It
certainly is easier when the language specifies a default
interpretation.  But there are valid reasons for having shared_copy
(which does NOT do ownership copies), shallow_copy (which copies or
clears contained objects not meant to be shared, such as a dictionary
cache), and deep_copy, which copies everything and its brother,
sister, cousin, and aunt.  Some data structures cannot wisely
implement deep copies without some smarts to prevent infinite
replication, such as duplicating graph structures.

I guess my point to all of this is that I will contend that the
problem is in the language and not the individual.  Yes, an
unfortunate number of our colleagues may not really understand the
complexities of languages they use.  (Let's leave personal indolence
and insolence out of it, shall we?)  Yes, management usually feels it
needs to exert its authority on issues for which it is not competent
to evaluate the options.  (Let's skip the ego thing, too.)  But *why*
do I need to propagate such insanities where there are better ways?

Stroustrop et al and his philosophy notwithstanding, with a background
in languages and a frequent, practical user of compiler technology, my
opinion professionally is that C++ as a language absolutely sucks.  It
is a pain to use simply because all of the issues noted in this thread
are counter-intuitive.  It doesn't matter in the least whether they
are useful to have.  There is simply no reason whatsoever that the
normal, introductory, or just plain naive programmer should ever feel
like disemboweling him/herself trying to get something to work when
the trouble is related to obscure language semantics.  (I'm sorry,
this is one of the reasons I dislike Ada:  coming up with the Posix
bindings was almost an exercise in futility because of all the
restrictions on packages and types.)  In that regard, Objective-C is
much cleaner as a strongly typed language, since it is a real albeit
hybrid OO language, where the OO-ness has been neatly layered onto the
original language.

And so that leads to objections about changes to the [base] language. 
I must disagree:  changes are inevitable.  We always find better ways
to do things, or eventually discover that the original way was not as
extensible (read that, "OO") as one would like, or even that some way
we depend on is flatly wrong, and so we "improve" it.  I've had to
port system implementations across 8 versions of a single language,
and it is never easy when you've made system (base code) extensions or
changes.  (One particularly nasty variant was a rewrite of the
graphics system!)  Having a language "protected" by a "standard" still
doesn't prevent gratuitous changes.  The best one can do is adapt
programming practices that help to minimize the effects of such
rudeness.  But don't whine about it, because the language we favor
most today may very well either be changed or obsolete tomorrow...

-- Tom