[Haskell-cafe] Why Haskell?

[Matthew Bromberg]

I am currently in the middle of a reasonably large software simulation 
of a wireless network that I'm programming
in Haskell and in C.   Progress has been slower than anticipated and I 
occasionally (probably because of looming deadlines)
 ask myself did I take the right approach?

Here are the reasons why I chose Haskell initially
1)  It's mathematical elegance, I thought would lend itself to the 
complex mathematical expressions I am implementing.
2) It rates reasonably high in performance comparisons with other languages
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all
3) It has a very active community who are courteous and quite helpful
4) It has an interactive shell.
5) It integrates easily with C.


The idea would be to implement hooks to some fast matrix libraries and 
some plotting routines in C and then develop the higher level logic in 
Haskell.
Since marshalling arrays and such, is a bit of a pain I structured my C 
matrix library in the form of stack based machine, using reference counting
to handle memory management and to minimize the amount of actual data I 
need to pass between C and Haskell.  This seems to work fairly well.
However I have been somewhat disabused of my original thought about how 
development would proceed.  I had hoped that I could get within a factor 
of two or so of the fast prototyping, development times of a good 
scripting language such as Matlab,  Python or Lua, but I don't think I'm 
achieving this unfortunately.

Here are some reasons why
1) Lack of debugging support.  Yes there are print statements and trace, 
but I would like to set a breakpoint.  It would be nice to do so and 
launch the GHCi interpreter with all the variable context supported.  A 
google search revealed that there is current work on this, but 
unfortunately the package is in cabal, which has spotty support in 
windows it seems.
2) Recompiling binaries (necessary in order to link in foreign object 
code into GHCi) is slow using GHC.  Moreover I have to restart GHCi if I 
want to reload a changed DLL (unless there is a way to unload a DLL in 
GHCi).  It also requires jumping around between several console windows 
to get the job done.  (I'm not using an IDE does one exist?)
3) Lack of automatic type coercion for closely related types.  In 
particular I have to use CInt and CDouble to go into and out of C.  
Unfortunately only a small subset of  library functions will actually 
support CInt so I have to explicitly coerce this values.  I usually have 
a host of compile errors initially because of this silly issue and it 
makes the code ugly.  What would help would be an automatic type 
conversion from CInt to Int and CDouble to Double.  Perhaps some warning 
level could flag these if this were 'too dangerous'.
4) GHCi is really not as useful as I'd hoped.  You can not just cut and 
paste Haskell code from a text file and run it in the interpreter.  
There is also this context issue concerning what modules are actually in 
scope.  So although in Haskell once I import a module, all of its 
functions are in scope, in GHCi, if I load this module only the exported 
functions from that module are in scope.  The result, again, is that I 
can not get an apples to apples idea of what is happening in my code. 
Thus I have been using GHCi primarily as a syntax checker for Haskell 
constructs.
5) Learning new programming patterns may have a role to play, but 
sometimes things like iteration is cleaner than recursion.  I worry 
about performance issues however.  I had to create a 50 Mbyte matrix and 
I used what I thought, initially was an elegant contruction technique in 
Haskell.  Something like this
do
...
    sequence $ [ reffill b s | s <- [0..(fi temits)-1], b <- [0..(fi nc)-1]]
...(push list on to matrix stack)

The refill function generates a matrix based on basestation index b and 
SU index s and pushes it on the Matrix stack in C, inside an IO monad.  
So it returns IO().
The list comprehension ends up doing a cartesian product of all (b,s) 
pairs which in this case is a large number.  fi is my shorthand for 
doing an annoying CInt to Int conversion.  The problem with this code is 
that it takes about 500 Mbytes in memory instead of 50 Mb.  Apparently 
it loads up all the potential IO actions into the huge list before 
executing it, taking the factor of 10 or so hit.  There is probably a 
nice space saving way of doing this, that executes each IO action before 
generating the next one, but I was in too much of a hurry to figure it 
out.  This also makes me wonder about the efficiency of the C 
interface.  Each IO action calls a C function  (using the unsafe 
specifier in the import declaration).  I hope there isn't too much 
overhead with this.  In my case I do almost no marshalling.  Most calls 
have no arguments and no returns, or at most require a handful of CInts 
or CDoubles. 

My application has 60-70% of it's statements in an  IO monad calling 
lots of C code.  I begin to wonder if all those statements shouldn't in 
fact just be in C to begin with.  Thus I begin to wonder why I'm using 
Haskell.  Maybe I just need some encouragement that my choice will pay 
off in the end.