Related articles |
---|
On Legacy Applications and Previous Work PAUL@TDR.COM (Paul Robinson) (1994-03-06) |
Re: On Legacy Applications and Previous Work donawa@bnr.ca (chris (c.d.) donawa) (1994-03-21) |
Re: On Legacy Applications and Previous Work bill@amber.csd.harris.com (1994-03-14) |
Re: On Legacy Applications and Previous Work baxter@austin.sar.slb.com (1994-03-16) |
Re: On Legacy Applications and Previous Work steve@cegelecproj.co.uk (1994-03-22) |
Re: On Legacy Applications and Previous Work bart@cs.uoregon.edu (1994-03-23) |
Re: On Legacy Applications and Previous Work pardo@cs.washington.edu (1994-03-24) |
Re: On Legacy Applications and Previous Work bill@amber.csd.harris.com (1994-03-25) |
Re: On Legacy Applications and Previous Work mboucher@silver.sdsmt.edu (1994-03-29) |
Re: On Legacy Applications and Previous Work bill@amber.csd.harris.com (1994-04-04) |
Newsgroups: | comp.compilers |
From: | bart@cs.uoregon.edu (Barton Christopher Massey) |
Keywords: | tools, design |
Organization: | University of Oregon Computer and Information Sciences Dept. |
References: | 94-03-034 94-03-058 |
Date: | Wed, 23 Mar 1994 08:14:02 GMT |
Bill Leonard <bill@travis.csd.harris.com> wrote:
[...]
> Reusing large pieces of code is better. But writing reusable software
> that does something complicated enough to justify reuse is hard, real hard
> -- and time-consuming. Suppose you go to your manager and say, "I can
> have it done in 3 months, or a year if you'll let me make it reusable."
> I'll give you one guess which way the manager is likely to vote.
No, what you want to be able to do is go to your manager and say "I can
have it done really well in 3 months, or we can buy Frobozzco's reusable
component and I can get it running in three weeks." Unfortunately, this
raises questions about programming languages and translators that we don't
quite know how to answer yet.
As a taste of what may be coming in this regard, consider the ML module
system: it is quite possible for a software vendor to write, for example,
a sparse matrix module with an interface abstract enough that ML client
programs can use it for sparse matrices of arbitrary objects (e.g.,
spreadsheet cells), without sacrificing type-safety or (too much)
efficiency. If more people were using ML, it is likely that such modules
would be readily available, and that management would raise eyebrows if a
programmer wanted to implement their own complicated module instead of
using a commercial one.
IMHO ML modules aren't the final answer, but something like this has IMHO
got to be *the* biggest priority for software engineering in the 90s.
Bart Massey
bart@cs.uoregon.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.