the problem with easy
Among the more challenging questions we face when describing the Puppetmaster environment are those like “how do you create new proprietary trading strategies within the environment?” It’s a difficult question because of expectations – people want to hear about some super simple scripting language that any non-technical person can immediately learn and be up and algorithmically trading in no time. A few platforms intended for retail users offer such things – one is even appropriately named easy language. When researching approaches for our system, we spent some time learning easy language and found that it in fact did make easy things easy!
The problem was that it also made sophisticated things impossible.
This led us to pursue another, more powerful, approach for which we are currently seeking a patent.
That said, once upon a time I’d worked on a system into which some enterprising engineer had embedded a TCL interpreter with which one could monitor and manipulate objects within the runtime environment. We didn’t use it for much, but it was certainly interesting and helped with debugging the live system. Ever since then, I’ve had an interest in embedding a simple language+interpreter into my systems.
Thus, when a friend who builds systems for UBS told me about a talk on the groovy language in the google auditorium. I went along to see what it was about. (Admittedly, I was in significant part motivated to see inside the mysterious googleplex. I found it disappointing unless you fancy an environment that looks like an apple store with free razor scooters for anyone who might fancy a spin…)
The talk itself was also a bit disappointing as the speaker was very permissive with the questions and google had graciously given the crowd access to free beer. Many will argue that java programmers aren’t the sharpest tools in the shed and while I won’t weigh-in on that issue, I’m pretty certain that adding beer to the equation isn’t likely to help.
In any case, I did come away from the talk understanding that 1) if our business takes off in a big way, we will not attempt to motivate people with silly toys and 2) that groovy (or any other such scripting language) isn’t a reasonable mechanism for enabling non-technical people to write trading strategies.
This is no fault of the groovy language which seems fine enough. It’s a problem with the complexity of algorithmic trading. Trading is an intrinsically uncertain, asynchronous and demanding activity. I send orders to exchanges and they respond in their own good time. It might be 20ms if I’m sitting on top of the exchange or it might be seconds if I’m around the world or it might be days or more if it’s some kind of conditional order, but it’s certainly not a fixed time and it’s an uncertain message I’ll receive in response. Messages arrive when they arrive and you have to be ready for them.
If you’re trading a portfolio re-balancing model that trades infrequently and in size then it might suffice to send a few or perhaps a few hundred vwap orders a month and things will mostly take care of themselves. Here, maybe a scripting language is sufficiently expressive. But if you want to implement that vwap algorithm yourself or implement a strategy that trades against your broker’s vwap algorithm or implement a high-frequency strategy that is very “close to the market” requiring extreme low latency and precise order management or write a discovery algorithm that’s employing proprietary understanding of the ubiquitous and ephemeral “dark pools of liquidity,” then no scripting language will suffice.
From a technology perspective, my curiosity for groovy was sated – it’s certainly possible (and even easy!) to embed a powerful scripting language into your application. But from an algorithmic trading perspective, the problem is designing a trading-specific language that allows easy things to be simply done while allowing complex strategies to be efficiently expressed as well. This remains an area of active interest and research as it may someday complement our existing methodology, but for now we think we’ve got the best solution for the difficult “problem with easy.”
