sebastien.pierre at adival.com
Fri Mar 19 10:03:16 EST 2004
ajb at spamcop.net wrote:
> I am still unsure of whether Haskell would be a good competitor against
>>other languages in my case, but it seems like if it does the best option
>>would be to reuse C++ graph libraries and carefully write a wrapper
>>around them to minimize passing values between C and Haskell worlds.
>As a matter of curiosity, have you considered prototyping your program
>in Haskell first, and then subsequently translating it into C++?
>(Boost.Graph is supposed to be quite good, incidentally.)
I actually considered to prototype the program in Python and then use
Java when things get settled... the fact is that I don't know Haskell
much (I never wrote a program with it) and try to avoid C++ when I can
(too error-prone in my opinion). Most of the program will be made of
algorithms that manipulate RDF graphs using the Redland RDF library (C
based), and this library happens to have both Python and Java bindings.
>If Haskell provides more rapid development (and I think it does), then
>you can spend time in Haskell making your algorithms work, finding the
>"hot spots" and generally optimising it, then translating parts of it
>into C++ as needed.
Johan "Mahogny" made a point when relating his problems with implenting
complex algorithms in C and Haskell. I personnaly had a rather
frustrating experience of implementing a Ford-Fulkerson graph operation
with Java... the imperative style plus the OO paradigm did not put my in
the appropriate perspective to properly implement this.
I truely think that functional languages are much more suitable for
implementing complex graph algorithms than imperative languages, though
I can't really explain why... (I may say that I consider
functional/declarative programming good for expressing
processing/behaviour and OO/imperative good for expressing data).
More information about the Glasgow-haskell-users