Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!bloom-beacon!bloom-picayune.mit.edu!athena.mit.edu!captkidd
From: captkidd@athena.mit.edu (Ivan Cavero Belaunde)
Newsgroups: comp.sys.mac.programmer
Subject: Re: OOP--What do you think?
Message-ID: <1991Apr12.183012.6855@athena.mit.edu>
Date: 12 Apr 91 18:30:12 GMT
References: <1991Apr10.210516.25812@rice.edu>
Sender: news@athena.mit.edu (News system)
Distribution: usa
Organization: Massachusetts Institute of Technology
Lines: 97

In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard Koopmans) writes:
>What I want to know is, is OOP the wave of the future in
>programming or just a passing fad?  Is it worth learning
>a new way of programming just to use the TCL?
>Maybe I'm just old fashioned, but I like the straight procedural
>way.  In all the message passing and things, I feel that the
>programmer gets too far away from the machine and works on a
>too abstract level.

Disclaimer: I'm heavily biased here, since I *do* believe that OOP is
indeed the wave of the future, and I'll try to outline why.

In one respect, OOP is familiarizing oneself with the class libraries
supplied in order to take advantage of them. In this respect it is not
too different from having to learn how the Toolbox works in order to
program the Mac: there's all this code that's been written for you, and
you need to learn the interfaces in order to be able to use it. Thus it
is not very different from using non-OOP procedure libraries, such as a
prewritten application shell.

OOP, however, allows you to make use of these libraries in a much more
transparent manner through the object and message-passing concepts. With
said app shell, tou have to go in, modify the code, and recompile. With OOP
you just pass messages to the various components of the app shell without
having to recompile, say, your window object (I know I'm not explaining
it very clearly, maybe someone can expound on this a bit more).

And this leads to another big win with OOP. The functionality inherent in
object oriented programming makes it a natural for *reusable* code, when
properly written. App-specific procedural code generally needs to be modified,
sometimes significantly, in order to be reused in a different application.
This is because procedural code does not necessarily lead to thinking in
a modular and abstract manner, where the caller does not need to (nor should
it) know the internals of how a specific routine is doing its work
(it's the same concept as the INTERFACE/IMPLEMENTATION dichotomy in pascal
units, for example). In programming in an object-oriented language and in an
object-oriented manner (you can still write procedural C in C++, for example.
I'm saying these advantages happen when you take advantage of the object
features in the language), the designing and building of objects carries with
it implicitly the creation of a well-defined calling interface for this code,
and it tends to isolate the outer routines from the nitty gritty of what the
objects do and rely on the abstract ideas of what the object is supposed to
do.  Reusable code in this manner is a BIG win, because although it's a fairly
significant effort at the beginning, it will shorted development time in
future projects (possibly by a lot). 

Another reason for OOP being extremely useful comes from the following idea:
OOP buys you ease and speed of programmind and development generally at the
expense of program size and speed. Although that seems to be a drawback (and
it can be in some situations), I submit that it is a big advantage: computers
are getting more and more powerful and cheaper and cheaper all the time. The
point is that MIPS will continue to get more and more plentiful, and
*something* has to be done with them. There comes a point where, except for
seriously mega-apps that crunch huge amounts of data, the additional MIPS
are not going to do squat for you. Except for the fact that OOP coupled with
the extra power can give you a huge benefit: much shorter development times
for newer software and software updates, and consequently being able to
find new uses and do more things with your machine in a lot less time (from
the perspective of the user). BTW, the same thing can be said for storage.
In this sense, OOP is the wave of the future because as MIPS get cheaper and
cheaper it will make more and more sense to develop in objective languages
and be willing to take the performance hit (which I don't think it's that
big, but on the other hand I wouldn't want to program a low-level driver
using TCL ;-), and since OOP leads to reusable code and has a fairly steep
learning curve, using OOP now starts one's library of 'reusable objects'
which will become more and more useful in the future and also permits one
to climb the learning curve now and be fully up to speed when it is useful
rather than starting to learn it when it's useful and be *seriously* behind.

One last point: I don't believe that for application-software (stuff that's
supposed to interact with the user and perform a useful task as opposedf to
internal code like a low-level driver) you can really get "too abstract,"
and "too far away from the machine." Proper abstraction, defining the
problem to be solved in abstract subproblems and the data manipulated in
an abstract manner without regards to the internal representation of the
data is IMHO a good thing (you people out there who have programmed in CLU
know what I mean - Is there anybody out here that has programmed in CLU
, BTW?). It tends to make for more reliable and easier-to-test 
software, and additionally can add a level of machine independence to the
software in question (by reimplementing the low-level abstractions, the
program could be easily ported, for example). It makes for code that is much
cleaner and much easier to read and understand, in general, which is a big
plus since we all know that if you go away for a month from a nontrivial
piece of code that is not properly commented you'll be up the proverbial
creek without the proverbial paddle when trying to come back to it, and
debug or understand it. I however do not mean that highly optimized machine
specific code (especially assembly) is bad, but that it has its place, and
there are tradeoffs involved, and that the balance tilts over time to the
easily written, easily reused, easily debugged and easily tested object-
oriented code for most tasks, IMNSHO.

Flames ignored, scholarly debate and discussion requested and appreciated.

-Ivan Cavero Belaunde
Visualist
Digital Video Applications Corp. (DiVA)
Internet: captkidd@ATHENA.MIT.EDU