Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewse!emuroga
From: emuroga@cbnewse.att.com (eisuke.muroga)
Newsgroups: comp.sys.mac.programmer
Subject: Re: OOP--What do you think?
Message-ID: <1991Apr17.231641.7125@cbnewse.att.com>
Date: 17 Apr 91 23:16:41 GMT
References: <1991Apr10.210516.25812@rice.edu> <712@gate.oxy.edu> <14@fss.UUCP>
Organization: AT&T Bell Laboratories
Lines: 52

In article <14@fss.UUCP> brugge@fss.Ems.MN.ORG (John Brugge) writes:
>In article <712@gate.oxy.edu> schorsch@oxy.edu writes:
>>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.
>>>
>>>What do you think?
>>>
>
>For the solitary programmer working alone on a (relatively) small program
>for a specific machine where running lean and mean is the highest design
>priority, the benefits of OOP may be obscured.
>
>BUT, if you're developing a more complex system, with a number of programmers
>involved, and the system may still be living and growing when you're no longer
>around, then the paradigm (what a great word) of object-oriented development
>has some more tangible rewards: support for encapsulation and data abstraction,
>class libraries (e.g. TCL and MacApp on the Mac) that give you a head start
>and a foundation on which to build, and possibly even platform indepedence
>(e.g. Objectworks/Smalltalk that runs unaltered on Macs, Windows & X systems).
>
>In the current world, this doesn't come free, however; there's some overhead,
>in terms of code size and speed, but I'd like to think that that is less
>important (to a degree; nobody wants a dog program, but I often find that I'm
>the limiting speed factor in using a program, not the program). And personally,
>I'd just as soon be as far away from the machine as I can when programming -
>I'm awaiting the day when I can write a significant Mac program without having  
>to know anything about A7, or whether my handles are locked or unlocked, etc.
>
>With the variety of applications being found for computers today and tomorrow,
>the premium will be on analysis, design and adaptability - ideas which an OO
>mindset encourages (although doesn't enforce). There's nothing magic about OOP,
>just another way of looking at the world that can give better insights and
>payoffs in certain situations.
>
>John Brugge
>
> 

In addition, I believe oop requires better design at the outset. It's hard
(and can really kill you) to start writing code on the fly. A bad design
can be more difficult to maintain than procedural code, so oop doesn't
necessarily mean the code will be easier to maintain.

Eisuke Muroga