Quote from gigi:
I agree with you, but careful, the argument goes both way. Pushing it further, I can ask why would you do the strategy in C#/Java when you can do it in Python (like I do) given that speed is not an issue for non-HFT systems, and considering the (massive in my opinion) Python productivity gains. A language is not only chosen based on performance, but also on how easily you integrate it or how familiar you are with it.
Of course, you are right. My technical background was initially in C++ and then I moved almost exclusively into Java and C# about 8 years ago. I code in C# because it is the language I am most comfortable with and it was the highest level language that meets my performance requirements. If I was looking at analysing condensed data rather than unfiltered tick data I probably would have gone one rung further up the language ladder and learnt a higher level language (such as Python).
Quote from gigi:
This is why I can understand those pushing C++.
I would advocate using the language in which you are most productive which meets your technical (e.g. performance) requirements. If this happens to be C++ then great. You will be working at your most productive levels and getting high performance code thrown into the equation as a bonus.
My real gripe is with those people that seem to insist all serious trading platforms
must be developed in C++, regardless of performance requirements. There are quite a few people in the industry that look down their nose at anything not developed in C++. I just don't see a valid business case unless you are in the HFT arena. I don't think there's anyone who would disagree that C++ takes considerably longer to build, test (most importantly) and maintain.
Quote from gigi:
When I work in C++, I find it very hard to write "slow" code, even if I know that that piece of code will only be called once on startup 
I think it's a language philosophy, where "slow" code is considered ugly. When working in Python I have no such problem (and I find this liberating), probably because I know it's already thousands of times slower (for number crunching) than C++, so if I add some more slowness it will really make no difference
Another thing which I realized after 2-3 years of using Python. In C++ I would quickly drop some ideas because they are just painful to write. In Python I can write in two days a tick storage with individual files for each day, have the file content compressed with LZMA (7-zip), then store all the files for one month in an uncompressed .zip archive (since 200,000 tick files are not fun to manage). But trying to do this in C++ makes my head hurt.
So I can have in this way the best of both worlds (in my opinion): manage the gross of tick files in Python, pass only the uncompressed tick data to C++ and compute the candles there, and then manage the resulting candles on the Python side again. And when I'll have a performance problem I'll see what more to move to C++.
You have got it right there, pick the right tool for the job. You don't see a construction worker bashing nails into a piece of wood with his screwdriver just because he prefers his screwdriver to his hammer, do you? Choosing a technology should always be a case of 'horses for courses'...but very few techies (including some very expensive systems architects I have worked with) can get their head around this. Developers have this tendency to become unhealthily attached to their favourite language and seem willing to sacrifice their children before they'll admit that, perhaps, just perhaps, it's not the right tool for the job. I was once brought into run a project (long ago) and in the development team was a guy who was insistently trying to write a large chunk of a complex database app using VBScript. I shit ye not.
Anyway, look at this...even the top tier IBs are starting to wake up to languages other than C++ for low latency apps.
http://www.jobserve.com/CSharp-CPlusPlus-Algos-Developer-London-Contract-W58458664EFC6E508.jsjob
There's hope for us all!!!!
Anyway, time to put the debate to bed me thinks. The biggest drain on my productivity at the moment seems to be posting on ET.
