From: lwloen@rchland.vnet.ibm.com (Larry Loen)
Subject: Re: What is Object Oriented Programming? Is C doomed?
Date: Tue, 15 Dec 1992 20:19:54 GMT
Reply-To: lwloen@rchland.vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <id.Z2UV._XK@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> In article <1992Dec12.141331.23325@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> > In article <rmartin.724084666@ctbu> rmartin@ctbu.Rational.COM (Bob Martin) writes:
|> > >peter@ferranti.com (peter da silva) writes:
|> > >|Personally, I think object-oriented languages are a distraction from the real
|> > >|goal of good software component design.
|> 
|> > >I disagree.  Granted that some people are distracted!  Somem engineers
|> > >think they will write better programs just because they are using an
|> > >OO language.
|> 
|> Yes, that's my point. It's a distraction. It's not in the slightest bit harder
|> to write Fortran or Basic programs in C++ or Smalltalk than it is to write
|> them in C or Pascal.
|> 
|> > 	No, it is not. Many programmers *will* write better code
|> > when constrained by, say, strong typing in C++, or mandatory
|> > class orientation as in Eiffel.
|> 
|> I think you're looking at a marginal effect. I've never seen any indication
|> that any programmer who needs to use these tools as crutches is going to be
|> able to do a competant job of software design in the first place.
|> 

Not true in my experience.  There are two distinct phases in my neck of the 
woods -- high level design and low level design.  They are distinct phases with
distinct tools and people have varying degrees of talent for both.

I agree with you that someone who cannot do high level design will not use OO
effectively or well, there.  And, the results will not be impressive whatever the
programming technology.  Poor data structures and inefficient algorithms selected
here will still make for bloated or slow running programs.  OO doesn't change
that.  Indeed, in the early projects, it'll probably make it worse until folks
understand the trade-offs better and they're back to their old selves.

But, I have seen talented designers mess up badly in the low level design and
implementation.  Having actually done an OO decomposition or two on some old
designs, I have concluded that a lot of the remaining "creak", even in code
that we proudly shipped, probably would not have been there if the same code 
was done with a good OO-based design rather than with structs.

In particular, you are underrating the positive discipline of constructors and
destructors.  Of having methods with fewer parameters, which always seems to
be an issue in bugs that escape my testing.  Or, maybe this just highlights 
problems in my own and my most recent collegue's coding style?  :-) .

I see a real plus from OO-based implementations, here, and even if that is
"all" that it does, it would be worth quite a bit.  There's 100,000 ways to
mess up a low level design and objects do help steer one away from some of them.
Enough to be worth it, in my view.

I am also impressed that the code I write in OO seems to do at least the
initial phases of debug/code review, etc. a little faster.  That ain't chicken
feed.

|> You still need someone good to design the system, whether or not they're doing
|> the coding, and object oriented languages can all too easily become a
|> distraction... not for the competant, but for their managers who refuse
|> to spent the money on design because "we're using OO languages".
|> 

I agree.  But, that's mostly a learning curve discussion, which is a one or
two project cost.  Once mastered, it can't be a distraction any more than any
other formerly new idea is.  How many projects are left in your career?  

And, if managers don't think OO means more design and not less, 
it is our job to tell them that.  Because, OO _is_ more design, in my 
experience with it.

|> Object oriented languages, structured languages, strong typing, all these
|> things are good. But they're neither necessary nor sufficient for good
|> design and implementation of a software system.
|> -- 

I am increasingly concluding that these are "necessary" but _not_ sufficient,
because of the high level/low level situation described above.  I see enough
leverage in OO to make it in the same class as structured is today; something
that is not _mathematically_ required, but in fact tends, on average, to produce
better code quicker.  And, so is fairly universally adopted, because 
"necessary" translates to business necessity.  Or, are you uninterested 
in having a competitive cost for what a programmer does?

|> %Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
|> /L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
|> 482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
|> 324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"

-- 
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer
Newsgroups: alt.amateur-comp,comp.lang.c,comp.lang.c++,comp.misc