guthery@acw.UUCP (Scott Guthery) (04/11/91)
"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
+*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+
NET Domain: guthery@uunet.uu.net Post: 11100 Leafwood Lane
COM Domain: guthery@acw.com Austin, Texas 78750-3464 USA
US Domain: guthery@acw.austin.tx.us FAX: +1 (512) 258-1342
Usenet: {uunet}!acw!guthery Voice: +1 (512) 258-0785
CompuServe: 70240,221 Fidonet: 1:382/12
Packet: N5MDE @ KB5PM Prodigy: BCDG83A
+*+*+*+*+*+*+*+*+*+*+*+*+* The Source of C +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+richieb@bony1.bony.com (Richard Bielak) (04/11/91)
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. > I agree with you on this point. However, I find that there is too much emphasis on efficiency and not enough on reliability and correctness. We are starting a project in which we will re-build a large system and we will program it in Eiffel. We chose Eiffel mostly because we expect that our code will be more reliable (partly due to "object-orientedness" but mostly because of Eiffels pre- and post conditions). In our case, it is more cost effective to buy faster machines, then to suffer software failures in production systems. ...richie -- *-----------------------------------------------------------------------------* | Richie Bielak (212)-815-3072 | Programs are like baby squirrels. Once | | Internet: richieb@bony.com | you pick one up and handle it, you can't | | Bang: uunet!bony1!richieb | put it back. The mother won't feed it. |
aew@eosvcr.wimsey.bc.ca (Alan Walford) (04/11/91)
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!)" I can only assume thar S.G. is referring to my post regarding the rewrite of my survey software. > > 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? Ha, who has the axe to grind. It certainly isn't me. I think we all know who does. > > 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. Yes, a very large part of the efficiency gain is due to the rewrite and rethinking of the problem. I did not and I do not dispute this. My point was this: You can write an efficient program in an object oriented language using object oriented concepts. People (customers) were happy with the speed of the old implementation and are stunned at the speed of the new one. Your statements that customers will not pay for the use of object oriented language is completely unfounded. What is the axe you have to grind anyway ? > > Cheers, Scott Cheers again, Alan Alan Walford Eos Systems Inc aew@eosvcr.wimsey.bc.ca
jls@rutabaga.Rational.COM (Jim Showalter) (04/12/91)
This is a good post, and raises an important point--a rewrite is NOT the proper way to judge the merits of one methodology over another. However, there HAVE been some efforts to write the SAME project in parallel, using a functional methodology on one and an object-oriented methodology on another. Companies typically do these so-called "shadow" projects (the main project and a parallel one that shadows it) to assess as scientifically as possible the real merits of newfangled stuff as opposed to the hype. In all such cases I'm aware of, the object-oriented shadow project came out on top. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *
marc@dumbcat.sf.ca.us (Marco S Hyman) (04/14/91)
In article <jls.671420246@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: > In all such cases I'm aware of, the object-oriented shadow project came > out on top. Jim, please elaborate. The only examples I've seen published have been more re-write than parallel development. Some references please. -- // marc // home: marc@dumbcat.sf.ca.us pacbell!dumbcat!marc // work: marc@ascend.com uunet!aria!marc
klimas@iccgcc.decnet.ab.com (04/16/91)
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.
klimas@iccgcc.decnet.ab.com (04/29/91)
In article <jls.671420246@rutabaga>, jls@rutabaga.Rational.COM (Jim Showalter) writes: > This is a good post, and raises an important point--a rewrite is NOT > the proper way to judge the merits of one methodology over another. > > However, there HAVE been some efforts to write the SAME project in > parallel, using a functional methodology on one and an object-oriented > methodology on another. Companies typically do these so-called "shadow" > projects (the main project and a parallel one that shadows it) to assess > as scientifically as possible the real merits of newfangled stuff as > opposed to the hype. > > In all such cases I'm aware of, the object-oriented shadow project came > out on top. > -- Some further corroboration. One can raise the argument that when rewritting a program in an OOP language from a non OOP language, it is easier because one is benefitting from the accumulated design knowledge in the existing code. This was an interesting argument that was difficult to disprove until I had a real life experience relayed to me by a software tool maker. To meet some tight deadlines for an upcomming trade show, they did a show demo in Smalltalk. Afterwards they had to reimplement the same program in Objective-C which was a little harder and took longer even though the developer's were well versed in the language. Finally, the same tool was rewritten for C++ which was much harder to do and took significantly longer. The tool developer has his greatest market with C++ users so he's reluctant to tell his customers they are not necessarily using the best technology. This experience seems to disprove some of the ideas that it is easier to redo software the second time around.
hansen@pegasus.att.com (Tony L. Hansen) (05/07/91)
< From: klimas@iccgcc.decnet.ab.com < One can raise the argument that when rewritting a program in an OOP < language from a non OOP language, it is easier because one is < benefitting from the accumulated design knowledge in the existing < code. < This was an interesting argument that was difficult to disprove until I < had a real life experience relayed to me by a software tool maker. To < meet some tight deadlines for an upcomming trade show, they did a show < demo in Smalltalk. Afterwards they had to reimplement the same program < in Objective-C which was a little harder and took longer even though < the developer's were well versed in the language. Finally, the same < tool was rewritten for C++ which was much harder to do and took < significantly longer. The tool developer has his greatest market with < C++ users so he's reluctant to tell his customers they are not < necessarily using the best technology. < This experience seems to disprove some of the ideas that it is easier < to redo software the second time around. I can't help but wonder how much of the problems doing the reimplementation were due to lacks in the language vs. a lack of an equivalent library and/or environment. For example, if the Smalltalk library provided a particular flavor of collection class which was crucial to the implementation, and a comparable collection class weren't already available in Objective-C and/or C++, such a collection class would probably have to be coded from scratch in order to continue with the port. Should that be considered a problem with the technology or a problem with the maturity of the technology? In other words, the technology may be sound but just not have sufficient support. We need more data. Tony Hansen hansen@pegasus.att.com, tony@attmail.com att!pegasus!hansen, attmail!tony