Why is Tradelib in Java?

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:

  • Go
  • C#
  • Python
  • Java

Let me share my thought process.

Go

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.

C#

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.

Python

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.

Java

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.

Comments

  1. Thanks for sharing your thought process for choosing a new language.

    I’m curious to also hear your thoughts on what is wrong with C++, for your task and in general.

    1. quintuitive says:

      Small to medium projects need far more than just a language to develop quickly. In other words, they need libraries and tools besides the language. C++ is a massive language with very little (useful) functionality bundled into its standard library. In year 2016, it doesn’t have datetime support! Nor does it have a portable filesystem support (yet)! One can use libraries, but they come with their own set of issues. First, they might have bugs, and it turns into a library management hell. Second, smooth dependency management, is typically part of the build system. Like Maven, like Graddle – all of them for Java. C++ has to offer very little here.

      1. As far as not having enough in the standard C++ libraries, I think that is partly by design. The functionality you mention has been in boost for ages, which is an excellent C++ library. I suspect it’s more reliable than a lot of the Java standard libraries.

        Dependency management (I assume you mean external dependencies) is definitely behind the curve in C++. It hasn’t been enough of a setback to turn me away from C++. If the external libraries would all use CMake as the de-facto standard, the problem would be solved. For example, I was able to incorporate Qt5 into a CMake project in a matter of minutes, because it provides a CMake module. It becomes plug n’ play, almost as easy as C#.

        My main experience outside of C++ (I don’t count R as a software development language) is C#. When I hear people claim that development is 5x faster in C#, I suspect that they are not very good C++ programmers 😉 Personally, the thing I found most impressive about C# was the way the Visual Studio editor is so powerful at automatically completing expressions as you type.

  2. Howdy doody. Am I too late to the party? I have studied all languages for trading. I would say Matlab could be considered the Holy Grail if it was FREE but my folks want free so I now focus on Python. Yes, Python is slow but I am looking at advanced ways to peppy up the beast via GPU for backtesting. It integrates nice with C++. I would consider Java but working with Python where the code is compact, it will be hard for me consider another language at this point. I did resist Python but that was my long gone Windows days as I switched recently. Python seems to be a decent language for command and control from an automated trading perspective. This brings me to bloat ware Java. After 7 years doing Java, I moved on as I found Java engineers love to over-complicate problems. As for R, I found that community to negative for my tastes. In a nutshell, each language has it’s pros and cons but I know the author of this blog who has been most helpful in many ways esp. Interactive Brokers. This is where the Java API component will be part of in my arsenal for the new trading system I am unleashing soon. I hope this helps from my little minion world

  3. Shane says:

    I’m finding that for almost any problem I’m trying to solve I’ll use a blend of Scala and Java 8. More specifically, Java 8 when I have to (I want some Java framework, external API, code that I need others to work on who don’t know Scala, etc.) and Scala for everything else (prototyping, linear algebra, statistics, machine learning, text processing, real time event driven shenanigans etc.). For me it’s the “best” of both worlds. All languages are just tools and they are all flawed. But Scala is very concise and has eliminated many of the annoyances in Java. Forget the functional programming hype/stigma. In reality it’s just Java for modern times. I use the same IDE and package management tools and don’t have issues with applications leveraging both languages. If Java continues to make changes such as that in Java 8 the need for Scala may go away, but for now it’s really a versatile complement.

    1. quintuitive says:

      Thanks for sharing – I’d definitely take a look at Scala. Have been on the sidelines so far.

  4. Thanks for sharing. I’ve been doing my work in Python despite having far more Java experience. I’ve definitely suffered from both the lower performance and lack of API support. You’ve given me the push to rebuild some of it in Java and compare.

    Regarding Python and IB (my situation); I am also considering a 3rd party wrapper API called IBPy, recently featured on QuantStart. No affiliation, but it could at least solve the API issue for us IB customers.

    https://www.quantstart.com/articles/Using-Python-IBPy-and-the-Interactive-Brokers-API-to-Automate-Trades

  5. Have you considered Scala? It’s basically a far superior version of Java. You get to leverage the entire Java ecosystem with a syntax that is as expressive if not more so than Python. Lots of leading data science projects are moving to Scala as it provides a more powerful and concise syntax that works well for numerical programming. It runs on the JVM, so as similar performance characteristics to Java and you can use all the Java libraries you know and love.

  6. Fabian says:

    Did anyone tested julia ? I should be as simple as python but as fast as fortran…

Leave a Reply