http://ocaml.janestreet.com/?q=node/61
Caml Trading talk at CMU
Thu, 2009/03/12 -
9:30pm — yminsky
I was at CMU several weeks ago, and gave a version of my "Caml
Trading" talk there. See below if you are interested in seeing the video. It's a
reasonably good source if you're interested in understanding more about how and
why Jane Street uses OCaml.
Caml Trading
Caml Trading
- yminsky's blog
- Login or register to post comments
What programming language(s) is algorithmic trading software written
in?
up vote
11 down vote
favorite
8
|
Anyone know what programming language(s) is algorithmic trading
software mostly written in? Also known as automated trading, algo trading,
black-box trading or robo trading.
If I wanted to write the above software where would I start? Any tips/trick/advice greatly appreciated. Thank you in advance ;-)
| ||||||||||||||||||
|
12 Answers
up vote
12 down vote
accepted
|
I'm working on the same thing right now (FOREX), and I'm using
Python.
C++ is needed only for really fast strategies (mili/microsecond level) or for huge amount of data (think arbitraging the S&P 500 index versus it's 500 component stocks, BTW, another microsecond level job) You can use pretty much what you fancy if you won't trade less than a minute apart. It also depends on the API of the broker you use. Some offer FIX (socket programming), others Windows COM APIs, other Java APIs. To answer your question, most use C++. Here's a job offer of the kind | |||
up vote
14 down vote
|
JaneStreet uses OCaml. Here's a tech talk about why they chose a
functional programming language to implement their trading software:
http://ocaml.janestreet.com/?q=node/61 | |||
|
up vote
7 down vote
|
You are not defining your terms well.
Automated trading (or black-box trading) can be written in anything, provided your trade horizon is long enough and your latency requirements are not stringent. That's where the stuff from the late-night commercials comes in and you get Windows applications with their own scripting languages etc. Some people do this in spreadsheets on daily closing prices or coarse-enough 'bars' of data, and daily trade frequency. However, at higher frequencies and/or model sophistication, the door opens for Python, Matlab, R, ... as well as compiled languages. High-frequency trading is a different matter as trade horizons are much shorter and latency requirements can be critical. In this domain, the language of choice is C++ (as you can confirm by perusing job ads) with the odd sprinkling of Java or C#, as well as outliers as OCaml used by Jane Street. | ||
|
up vote
5 down vote
|
I work in a the field, so here is my knowledge about US
companies:
Quite a few algorithmic hedge funds are C++ and Linux centric. Examples include Tower Research Capital, Hudson River, Knight, etc. They typically have their infrastructure done in-house, and benefit from C++ speed. C++ is generally more common in investment banks as well. Bloomberg is also C++ based though they don't do their own trading. However, some serious players are actually in the Java world: D.E. Shaw is the most notable and probably largest. Two Sigma investments are also major players in Java, and then there are a lot of small players. I'm less familiar with the Chicago and Austin markets (other algo powerhouses) but it still seems to be primarily C++ and Java. I know that there is at least one firm in NYC that does only OCAML (Jane Street?), and they hire lots of Ph.Ds. who tend to come from a PL/functional background. I have heard stories of .NET shops but they're less common, likely because of licensing costs - Linux is more common in this domain because you can ramp up a lot of firepower quickly. Finally, quite a few smaller houses buy access to APIs to do algorithms. The company I work for, for instance, provides a trading platform and a Java based API that one can use to implement specific algorithms. A lot of the complexities of programming are hidden so the quants can focus on the algo side. I would seriously advise against writing your own trading platform. The market is saturated, and you usually have to hand optimize for years to get good performance. If you have an idea for a clever algorithm, you may be better off licensing a trading platform or joining an actual fund. | ||
|
up vote
4 down vote
|
Most of what I know is written in C++, less in Java, and some
bits in C# and .NET ASP
| ||
|
up vote
4 down vote
|
It depends on what API your brokerage provides. The one I use
for this sort of thing is Interactive Brokers, which provides APIs in DDE for Excel, Java, C++, and ActiveX.
When I first started developing my ATS, there were some eccentricities to their
C++ API, so I'm using the Java interface. It looks like the C++ API has improved
since, but I've already got a large body of working code. The APIs may provide
different features for individuals versus institutions. FIX interfaces are an
industry standard, but it may be difficult to get direct access as an
individual. Depending on which broker you select, YMMV.
| ||||
|
up vote
3 down vote
|
Just adding my two cents: the company I work at uses primarily
.NET (C# and--believe it or not--VB.NET). As others have pointed out, you're
probably not going to find a lot of managed languages like Java or anything in
.NET for high-frequency trading (e.g., tens or hundreds of
trades per second), but for algorithmic trading in general, a
managed language can be a smart choice for the faster development speed. We are
adding and changing functionality on a constant basis and would not be able to
do so nearly as rapidly working in a language like C or C++.
The biggest issue with a managed language in this context is not garbage collection per se, but specifically garbage collection that occurs at a time-critical moment such as when a high volume of trades are being executed. Since the CLR handles this by itself, the developer has little control over such situations, which is fine (even desirable) in a typical business application but terrible in a real-time trading environment. The standard strategy that I'm aware of (and that we use) to minimize this potentially catastrophic scenario (a quote lagged by 50ms could be bad; one lagged by 1s could be devastating) is to use resource pooling and recycle the same objects over and over in favor of creating new ones. The less garbage you create, the less there is to collect. Besides that, constant performance profiling is obviously a must. A lot of the code in our codebase looks pretty ugly because of all the performance optimizations we've made (and continue to make). That's just the way it is, unfortunately, when you're competing with other traders to get to the market a few microseconds sooner. | ||
|
up vote
2 down vote
|
I've come across autotrading software written in languages as
diverse as VB6 and Java (hmm, maybe not that diverse). The stuff that actually
talks to the exchanges to do the trades always seems to be written in C++
though.
| ||
|
up vote
2 down vote
|
Depends, these days a 4th gen language like Java or C# for
normal e-commerce (other such languages will also function -- e.g., Erlang or
Python); however, there is a real-time aspect to the --hard-core --
trading side.... such systems use expensive -- non-standard -- hardware
to eliminate latency and naturally software is written in C++ or C. every ms
counts when you want to out-do others competing with you.
| ||||||||||||
|
up vote
0 down vote
|
Some systems, e.g. StreamBase, let you define your trading algorithms in a proprietary language (which
may be a visual language or something declarative instead of a common
programming language).
Engines of this type can be created using anything from Java (to run on any server) to machine language (to run on specialized hardware). | ||
|
up vote
0 down vote
|
To be very honest: C, C++, OCaml, Perl, and FORTRAN. Those
languages tend to dominate numeric things such as financials. I'm not saying
they're better languages or that newer stuff hasn't come along but many
companies are loath to pay for "upgrades."
| ||||||
|
up vote
0 down vote
|
We have run the Trading Shim project (link below) for several
years, which is designed to provide the connector between a Java based, FIX
translation and account management gateway, called the TWS, which connects to
the upstream exchanges, account detail, and data farms of the broker:
Interactive Brokers; and on the downstream toward the trader's strategy and
management clients. It exposes a simple text command interface on its input, and
results datastreams in several formats (syslog, logfile, standard
out)
The shim is written in C++, and is released under a GPL3+ license. The testing harness (which simulates a client) is written variously in shell, Ruby, Python, and basically any language which can read from standard in, and write to standard out. So ... any language. I collect a linkfarm to several such projects and products, note their implementation lamguage, and the licenses under which they are released here |
http://www.trading-shim.org/faq/?other-voices
trading-shim Frequently Asked QuestionsCertain recurring questions tend to come up in mailing list and support contexts; the links below address or point to further resources about the most common areas of inquiry.
Show Categories
Other voices - connection to the TWS |
The Jump links are: here |
Language (and License) | Website or URL | Developer |
C++ (GPL) | Trading shim | Devels mailing list |
C++ (unk) | Lightweight TWSAPI C++ library
wrapper (then go to Files -> C++ Code) |
Jan Boonen |
C (BSD) | C language API for TWS | Slavcho Nikolov |
Java (BSD variant) | HSQLDB Java SQL relational database engine |
Thomas Mueller, et al. [ used in TWS ] |
Java | IBdemo (Alternate location) |
Vic Szmyd |
Java (LGPL) | IBTrader | Gabor Liptak |
Java (LGPL) | JDOM light weight Java API to manipulate XML |
Jason Hunter, et al. [ used in TWS ] |
Java (LGPL) | JFreeChart | David Gilbert, et al. [ used in TWS ] |
Java (new BSD) | JSystemTrader | Florent Guiliani, et al. |
Java (GPL)
Matlab connector |
CCAPI
Patton code (BSD) and CCAPI-Matlab connector |
ActiveStocks.EU, Rene Nederhand |
Java (LGPL) | Mondrian Java OLAP server |
Julian Hyde, et al. [ used in TWS ] |
perl ('same terms as Perl itself') |
perl-Finance-InteractiveBrokers-TWS | Jay Strauss |
Python (BSD) | IBPy - and - ProfitPy |
Troy Melhasemailing list |
R (GPL) | ib notes | Vincent Andres |
Java (LGPL) | ROME Java tools for managing RSS and Atom feeds |
Alejandro Abdelnur, et al. [ used in TWS ] |
Ruby (GPL) | IB-Ruby | Paul Legato |
N/A | Yahoo forum | mailing list |
N/A | Chuck Caplan wiki | wiki |
Note: We strive to get license information correct; please send a email report if you note a possible error to: herrold@trading-shim.org citing any questioned matter.
Available Source Efforts - Libraries, Visualization and Trading Platforms - Platform neutral
These platforms either explicitly support indicator computation, visualization, or trading through IB and the TWS, or appear well suited to such an effort.C++ (BSD) | TA Lib (library) | Devels |
C++ (BSD) | QuantLib (library) hooks to a spreadsheet |
Devels |
Java | JQuantLib | |
C and others (freeware) | gnuplot | Contributors |
C++ (GPL v2) | octave | Contributors |
C and others (GPL) | R | Contributors |
C and others (GPL) | R-SIG-Finance | Contributors |
C++ (GPL) | R Server | Simon Urbanek |
R (GPLv3) | quantmod | Jeffrey A. Ryan |
R (GPLv3) | TTR: Technical Trading Rules | Josh Ulrich |
N/A (Protocol) | FIX Algorithmic Schema | Working Group |
C++ (BSD like) | QuickFix | Developer group |
Java (BSD like) | QuickFix/J | Developer group |
Java (GPL) | Continuous Trade (Possible fork of Merchant of Venice) |
Jordi Pujol i Palomer & Xavier Diumé i Delip |
Java (Eclipse Public License) | Eclipse Trader | Developer group |
perl (GPL) | Genius trader (local) |
Raphaël Hertzog & Fabien Fulhaber |
C++ [Web UI] (GPL) (uses TA Lib) |
AST | Michael Williamson |
Java (Common Public License) | Eclipse Trader | Marco Maccaferri |
Java (BSD) | JSystemTrader | anonymous webpage presently |
Java, Ruby (GPL) | Marketcetera (with C++ and Fix hooks; CLA, MySQL CLA<>) |
Devels - toli, gmiller |
C++ (BSD) | TREE - data connector and store Structured Software Systems at SourceForge |
Devels - georgev13 |
Java (GPL) | Merchant of Venice Based on Joone |
Andrew Leppard, Daniel Makovec |
C++ (GPL) | Qtstalker | S Stratos |
Python (GPL) | Sage | many |
Java (GPL) | truetrade | 'tyrotrade' |
Java (GPLv2) | ActiveQuant | Devels |
Apache 2.0 (BSDish) | ActiveMQ | Devels |
GPLv3+ or LGPL | Zero MQ | Devels |
Apache 2.0 (BSDish) | Qpid | Devels |
Connection to the TWS - Commercial and Non-available Source Efforts - Platform neutral
Language | Website | Developer |
Delphi | Delphi / BCB / Kylix TIABSocket | Ross Hemingway |
Excel | INDEXFUTUROS | IndexFuturos Engineering (Madrid) |
Java | Eclipse Trader - and - (second site) | Eclipse Trader is an Eclipse Rich Client Platform (RCP) application |
Java | JSystemTrader | Eugene 'nonlinear' |
Java | jTWScharts - Charting jTWSdump - Downloader |
'Orionn' |
Matlab | Matlab trader - also tick, history, earnings | anonymous |
Commercial and Non-available Source Efforts - Platform limited
Language | Website | Developer |
C# | TradeBuild | Richard King |
Smalltalk | Alchemetrics | Alchemetrics Trading Research (mentioned) |
unknown | Trade-Commander | anonymous |
unknown | MetaQuotes Language reference | MetaQuotes |
Unknown | SSChart | Simian Savants |
seemingly C++, Java and FIX | SmartQuant documentation | SmartQuant - Anton Fokin, acquired by QuantHouse |
Unknown | Futures trader - simulator | RTS Trading |
Unknown | TSim plus - simulator | Henry Eldridge-Doyle |
Tools we use
Language | Website | Developer |
n/a | SEC Info -- EDGAR filings, on a 'push' basis | n/a |
Jump Links:
[ connection to the TWS | Available Source Efforts - Libraries, Visualization and Trading Platforms - Platform neutral | Connection to the TWS - Commercial and Non-available Source Efforts - Platform neutral | Commercial and Non-available Source Efforts - Platform limited Tools we use ] Last modified: Tue, 30 Dec 2008 18:03:39 -0500
[ Home | Search | Interior documentation | Program documentation | FAQ | Download | PDFs | Screen shots ] [ Contact Us | Site Map | Bugzilla | Mailman | Mailing List Archives: (Main) | License | About | Press | Copyright ]
Copyright (c) 2006 ... 2009 trading-shim.com, LLC, Columbus, OH
Comments
Quoting for OCamlCore.com
Thanks in advance Sylvain Le Gall
(website: www.ocamlcore.com)
Quoting
Excellent talk
Thanks for putting this talk here.
It is very interesting and I know I'll now have an excellent link to give to people with a bad opinion of OCaml !
Quoting
So this is not about quoting like "OO is ... " as Y. Minsky from Jane Street Capital said. I just want to take your ideas, write some web pages and thank you in another web pages for giving me ideas about these points.
Do you still agree ?
Quoting
First, I think this is what you were trying to say, but to be clear, my point about subtyping is that it is the wrong default form of polymorphism, and that the right default (not implementation) is parametric polymorphism.
Second, while you've correctly pointed out some of my worries about F#, the language also has a great deal to recommend it. I don't think we'll be switching over all of our code anytime soon, but I do think it's a lovely language, and may be the way in which the Hindley-Milner type system hits the big time...
Very nice talk
Great seeing OCaml being used in such a large company
Monitoring software
tiger, Isn't that basically
Further Reading?
OCaml vs Haskell
As a Scheme programmer myself working on AI solutions for trading I have been looking at more performant alternatives to Scheme and have gravitated towards Haskell rather than OCaml because of its support parallel processing and marginally better performance than OCaml on the Language Shootout.
Did you evaluate OCaml against Haskell and what were your reasons for going with OCaml ?
Regards
Andrew
Credit where it's due
Poor example for ADTs
I think that the example for ADTs is rather poor, since this kind of thing can be done just as well in OOP languages. For example, in Java you'd write something along the lines of
interface Instruction { int getId(); } class Order implements Instruction { int id; public int getId() { return id; } } class Cancel implements Instruction { int xid; public int getId() { return xid; } } class Stuff { static List<Instruction> filter_by_oid(List<Instruction> l, int oid) { List<Instruction> new_list = new LinkedList<Instruction>(); for (Instruction i: l) if (i.getId() == oid) new_list.add(i); return l; } }
This is certainly uglier than the OCaml version, but it's not because Java doesn't have ADTs. It's ugly essentially because all the other FP stuff like higher order functions, closures etc. is missing. Note that I'm not disputing the superiority of functional languages, I just think that you chose a bad example to prove your point that ADTs help writing less buggy code.
examples
getId
as to what ID to return. For the cancel, should you include the identifier for the cancel message, or the identifier for the order to which the cancel is referring? There are really two valid choices, and you may need to make the choice differently in different contexts. By using a variant, you get to make the decision differently in each context. By doing this with object-style subtyping, you have to make the decision in the "Stuff" interface. For a library which is used in many different contexts, this means that you end up having to stuff all sorts of usage-specific details into the library, which is unnatural.For a tiny example like this, it's not a big deal either way. But as you scale up to real examples, it becomes clearer what you get from using algebraic data types.
For what it's worth, this is connected to the so-called "expression problem" which Phil Wadler has written on.
User-Interfaces
Web-based UIs
High Throughput Computing?
a worthwhile hour
I am interested to see how OCaml synergizes with the way I think. I like the balance points stated, and I really appreciated the perspective shared here.
http://stackoverflow.com/questions/1996432/what-programming-languages-is-algorithmic-trading-software-written-in