Hi ! ajb@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). Cheers, -- Sébastien