Path: utzoo!utgpu!water!watmath!clyde!rutgers!ukma!psuvm.bitnet!uh2 From: UH2@PSUVM.BITNET (Lee Sailer) Newsgroups: comp.software-eng Subject: Re: Is it Art or is it Engineering (Clarifications) Message-ID: <32637UH2@PSUVM> Date: 10 Feb 88 18:42:43 GMT References: <6879@agate.BERKELEY.EDU> <4618@teddy.UUCP> <635@cresswell.quintus.UUCP> <4620@teddy.UUCP> Organization: Penn Sate Erie--School of Business Lines: 46 In article <4620@teddy.UUCP>, svb@teddy.UUCP (Stephen V. Boyle) says: >So, how can software development become more like engineering? Beats me. At >this point all I have is vague uncertainties and "sort of - kind of" thoughts >about what could be done different. But I think the comparisons with more >"traditional" engineering disciplines can display some interesting parallels, >along with divergences, regarding engineering practice. I have always wondered why there are so few software "handbooks" to go along with all the engineering handbooks. There are lots and lots of little "standard" components in any big program, for example: o sort list in memory with good average time performance o sort external file with good worst case performance o find the first line in a file that satisfies P. o find all lines that satisfy P. o merge two lists. o merge k lists o maintain a priorty queue o parse a regular expression o match a contextr free pattern. etc etc etc. Sure, there are a lot of them, but there are a lot of IC's, too. There are good ways to do all these things, and they could be described in a general way in psuedo-code, or in specific languages, or whatever. They would have to be categorized in some way to make it easy to find the one you need when you need it. Knuth almost satisfies this description, except that it should be called the Handbook of Software Technique, and should be demystified (i.e. use a friendlier notation) so that most programmers could use it. Voila--engineering! 8-) lee