Did I just read an admission that Sony Imageworks use Haskell for movie post-production?

Nice try, but I do not speak for Sony Pictures Imageworks. Whatever things they do or do not do in post-production would no doubt fall under some kind of trade secret thing and I would not mention them here. Kudos to you for knowing that Imageworks is a part of Sony. You must be an industrial spy! Even so, you are inferring more than I implied. By "in my work", I mean specifically that I use Haskell (and GSLHaskell) to develop algorithms, prototype them, then validate the results of production code written in C++ (and GSL). As such, I couldn't care less about efficiency in Haskell. I realize that this way of doing things may be considered "impure" to hardcore Haskellers. My full comment was actually:

GSL is written in C, and I don't know any language more portable than that! gsl_vector and gsl_matrix use a continuous block of doubles, so you can use the FFI to marshall this however you want for efficiency.

I know it's heresy on this list to treat Haskell like a wrapper over C/C++, but my experience shows that it has a lot of advantages, even if the final product is code in another language! This is the only argument for using Haskell "in the real world" that I have found has any traction with management, so I hope people don't disdain it while waiting for the day when the benefits of Haskell will be apparent to all. Dan Dan Piponi wrote:

On 2/28/07, Dan Weston wrote:

...

I like spending my time on interesting things, not reinventing pre-debugged and efficient libraries. I use GSLHaskell in my work and have never had a problem.

Did I just read an admission that Sony Imageworks use Haskell for movie post-production? -- Dan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Feb 28, 2007 at 02:54:06PM -0800, Dan Weston wrote:

GSL is written in C, and I don't know any language more portable than that! gsl_vector and gsl_matrix use a continuous block of doubles, so you can use the FFI to marshall this however you want for efficiency.

I'd stick with GSLHaskell until you're ready to optimize the data marshalling though.

I like spending my time on interesting things, not reinventing pre-debugged and efficient libraries. I use GSLHaskell in my work and have never had a problem.

It seems like GSLHaskell is an awfully big stick, when all you need are scalar multiply and vector addition. Of course, we don't know what functions he wants to minimize, but in the absence of any need for GSL functions, I don't see a good reason for it. I see that GSLHaskell has a binding to a conjugate gradients minimizer, but it's not useful for any hard problems (it stores the trajectory, which defeats the purpose of using conjugate gradients), and can only be very, very slow.

From the API alone it cannot be efficient. Code that is written by people who obviously either don't know or don't care about efficiency is just not in general a good idea. I don't know what you use GSLHaskell for in your work, but I hope you don't use it for conjugate gradients, or only use it on easy problems. -- David Roundy Department of Physics Oregon State University