Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so "difficult" several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With "That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there." What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell.
Casey Basichis <caseybasichis at gmail.com> wrote:
I'm not entirely sure what you mean.
I'm intending on using Ogre for GUI - for which there is the Hogre bindings, but after emailing the DEV about it, I didn't get the impression from his advice that I should be using it for production code. Here is what he suggested:
"It depends, really. Hogre is good for running Ogre from within Haskell, but it has its limitations. The number one thing people have been struggling with is handling input with hogre - there's Hois (Haskell wrapper for OIS) but it's not perfect (it misses input events), and the other option is having to write some C++ glue. Hogre is a solid proof of concept and you can do some demos with it, but if you're e.g. writing a game it might be a bit of a struggle. In the end it's about how much you value being able to write code in Haskell (or how allergic to C++ you are)."
I'm on iOS so I imagine those difficulties are compounded.
I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close.
Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries?
That's not what I'm suggesting. It was just too little information to properly judge the difficulty of doing everything in Haskell.
Binding to Ogre (or C++ in general) is indeed difficult. If Hogre doesn't work or is too limited, your best option might be to write a C wrapper around the Hogre functionality you need. Another option is to use SDL/OpenGL directly, which may be easier or harder depending on your application.
However, if you can build the bridge between your rendering library and Haskell, then Haskell is certainly the better choice.
Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit.
I am interested in your thoughts and I am open to whatever, but you are the first to suggest that the mix is a bad idea.
That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. Nowadays you can write all sorts of interactive applications in Haskell, including GUIs, TUIs, games, simulations and web applications. However, I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm afraid that it's not going to happen any time soon.
Ultimately it's your choice. Let me summarize the possiblities:
* C wrapper around Ogre. Easy integration, but need to write the rendering code in C/C++.
* Full FFI bindings to Ogre. Difficult integration, but you can write your rendering code in Haskell.
* Partial FFI bindings to Ogre. Integration may be somewhat easy, if you do the initialization in Haskell and the actual rendering in C/C++. However, this again requires to write the rendering in C/C++.
* Using SDL/OpenGL directly: Everything available for Haskell. May be difficult, because you need to write OpenGL code.
I hope, this helps.
Greets, Ertugrul
-- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasichis@gmail.com 310.387.7540
From my experience, these things are needed to get solid (i.e. not flaky software) results. This is not what normal Haskell bindings look like though:
1. Create an interface over the Haskell RTS if you are going to use any of
it from C++, and use dependency injection to choose between mock and real
implementations.
2. Create a mock implementation of the Haskell side if it is accessed from
C++.
3. Create comprehensive C++ only tests (using mock Haskell) that runs
cleanly through valgrind.
4. Create as small an interface between C++ and Haskell as possible.
5. If you have a wide API that has little performance implications between
Haskell and C++, consider not using the FFI directly, but a higher-level
abstraction such as protocol buffers for this part of your API.
Alexander
On Thu, Jan 31, 2013 at 9:53 AM, Casey Basichis
Hi Ertugrul,
Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go.
Unfortunately Ogre isn't the only large library I'm using, so "difficult" several times over sounds like a good way to handicap the project early on.
I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running.
As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question.
What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell?
Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land.
Thanks, Casey
p.s.
With
"That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there."
What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell.
Casey Basichis <caseybasichis at gmail.com> wrote:
I'm not entirely sure what you mean.
I'm intending on using Ogre for GUI - for which there is the Hogre bindings, but after emailing the DEV about it, I didn't get the impression from his advice that I should be using it for production code. Here is what he suggested:
"It depends, really. Hogre is good for running Ogre from within Haskell, but it has its limitations. The number one thing people have been struggling with is handling input with hogre - there's Hois (Haskell wrapper for OIS) but it's not perfect (it misses input events), and the other option is having to write some C++ glue. Hogre is a solid proof of concept and you can do some demos with it, but if you're e.g. writing a game it might be a bit of a struggle. In the end it's about how much you value being able to write code in Haskell (or how allergic to C++ you are)."
I'm on iOS so I imagine those difficulties are compounded.
I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close.
Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries?
That's not what I'm suggesting. It was just too little information to properly judge the difficulty of doing everything in Haskell.
Binding to Ogre (or C++ in general) is indeed difficult. If Hogre doesn't work or is too limited, your best option might be to write a C wrapper around the Hogre functionality you need. Another option is to use SDL/OpenGL directly, which may be easier or harder depending on your application.
However, if you can build the bridge between your rendering library and Haskell, then Haskell is certainly the better choice.
Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit.
I am interested in your thoughts and I am open to whatever, but you are the first to suggest that the mix is a bad idea.
That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. Nowadays you can write all sorts of interactive applications in Haskell, including GUIs, TUIs, games, simulations and web applications. However, I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm afraid that it's not going to happen any time soon.
Ultimately it's your choice. Let me summarize the possiblities:
* C wrapper around Ogre. Easy integration, but need to write the rendering code in C/C++.
* Full FFI bindings to Ogre. Difficult integration, but you can write your rendering code in Haskell.
* Partial FFI bindings to Ogre. Integration may be somewhat easy, if you do the initialization in Haskell and the actual rendering in C/C++. However, this again requires to write the rendering in C/C++.
* Using SDL/OpenGL directly: Everything available for Haskell. May be difficult, because you need to write OpenGL code.
I hope, this helps.
Greets, Ertugrul
--
Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasichis@gmail.com 310.387.7540
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (2)
-
Alexander Kjeldaas -
Casey Basichis