brucec@demiurge.WV.TEK.COM (Bruce Cohen;685-2439;61-028) (09/23/89)
As a change from the GC wars, let's talk about how you might want to use components in a kinder, gentler, software development environment. In article <11963@boulder.Colorado.EDU> scotth@boulder.Colorado.EDU (Scott Henninger) writes: > ... [GC dialectic omitted] ... > It will take thousands or >millions of components to make a truly useable software reuse >environment. There is no way that a human can keep track of what is >available at that kind of scale. > >The cognitive overload also comes in understanding what a component does >for you. Do you realize how hard it is to get novice programmers to >understand what a stack does? And this is one of the simplest >constructs in computer science. Just think of training someone to >understand 1000 ADTs (that are much more difficult to understand than >stacks) to the point that he can (re)use them. OK, so maybe we are at the point of talking about software as an engineering discipline rather than a branch of applied mathematics, or a form of handcraft. How does an electrical engineer deal with the thousands of IC and other types of components he must choose from? He consults a (set of) databooks(s). How does a mechanical engineer choose from among the standard components which his plant stocks or manufactures? He consults a computer database. What we need to develop now are ways to think about software components which can be translated into rules for specifying components both before construction and afterwards. This is the basic enabling technology for a marketplace in software components. A producer of a component can enter such a specification into a database; a consumer can create such a specification to retrieve a set of components which are candidates for use in his application. This will allow databases of components to be built up and access to the components can be given, bought, sold, traded, what-have-you. An executable description of a component could be provided for the consumer to use in simulations; if it worked well, the implementation could then be bought. I won't spend a lot of time predicting the way this could develop just now; let's see what others have to say. >I also must emphasize that the problems of reuse ARE LANGUAGE >INDEPENDENT. In fact there are many good reasons why software development should be language independent, at least insofar as design goes. I realize that this is a hopelessly idealistic attitude for the way things are done today :-), but it's worth working towards. Certainly the specification of a component can easily ignore the implementation-level detail of what language it will be implemented in. In fact, there's no reason why the specifier needs to know if will be implemented once in a given language, or many times, in many different languages. And there should be no reason for a consumer to consult the implementation of a component until specifications have led him to the right design. > Even with all of the religious followers of ADA out there, >you will never in a million years convince me that ADA is anything more >than trivially different from Pascal, C, Algol, etc. > And even if it were superior for many things, it a) isn't likely to be superior for all applications. b) won't remain superior in the face of new applications and evolving software technology (Fortran was JUST GREAT for it's time; Fortran 9x is an attempt to keep it that way; so does that mean we will all use it?) c) isn't going to be used by everyone just because it is superior (after all many technically inferior products dominate their markets; we rational types hate to admit that). So there will never be a single programming language for all (or probably even a majority) of all applications. We need to find solutions to our problems which do not depend on the most recent "best programming language." Bruce Cohen brucec@orca.wv.tek.com Interactive Technologies Division, Tektronix, Inc. M/S 61-028, P.O. Box 1000, Wilsonville, OR 97070
david@cs.washington.edu (David Callahan) (09/23/89)
Let us concede for the sake of argument that eventually there will be catalogs of software components and even an electronic/expert retrieval system and tools to quickly tailor general components to specific uses. How will this be commercialized? or will it? Hardware components are sold by the piece after the piece has been selected. Given the almost negligible cost of replication of software will this be a viable mechanism for software components? Large libraries are often funded by public or not-for-profit organizations so cost recovery is not a problem. Will the government step in and create a National Software Library? How will we set the prices for software components in this not-really-a-market situation? Would foreign companies/individuals have access to our National Software Library? Will large corporations develop proprietary libraries that are used to a competitive advantage over smaller companies? Are software components intellectual property? While you could clearly copyright a particular implementation of a an ADT, it seems unlikely (and I'll venture undesirable as public policy) to allow someone to patent an "abstract" data type. How will owners of for-profit software component catalogs protect their investment? -- David Callahan (david@tera.com, david@june.cs.washington.edu,david@rice.edu) Tera Computer Co. 400 North 34th Street Seattle WA, 98103