Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object
Subject: Re: C++ vs. C
Message-ID: <1991Apr28.042949.1327@odi.com>
Date: 28 Apr 91 04:29:49 GMT
References: <1991Apr24.125926.5146@asc.slb.com> <18905@crdgw1.crd.ge.com>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 61
In-Reply-To: kornfein@azores.crd.ge.com's message of 25 Apr 91 12:56:59 GMT

In article <18905@crdgw1.crd.ge.com> kornfein@azores.crd.ge.com (Mark M. Kornfein) writes:

   This example shows both the power of object oriented programming and a 
   drawback of it. The C example is somewhat easier to debug and test than 
   the C++ example from my experience. This is especially true if I did not
   write the code originally.

   From looking at the C++ I have no clear idea what method will be called without
   looking further

I could use the same argument to explain why subroutines are not a
good idea in programming languages.  You should never use subroutines,
procedures, or functions.  You should always just write out all of the
code, in line.  After all, if I'm reading a program and find a call to
a subroutine called "foo", I have no idea what it does.  I'd have to
search all over to try to find "foo", and heaven knows where it might
be.  Subroutines just make programs incomprehensible.  As you say
yourself, "It is true that a good browser can help with this problem
but in the real world one does not always have that".

When I first started to use computers, there were always CREF
(cross-reference) programs, that would print out lists of where each
subroutine was defined and where it was referenced.  They also existed
for assemblers, this time applying to defined symbols rather then
subroutines, of course.  I found these cross-references utterly
indispensible when I wanted to read real (large) programs.  Nowadays
the job gets done on-line by my programming environment (e.g. "tags"
and the Gnu Emacs meta-. command).  The introduction of subroutines
effectively mandated these improvements in programming technology, and
they always existed in any real programming situation I found myself
in.

Object-oriented programming, with its new kind of subroutines
(generic, or virtual, or message passing, or whatever), similarly
demand cross-referencing tools.  The best ones I've ever seen are in
the Symbolics Genera environment, for Flavors/CLOS.  I program in C++
these days, and do not have tools as good as that, and wish I did.  In
general, I think the C++ world has not yet caught up with the need for
good program development environment tools, particularly in the area
of cross-referencers.  There are a lot of good starts that might turn
into something great one day, but it's not really here yet.  This is
one of the ways in which C++ is really still in its early days.

Indeed, some people might not want to get involved with C++ yet; they
might want to wait until the environments are better developed, until
parameterized types are available in all the leading compilers, until
more off-the-shelf libraries exist, and so on.  That's proper for some
people and companies and groups.  Those of us who are using C++ now
are to some degree pioneers, and we have to pay something in exchange
for using C++ earlier in its history.

And for people who want to use an OO language now and are picking
among the alternatives, one of the many considerations to take into
account is that some environments have better-developed tools than
others.  I know that the Symbolics Flavors/CLOS one is very well
developed.  I understand that the ParcPlace-based Smalltalk-80 one is,
too.  Probably many others are; I'm not familiar with most.

The point is that when you evaluate the "power of object oriented
programming", you really can't omit consideration of the programming
environment.