Yeah. I remember the discussion about generics in the java world - ridiculous. Then MS came out and said they dont ahve generics in .NET 1.1 because they wanted to do it RIGHT - and they did. I will never understand how people can defend the java solution here. Sorry
I think targeting the JVM the first time around is ideal. You can lean heavily on the JVM ecosystem (Apache projects, Spring, Esper, cross platform, etc) and performance is relatively good. You can do some pretty damn high frequency trading on this stack, but if you're seriously trying to compete in the low latency game, all roads lead to the same outcome. The tendency to over engineer and prematurely optimize has killed a lot off competition.
That is syour side (as user). I meant the decision from the point of the their side. They decided to be chaeap, fully kmnowing there will be bad performance implications on the language side. Not relevant for trading, but try doing 3d work The whole JVM bytecode needs an overhaul
Ah, okay. Some of the design choices are definitely peculiar. On that front, all hats off to Microsoft for acquiring great programming language researchers (Don Syme) to actually help design the runtime and languages. If only Mono were up to par.
Actually a lot can be explained with what java was orignially written for. But tat one point they should have gotten that overhauled. Micorosft did some really great moves - buying the best VM team on the market, getting a great langauge designer for C# (Anders Heilsberg) on board. Sun... basically.... managed to get pretty bad with no overhaul
Might have done. Never looked at it before to be honest. http://javolution.org/target/site/apidocs/javolution/io/Struct.html It looks like they've had to implement a lot of botchs to get around this hole in the Java spec and at the end of the day you are still passing around a reference type.
Exactly. Let's be honest, we can sit here all day discussing the merits of various technologies but really, honestly, making money all comes down to the quality of your alpha generation ideas. Aside from HFT strategies, I think the choice of platform is probably mostly inconsequential. Many people have been waiting years for this. Ain't never gonna happen.
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. This is why I can understand those pushing C++. 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++.
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). 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. 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.