UH2@psuvm.psu.edu (Lee Sailer) (02/03/90)
In a previous post on this thread, Dan Weinreb describes the typical empirical research design for testing the benefits of OOP, create matched groups of programmers and give them projects of significant size. As he points out, it is very expensive to do this type of study. Nonetheless, such studies have been done on other similar topics, usually using volunteers donated by local industry. So for example if every company in Silicon Valley would donate one programmer for a week (not too burdensome per company, I think) then some researchers could create a project, collect the data, subject it to the usual statistical hocus pocus, and get tenure. On the other hand, since this isn't going to happen anytime soon, what are the alternatives. One is to use cheaper programmers (students, usually) and smaller projects. Another is to wait and let the market do the experiment. OOEs (Object oriented enterprises) might blow the rest away. Third, is to admit that the empirical approach is beyond our reach, and thus rely on the perhaps inferior but best remaining technique, rationalism. Weinreb says that he can tell OOP feels really powerful to him. I have the same feelings. So do lots of folks. A few, but not many, people who have learned OOP and used it to write programs don't feel the same way. This is empirical evidence of an indirect nature, but empirical evidence nonetheless. In short, the only evidence for or against OOP that most of us can afford is the opinions of the best minds we can find. Isn't this (gasp) Pournelle's Rule---find a person you think you can trust, and then do what he or she tells you?
horstman@sjsumcs.sjsu.edu (Cay Horstmann) (02/04/90)
What is the alternative to OOP? Deliberately NOT using OO techniques? Oops, that struct over there looks too much like an object. Better rewrite that code... OO is a technique, not a religion. It is one tool in the toolkit of the enlightened programmer who is going to use it when it is appropriate. To come up with a dumb analogy, it is like recursion. Sometimes it works great, sometimes not. Have you seen people run seminars on the weighty question whether the benefits of recursion can be measured? Ok, now suppose we do "measure" the benefits. We teach one group of programmers about OOP, when it is useful and when not. And then we have them and a control group work on a problem. How can we insure against the fact that the people who didn't flunk out of the OOP course are probably smarter/more alert than the control group? At any rate those people will have had some extra mental stimulation just before they started the project. What kind of project will be selected? It would be interesting to select one where OO techniques could have no earthly significance, but who is going to do that? No, they'll pick some project where OO will probably make some difference. And, SURPRISE, the OO group will be the better one. That is the kind of stuff I could get tenure for. Cay
gillies@p.cs.uiuc.edu (02/07/90)
Here's the only reference about code size I know of. Eric Harslem and Leroy E. Nelson, "A Retrospective on the Development of Star". Proceedings of the 6th international conference on software engineering, 1982 September, tokyo japan. Also available in "Office System Technology -- A look into the World of the Xerox 8000 Series Products: Workstations, Services, Ethernet, and Software Development", pp 261-267. [Available from Xerox Corp, 3333 Coyote Road, Palo Alto CA] Since this paper is hard to get, here are the two main quotes. ...About one fifth of Star was working by the time it was determined that a subclassing mechanism would be needed to complete the system. Such a mechanism was subsequently designed and implemented [Curry82]. The existing Star code was converted to use this new mechanism in several places. ...The barchart below shows the size of the operational corpus of Star code over the period of its development. A plot of functionality would have roughtly the same (y=x/2 - ed) shape. Star actually shrank during the conversion to the subclassing mechanism. Quarter Code size 1 25k 2 46k 3 55k 4 70k 5 70k 6 60k <- shrink 7 70k 8 75k 9 80k 10 100k 11 125k 12 140k 13 150k 14 175k 15 185k 16 200k 17 240k 18 250k These people were using a Pascal-like language, and coding conventions to implement subclassing. The multiple-inheritance subclassing mechanism was called "Traits" and is documented in Gael A. Curry, Robert M. Ayers, "Experience with Traits in the Xerox Star Workstation", IEEE Trans. on SOft. Engineering, Vol SE-10, Sept 84, pp 519-527. Here is the most interesting quote from that article. "In 1982 an analysis of the OS3 Star traits graph was performed in order to see how multiple subclassing was being used. In the traits graph which was examined, there were 168 separate traits (including all of the structure discussed in Section III). Although, as noted earlier, many of the classes used multiple subclassing, very few used multiple subclassing in an intrinsic or unavoidable way; minor rearrangements of the traits graph, not costly either in program logic or in class data space, could eliminate the multiple inherence [yielding single inheritance - don]. The notable exception was the trait structure used to define tables (see Figs 13 and 14). The tables implementation used multiple-subclassing extensively. An examination showed that it was intrinsic subclassing that could only be eliminated by a basic redesign. Interestingly, the tables facility was developed late in the Star project, and its designer was very familiar with the traits mechanism. This analysis suggested two things. First, despite the historical evolution of the system, which has embraced multiple-component subclassing, it would be possible to do an after-the-fact restructuring and "retrat" to single-component subclassing. Second, it was possible that the design benefits of traits were lost because the designers, not having worked with them in the past, structured their implementations along better-understood single-component lines."
jimad@microsoft.UUCP (JAMES ADCOCK) (02/10/90)
In article <1990Jan31.053709.5741@odi.com> dlw@odi.com writes: >In article <25C3AC55.8379@paris.ics.uci.edu> crane@paris.ics.uci.edu (Steven N. Crane) writes: > > Everyone's heard of the alleged benefits of object-oriented > programming (improvements in reusability, productivity, buglessness, > maintainability, etc.). > > I believe it myself. (I can just feel the power when I use C++ :-). > But does anyone have any references to actual *empirical* quantitative > studies which have actually *measured* the extent of these benefits? > Studies with real *numbers* in them. Well, here's a simple, not-very-profound numerical study I did *just* this afternoon: number of articles in computer journals referencing the "object oriented" buzz-phrase. Each number represents number of articles during the previous year. Total number of articles in each time period was fairly constantly about 60,000. Oct 88 415 Jan 89 516 Mar 89 622 Jun 89 806 Sep 89 1057 Jan 90 1289 Interpretation is left to the reader. I don't know about you, but I feel like I'm falling a *little* behind in my "object oriented" readings. Of course my cat *is* object oriented. And I don't even *have* a cat.