pase@ogcvax.UUCP (07/07/87)
In article <glacier.17113> jbn@glacier.UUCP (John B. Nagle) writes: > > The trouble with this idea is that we have no good way to express >algorithms "abstractly". [...] Well, I'm not sure just where the limits are, but polymorphic types can go a long way towards what you have been describing. It seems that a uniform notation for operators + the ability to define additional operators + polymorphically typed structures are about all you need. Several functional languages already provide an adequate basis for these features. One such language is called LML, or Lazy ML. Current language definitions tend to concentrate on the novel features rather than attempt to make LML a full-blown "production" language, and therefore may be missing some of your favorite features. However, my point is that we may well be closer to your objective than some of us realize. I apologize for the brevity of this article -- if I have been too vague, send me e-mail and I will be more specific. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@Oregon-Grad.csnet
johnson@uiucdcsp.UUCP (07/09/87)
Object-oriented programming languages like Smalltalk provide a great deal of software reuse. There seems to be several reasons for this. One is that the late bound procedure calls (i.e. message sending) provide polymorphism, so it is easier to write generic algorithms. Late binding encourages the use of abstract interfaces, since the interface to an object is the set of messages it accepts. Another reason is that class inheritance lets the programmer take some code that is almost right and convert it without destroying the original, i.e. it permits "programming by difference". These two features combine to encourage the creation of "application frameworks" or "application toolkits", which are sets of objects and, more importantly, interfaces that let the application developer quickly build an application by mixing and matching objects from existing classes. There are a number of ways that an abstract algorithm can be expressed in these languages. An abstract sort or summation algorithm can be built just using a polymorphic procedure. Abstract "process all" and reduction algorithms are provided by inheritance in the Collection class hierarchy of Smalltalk, and a toolkit can be used to describe the abstract design of a browser or editor from a set of abstract data types, a display manager, and a dialog control component (i.e. the Model/View/Controller system). The Smalltalk programming environment also provides tools to help the user find code and to figure out what it does. While these tools (and the language) could stand some improvement, they already provide a lot of what is needed for code reuse. And they don't use A.I!
sterritt@ge-mc3i.UUCP (Chris Sterritt) (07/18/87)
Hello, I've been following the discussion of this avidly, but am new to the programming languages (?) ML, SML, and LML. Could someone (ideally mail me directly so as not to clog the net!) send me information on these langauges, so that I might find out more? Along the ideas of the discussion, if I remember my Computability theory correctly -- doesn't it make some sense that to show an algorithm (either computable or to prove it) you need to give an almost algorithmic description, as in an inductive proof? So isn't this what Lisp is (I'm a lisp hacker at work). I'd think that Church's Lambda Calculus would shed some light on this discussion, as I believe that that was what he was trying to do with the calculus. Generally, I agree that to specify an algorithm IN ENOUGH DETAIL, you will probably wind up writing at least as much information down as the code itself. I think that 'Requirements' as we define them in 'Software Engineering' presume a *lot* of human intelligence. Any comments? Chris Sterritt