Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!VAX1.CC.UAKRON.EDU!mcs.kent.edu!usenet.ins.cwru.edu!abvax!iccgcc!klimas
From: klimas@iccgcc.decnet.ab.com
Newsgroups: comp.object
Subject: Re: A Rewrite Is *NOT* An Experiment
Message-ID: <4266.2809adf8@iccgcc.decnet.ab.com>
Date: 15 Apr 91 18:43:20 GMT
References: <44.UUL1.3#913@acw.UUCP>
Lines: 46

In article <44.UUL1.3#913@acw.UUCP>, guthery@acw.UUCP (Scott Guthery) writes:
> "We rewrote the X system in Y and it was k times faster.  (Therefore Y
> is not only not less efficient than X and might even be more efficient!)"
> 
> Can somebody tell me why statements of this genre from the OO crowd
> (or any other crowd with an axe to grind, for that matter) go
> unchallenged?  Does hype like hope spring eternal?
> 
> Com'on, folks.  The fact that the rewrite ran faster says nothing at
> all about the relative merits or efficiencies of X and Y.  The
> efficiency of the rewrite is due at least to 1) the use of Y *AND* 2)
> the fact that it was a rewrite.  For all we know, the rewrite might
> have been 2k faster if X had been used.  In fact, in any rewrite
> situation, I'd bet that 83.7% of the efficiency gains are due to
> simply rethinking the implementation in light of now-known usage and
> load patterns.
> 
> The experiment of interest, of course, is to independently rewrite
> the system in X and then compare the new X implementation with the Y
> implementation.
> 
> The fact that OO advocates not only let statements such as this pass
> unchallenged but actually reference them in discussion tells us much more
> about the advocates than it does about the technology.
> 
> 							Cheers, Scott
	Real world production experience does not necessarily
	corroborate Mr. Guthrey's claims.

	Although one has the benefit of previous work in defining 
	the required functionality when doing a rewrite, there are some
	benefits to using the right tool for the right job.  I have seen
	some remarkable increases in productivity when rewriting some
	buggy C based drivers in an OO language.  The rewrite was done from
	a well defined specification (the same one that the original C
	code was based upon) and the developer managed to create a new driver 
	in a very short time that previously had taken several man-months 
	with straight C.  The main influencing factor seemed to be 
	the large existing library (i.e. code reuse) that the 
	developer was able to take advantage of.  As an aside, the code was 
	also more reliable, compact and, inspite of the myth that OOP is slow,
	the new driver was just as fast as the old one!

	OOP is beneficial for a number of software engineering problems,
	however one has to be a little prudent in making sure that the fit is
	appropriate.