From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!crowl From: crowl@rochester.arpa (Lawrence Crowl) Newsgroups: comp.lang.ada,comp.lang.misc Subject: Re: Software Reuse -- do we really know what it is ? Message-ID: <378@sol.ARPA> Date: Mon, 22-Jun-87 14:59:41 EDT Article-I.D.: sol.378 Posted: Mon Jun 22 14:59:41 1987 Date-Received: Tue, 23-Jun-87 04:44:07 EDT References: <8706160502.AA26398@ucbvax.Berkeley.EDU> <371@dcl-csvax.comp.lancs.ac.uk> <374@sol.ARPA> <4658@utah-cs.UUCP> Reply-To: crowl@rochester.UUCP (Lawrence Crowl) Distribution: world Organization: U of Rochester, CS Dept, Rochester, NY Xref: mnetor comp.lang.ada:405 comp.lang.misc:461 List-Id: In article <4658@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes: ]... software people fume and gnash their teeth over "wasted space". ... All ]the techniques for modules, objects, etc, tend to slow things down. Again, ]software types tear their hair out and vow to recode everything into one ]assembly language procedure. Worse, other software types admire them for ]doing so! ... ] ]In article <374@sol.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: >>In article <371@dcl-csvax.comp.lancs.ac.uk> >>craig@comp.lancs.ac.uk (Craig Wylie) writes: )))3. Languages such as Ada and Modula-2, and imperative languages in ))) general are unsuitable for writing reusable software because of ))) their concentration on the HOW rather than the WHAT. >> >>Clearly, we need more concentration on WHAT, but we should not abandon the ] ^^^^^^^^^^^^^^^^^^^^^^^^^ >>efficiency of HOW. ] ^^^^^^^^^^ ] ]QED! Let me clarify my position. I can specify a sort as a set of predicates and let the system figure out how to satisfy those predicates. This is the WHAT approach used in languages such as Prolog. Another approach is to write a algorithm for sorting, e.g. quicksort. This is the HOW approach used in languages such as Ada. Yes, the packaging of the sort will result in some loss of efficiency. However, it will be substantially faster than the WHAT approach. I am advocating an approach in which a package interface describes WHAT and the implementation of the package describes HOW. Because I wish to keep the macro-efficiency of algorithmic languages, do not accuse me of wishing to keep the micro-efficiency of hand-tuned assembler. ]3. In general, hardware types have standards for every imaginable sort of ]interface, and they stick to them remarkably well. You can plug boards into ]a standard bus with only a small chance of sparks flying everywhere as the ]boards fry. In software, standards are strictly for lip service to managers; ]only a novice would consider combining programs from several different ]sources without planning a few hours or days of debugging! Programmers to this sort of program combination many times a day in the Unix shell. There ARE approaches to software reuse that CAN work. We need to provide this kind of capability within a language. ]In short, I believe there are no technical problems or issues with reuse; ]it's the software culture that has to change. At present, the prevailing ]attitude is that the densely-coded, highly-optimized, do-everything program ]is a sort of ideal to which everyone aspires. Until this attitude changes, ]software reusability will continue to be a bad joke among those who actually ]write programs. There are technical problems. For instance, how do you insure that the parameters to a generic package are appropriate. Performance will always be a goal. However, it must be balanced against cost. Most programming done today is in a high-level language. In the early sixties, most programming was done in assembler. So, the software attitude has changed. Modular code also allows changes in representation that can lead to orders of magnitude performance improvements. Non-modular code strongly inhibits such representational changes. In short, the micro-efficiency of non-modular code leads to the macro-INefficiency of poor algorithms and representations. )))5. Nobody can force programmers to write good reusable code. >> >>True. But no one need buy code that is not both good and reusable. I >>believe there is a market for such code. ] ]Manufacturers seem to think their interest is in maintaining secrecy of code. Again, let me clarify. I meant that the reusable software would be written by software houses and sold to companies which write applications. For instance, Reusable Software Inc. sells a sort package to Farm Software Inc. which uses it in its combine scheduling program. Farm Software Inc. need not divulge its algorithms or its use of packages written by Reusable Software Inc. ]Customers only care about speed and features. Read Infoworld and see if they ]ever say anything positive about a program that is slower but more modular. You forgot cost. Modular code will cost substantially less in the long run. -- Lawrence Crowl 716-275-5766 University of Rochester crowl@rochester.arpa Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627