home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / function / 925 < prev    next >
Encoding:
Internet Message Format  |  1992-07-20  |  1.9 KB
  1. Path: sparky!uunet!mcsun!uknet!warwick!nott-cs!ucl-cs!news
  2. From: S.Courtenage@cs.ucl.ac.uk (Si Courtenage)
  3. Newsgroups: comp.lang.functional
  4. Subject: Re: Maturing implementations of functional languages (and religion)
  5. Message-ID: <2789@ucl-cs.uucp>
  6. Date: 21 Jul 92 09:20:39 GMT
  7. Sender: news@cs.ucl.ac.uk
  8. Lines: 36
  9.  
  10.  
  11.  Stuart Clayman writes:
  12.  >Another thing that should be considered is the cost of actually
  13.  >writing algorithms and maintaining them.
  14.  >These are the most money intensive aspects of commercial software.
  15.  >
  16.  >My feeling is that if my lazy, functional and modular program goes 10%
  17.  >slower than the C version, then in itself that seems poor.
  18.  >However if I consider the no. of lines of code, how long it took me to
  19.  >write it correctly, and moreover how long it may take me to debug it
  20.  >in future (in case of errors) then the overall view has to be (my
  21.  >belief here) that the functional version is not too bad, and may even
  22.  >be competitive.
  23.  >Rule n: Consider all the costs over the whole development cycle.
  24.  >
  25.  
  26. Making the following assumptions, that
  27.  
  28.    1. execution cost of functional languages is fixed for each program run
  29.    2. the cost advantage of functional languages, such as ease of program
  30.       maintenance and clarity of expression etc. per unit time decrease
  31.       over the program life-cycle,
  32.  
  33. then if the program was a high-use, long-use program then it would be better
  34. to write the application in an imperative language as the execution cost
  35. disadvantage would outweigh the dvelopment cost advantage. If the program
  36. was a short-use or low-use program then it would be better to write it in a
  37. functional language since the development cost advantage of functional
  38. languages would, on average(?), overcome the execution cost disadvantage.
  39. Hence why functional languages make good tools for prototyping but not for
  40. end-products.
  41.  
  42. Has there been any research in software engineering/fp into this kind of
  43. tradeoff?
  44.  
  45. Simon
  46.