Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!haven!adm!cmcl2!lanl!opus!ted From: ted@nmsu.edu (Ted Dunning) Newsgroups: comp.sw.components Subject: Re: using components Message-ID: Date: 18 May 89 18:14:29 GMT References: <11401@bloom-beacon.MIT.EDU> <5490@hubcap.clemson.edu> Sender: news@nmsu.edu Organization: NMSU Computer Science Lines: 93 In-reply-to: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu's message of 15 May 89 21:13:45 GMT In article <5490@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes: Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu Lines: 108 From tada@athena.mit.edu (Michael Zehr): There have been a couple of good comments about using software components, but so far most of them have been along the lines of "such-and-such a language does this." Could you describe *how* the language provides both efficiency and quick building time? For example, one person mentioned Ada's "re-binding" of executables. What does this do? ... many good descriptions of separate compilation ... Another mechanism is the "package". One use of packages is to describe specifications (*compilable* specifications) for subsystems which collectively interact to form a larger system. Once the high-level specifications have been compiled together, the information flows across the subsystem interfaces have been verified for completeness and consistency. this `checking for completeness and consistency' is actually nothing more than a static type check. since in a large application, the constraints on the interface between packages is considerably more complex than just having the communication merely be of the correct type, this should not be characterized as a full verification. ... more good comments are modular development ... The package specification forms a contract between the implementor and the other project members; if everyone fulfulls their end of the deal, then the entire system is guaranteed to work as far as information flows are concerned. again, this checking is far from complete (as it must be at the current state of the art). satisfaction of the type constraints is a BIG step along the way toward making things work smoothly, but there are an enormous number of constraints in a real program that cannot reasonably be expressed as type constraints. some, such as the sum of the squares of the first two arguments is greater than the square of the third, could be effectively checked by assertions. other aspects of the interface cannot even theoretically be checked by a compiler (such as the values returned by a function will be returned with 10 ms. of a call). again, type checking is almost always a GOOD THING, but it is also almost always not enough to verify that the communication between parts of programs are correct. ... more good comments about the benefits of libraries and separate compilation ... Someone also mentioned being able to reuse components in different languages. I agree that this is crucial in combining efficiency with productivity. So far, my experience with mixed-language coding is that it is very easy on Vaxes (becuase of the forced procedure interface of the CALLS instruction) but extremely difficult on IBM mainframes (because there is no standard calling sequence). Does anyone have any experience in mixed-language coding on newer RISC machines? Do compiler witers stick to "standardized" calling mechanisms? ... good stuff about the ada party line ... ---------------------------------------------------------------- and now for the view from the rest of the world. type checking is a good thing. separate compilation is a good thing. libraries and linkers that understand type checking are a good thing. none of these are particular to ada. some or all of these can be found in ansii c, commercially available pascals, c++ and other languages. some of these solutions are partitioned differently from the way specified by ada orthodoxy, often with the result of more flexibility. this is the case with make. one place that most of these tools fall down at the current time is with program generators and preprocessors. the requirement that we specify interfaces completely in terms of base language leads to very serious awkwardness if when we try to replace the functionality of yacc or make heavy use of precompilation as do the internals of the gnu c compiler. the failure of tools in the face of language extension is an issue that has been long recognized in lisp circles. only recently are conventional languages being used (and shown insufficient to the task) in such advanced applications. a serious case in point is the x toolkit as implemented in c.