As further indication that Chicago is becoming increasingly recognized as a legitimate hub for tech talent in the U.S., the GOTO international software conference came to Chicago for the first time this week. The conference included speakers from many top names in the industry discussing the latest advancements in the software development community. Trading Technologies was proud to be a sponsor of the inaugural GOTO Chicago conference, and I was thrilled to have the opportunity to give a talk on visual programming languages (VPLs), and how TT has managed to utilize this technology in the algorithmic trading community with our ADL™ (Algo Design Lab).
Using visual programming, TT’s ADL allows traders and programmers alike to rapidly
 design, test and deploy automated trading programs without writing a single line of code.

Applying visual programming to professional industries has proven difficult; the fundamental tenets of VPLs (approachability and ease-of-use) tend to belie the goal of providing a usable platform for getting “real work” done. As educational tools for children or first-time programmers, VPLs often shine, but applying them to very specific domains (like low-latency trade development) often ends in frustration and something that looks more like spaghetti than anything else.

As I discussed in my GOTO talk, the way in which ADL has overcome these challenges—and a good model to follow when applying a VPL to any domain—is by adhering to three important characteristics:

  1. Domain specificity
    The fundamental building blocks in ADL are modeled with the automated trader in mind, utilizing concepts and vocabulary that come naturally to participants in this industry, without exposing complexity that is unnecessary to the business needs. If not domain specific, general-purpose VPLs tend to be cumbersome when trying to build something of business value.
  2. Hiding the “dirty stuff”
    As most any algorithmic trading developer will admit, managing tasks like “in-flight orders” and exchange-specific nuances add complexity to any automated strategy. What makes matters worse is that these complexities don’t offer the opportunity to differentiate your strategy from others. In other words, there is no value to be gained by solving these problems, so why spend time worrying about them? ADL aims to hide these “dirty” details to let you focus on what matters most: designing your trade quickly and safely.
  3. Mitigating the “Deutsch Limit” 
    Any development framework is only as good as its ability to provide unlimited flexibility without sacrificing maintainability; the larger and more complex your strategy becomes, the more you rely on your development environment to help you navigate your code. This should be no different for a visual development environment, and ADL strives to give you a rich set of tools that helps you manage even the most complex algos. With the proper tools in place, the Deutsch Limit is no longer a factor when it comes to managing visual complexity.

I wrapped up my talk at GOTO Chicago by explaining that I never intended to build a visual programming language. However, after realizing our industry lacked the tools which could provide a safe, robust environment for developing low-latency trading strategies, and which could empower every trader—regardless of technical know-how—to compete in the world of automated trading, ADL was the inevitable result.


A special thanks to the GOTO team for putting together such a fantastic few days of programming discourse.