Why Java? Doesn’t sound like a meaningful question at first – whatever works, right? Yes, but it’s not that I didn’t have a choice, and Java was hardly my first choice. There were at least a few other attractive options: C#, Python and Go. Lat but not least, don’t forget, I am a professional C++ developer. So why Java? The history of Tradelib is somewhat interesting, so I decided to share it.
It all started about two years ago. After exploring many options to do “path-dependent” backtesting, I settled on creating my own framework. In C++. Yes, you read that right. I made a mistake using C++ for a hobby project. Simply, it was the wrong tool for the job.
In any case, after a few months of developing, I got the first strategy implemented. A few more followed. Not too long after however I started hitting the first obstacles. Inertia took me through another couple of months, but I reached a point at which I was convinced – C++ is not the right language for the task. In fact, my feeling is that C++ is not the right language for almost any task.
At this point, I took a step back and considered carefully which direction to take. It came down to choosing a language. There were a few obvious choices:
Let me share my thought process.
It’s a new language, but seems to have reasonable traction. It’s compiled, so it’s fast. However, I was done with it fairly quickly. My main objection was that it’s too new. Thus, little chance that brokers will provide APIs to support it in any foreseeable future. My other objection was more subjective – I simply dislike Go’s syntax and the restrictions it imposes on developers. They might be for the better, but the idea of one nerd telling all others how to better nerd … not my cup of tea.
This one was really tough. Considering just the language, C# is the best language I have ever used. There were already trading projects using it. The good old Tradelink, as well as the new QuantConnect. A quick look at both libraries convinced me however that they will both need a good amount of work to bend them to my needs. But that was ok. The deal breaker was that C# was a single-platform pony (in my mind, the Mono project is not a first class citizen as frameworks go). Moreover, that wasn’t the platform I was using for my semi-automated trading.
I have used Python for scripting. It’s very, very good. All batteries included indeed, a fact I greatly appreciate. There were even open source projects in Python. The well-known zipline by Quantopian turned out be designed in a way which would make it hard for my needs. Not to mention, it turned out to be quite slow. PyAlgo seemed to be designed in a very similar way to what I thought it’s a good design based on my C++ experience. At the end, however, it was the speed and the lack of brokerage support which turned me away from Python. It was close though.
There is only one thing that I have a problem with Java, the language itself. 😉 There are a few things that I find questionable. One that comes to mind is the butchered BigDecimal type: it takes a genius to decide to make it non-native in a language which doesn’t support operator overloading, but one was around apparently.
// for the uninitiated this is a/b - 1 BigDecimal res = a.divide(b).minus(BigDecimal.ONE);
You write a few statements like the above, and you quickly go to the “bad” doubles.
Despite all that, I took the practical route.
Java is a giant among languages. In terms of libraries and tools it’s second to none. It’s trivial to find production-grade packages to do pretty much anything. Exceptional package management via Maven, Graddle, Ant, you name it.
Java runs on all major platforms. Java is also well-supported by all major brokers.
Last but not least – it’s a VM language. Thus, although not as fast as C++ and Go, it’s way faster than Python and other scripting languages.
All in all, it wasn’t an easy decision. So far so good though.