Ditto. I spend 95% of my time writing Monte-Carlo based financial simulations. Obviously, they are computationally intense. That being said, after many years, I finally figured out that prototyping in in a scripting language (formerly Python now Ruby) and then factoring out parts into other languages for speed (usually just a C++ or C/CUDA binary via a `cmd` call) makes me 100 times more productive than just doing it in C.
Funny, I do a lot of stuff with Monte-Carlo* as well and I have reached the opposite conclusion. It's soooo much easier (and more pleasurable) to prototype in Python versus chasing down null pointer violations all afternoon. At least for my simulations I have always found that 90+% of the execution time is spent in one or two routines which can then be factored out into C (or FORTRAN, which is faster.) Also, it's much easier to inspect and graph your data in Python; when I develop in C I tend to skip these things because they're such a PITA. I can't help but wonder what I'm missing.
Although, at a 100x productivity increase, I might have to give it another look; I'd be out of grad school by Halloween.
*For the uninitiated, Monte Carlo is a fancy way of saying "for loops."
I think you misinterpreted what I said. I prototyped formerly in Python, and now with Ruby. I also do not chase down null pointer violations most of the time (except when debugging any CUDA exported functions that need speed).
Ahh, righto, sure did! Well then we agree. How do you like CUDA? We just took delivery on a 4xTesla C1060 box which I can't wait to check out. Sadly it's sitting in a closet right now because of departmental squabbling over who must foot the air-con bill when it gets plugged in :-)
I have a single C1060 on my desktop system -- it is the single greatest investment I have ever made. Granted, debugging CUDA is not great, but the for many things Thrust alone (http://gpgpu.org/2009/05/31/thrust) can make demolish any bottlenecks so you can get closer to your idea rather than spending all your time on metal. However, I have to play with OpenCL...especially now that OSX has built in support!
When you get down to it, all the code really just ends up being machine code. Many popular languages now allow you to build interfaces to use the generic C libraries.
This lets you do the complicated, high-level stuff in a language suited for it, and do the nitty-gritty stuff in C or your favorite compiled language.
It's very important to pick the right tool for the job, and these days that doesn't even have to be one tool at a time.