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.
