On 06-Dec-2003, Sven Panne
Henk-Jan.van.Tuyl wrote:
[...] it looks to me, that the problem of space leaks is a very good reason to not use Haskell for commercial applications. Java, for example, does not have this problem.
I just can't resist when I read PR statements like this (SUN's marketing department has *really* done a good job):
Yes, it is just plain wrong to say that Java never has space leaks.
Granted, Haskell has problems with space leaks from time to time, and it is especially easy for beginners to stumble over them,
The problem with Haskell is not so much that beginners sometimes stuble on space leaks -- the problem is that even seasoned experts have great difficulty analyzing the space usage of very simple Haskell programs.
But for large realistic programs most programming languages converge and you basically have the choice of what kind of space leak you want:
If you are suggesting that space leaks are equally frequent and equally easy to diagnose and avoid in these different languages, then I would disagree.
* C: Missing calls to free(), etc.
For C, leaks are common because it is easy to forget to insert calls to free(), and avoiding or fixing them can be difficult because figuring out when it is safe to call free() requires a non-local analysis to figure out when data is no longer used.
* C++: All of C's leaks + lots of hard to find space leaks due to incorrectly handled exceptions + ...
C does suffer from many of the same problems as C. But in C++, it is much easier to automate techniques like reference counting, which can be done manually in C but are much more cumbersome and error-prone when done manually.
* Haskell: Functions which are not strict enough, thunks which are never evaluated but hold large data structures, etc.
Yes. The difficulty with Haskell is that everything is lazy by default. There is no explicit syntax required to define a lazy function, so if you want to figure out which functions are too lazy, you may need to examine *every* function. There is often no explicit syntax for creating a thunk, so again it is difficult to spot which parts of the program are doing this.
* Java: Listeners which are not de-registered, containers which are not "nulled" after removal of an element,
In general Java can suffer from space leaks if variables which will not be used are not "nulled" out. However, avoiding and/or fixing such problems is a lot easier in Java than in C, since determining whether a variable can safely be nulled out only requires analysing uses of that variable, rather than analysing uses of the object to which that variable points. This is a _much_ easier kind of analysis. IMHO it is probably also much easier than trying to analyze space usage of Haskell programs.
badly written cache-like data structures, etc.
Those can be a problem in any language.
--
Fergus Henderson