🚀 go-pugleaf

 Stuart Clayman writes:
 >Another thing that should be considered is the cost of actually
 >writing algorithms and maintaining them.
 >These are the most money intensive aspects of commercial software.
 >
 >My feeling is that if my lazy, functional and modular program goes 10%
 >slower than the C version, then in itself that seems poor.
 >However if I consider the no. of lines of code, how long it took me to
 >write it correctly, and moreover how long it may take me to debug it
 >in future (in case of errors) then the overall view has to be (my
 >belief here) that the functional version is not too bad, and may even
 >be competitive.
 >Rule n: Consider all the costs over the whole development cycle.
 >

Making the following assumptions, that

   1. execution cost of functional languages is fixed for each program run
   2. the cost advantage of functional languages, such as ease of program
      maintenance and clarity of expression etc. per unit time decrease
      over the program life-cycle,

then if the program was a high-use, long-use program then it would be better
to write the application in an imperative language as the execution cost
disadvantage would outweigh the dvelopment cost advantage. If the program
was a short-use or low-use program then it would be better to write it in a
functional language since the development cost advantage of functional
languages would, on average(?), overcome the execution cost disadvantage.
Hence why functional languages make good tools for prototyping but not for
end-products.

Has there been any research in software engineering/fp into this kind of
tradeoff?

Simon