Doug Ransom <[EMAIL PROTECTED]> writes:
> none will miss spending a couple of weeks at the end of the
> development cycle trying to find a memory leak.

Apart from the fact that they are called space leaks, a lazy
functional language will not help them with this problem. It may
rather aggravate it by hiding the leaks in very wierd places. Show me
any working programmer who reads the "Improving laziness"-part in the
Hutton/Meijer paper on monadic parser combinators and says "Oh! What
an elegant language! And these nifty efficiency improving no-ops like
(fst (head x), snd (head x)): tail x !" (By the way, can anyone
explain this section to me?)

To cite the comments of Olof Torgersson on Haskell
(www.cs.chalmers.se/pub/users/oloft/Papers/wm96/wm96.html):

   As a consequence the programmer loses control of what is really
   going on and may need special tools like heap-profilers to find out
   why a program consumes memory in an unexpected way. To fix the
   behavior of programs the programmer may be forced to rewrite the
   declarative description of the problem in some way better suited to
   the particular underlying implementation. Thus, an important
   feature of declarative programming may be lost -- the programmer
   does not only have to be concerned with how a program is executed
   but has to understand a model that is difficult to understand and
   very different from the intuitive understanding of the program.

As another example, compare the propaganda version of quicksort in
Haskell with a more realistic tail recursive one.

If you want to increase the popularity of functional languages, remove
the possibility of unintended space leaks and the necessity to
make algorithms tail recursive manually (or solve the traveling
saleperson problem in O(n)). Then you will only have to overcome the
problem that most people are already hard pressed to understand
functions as mappings from real numbers to real numbers, let alone as
mappings from one function space to another.

Yours, Florian.

Reply via email to