[Haskell-cafe] Why Haskell?

[SevenThunders]

David F. Place wrote:
> 
> 
> On Jul 23, 2006, at 1:20 AM, Matthew Bromberg wrote:
> 
>> I do want to understand the advantages of Haskell.  My approach has  
>> been to consign the heavy imperative, state manipulating code to C  
>> and leave the higher end stuff to Haskell.  The nature of my  
>> problem  (a simulation) necessitates holding state for efficiency  
>> reasons.  (e.g. I don't want to copy a 500 MB matrix every time I  
>> change an entry.)  I assumed that Haskell would be easier to write  
>> and perhaps maintain than the horrors of pure C.  At this point  
>> there is no turning back. I will probably answer this question soon  
>> enough.
>>
> 
> Hi Matthew,
> 
> It seems that a lot of your issues stem from the design decision to  
> implement a good chunk of your program in C.   There are certainly  
> ways to implement an indexed data-structure in Haskell with good  
> performance for persistent functional updates.  Alternatively, you  
> could write imperative code in Haskell to update the array in place  
> non-persistently.  So, the decision not to use Haskell for that part  
> may be a case of premature optimization.
> 
> Cheers, David
> 
> --------------------------------
> David F. Place
> mailto:d at vidplace.com
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 

You make a good point and the decision was by no means cut and dry.  However
I made a point of developing some test code using some the newer array data
types and looked at maintaining the array in Haskell and then directly
calling Blas etc.  I even had a nice polymorphic matrix class going. 
However I found the array interface just a bit too 'clunky' to use a
technical term.  The withArray interface is not very appealing.  The layers
of lambda notation was giving me a headache.  

The idea of separating the imperative code into an imperative language was
appealing to me.  Moreover using a stack based architecture for matrix
operations makes the C end of things very easy to implement.  The big
bugaboo of memory management issues pretty much disappears, and thinking of
the world state in the IO monad as a stack of matrices has a nice intuitive
appeal for me.  It seems to work well so far as I said earlier.  I'm not
sure all my issues would have gone away if I had tried to do more of the
matrix op.s in Haskell.  It is pretty much a given that I need to interface
to external optimized libraries, that's where the big number crunching is
occuring and those libraries have had teams of Ph.D.s working on them for
years.  I want to leverage that.  My approach actually minimizes the amount
of marshalling I have to do between C and Haskell.   The stack manipulations
are simply scripted in a do clause, with nary an argument being passed.
-- 
View this message in context: http://www.nabble.com/Why-Haskell--tf1986013.html#a5458965
Sent from the Haskell - Haskell-Cafe forum at Nabble.com.