7
$\begingroup$

Since couple of weeks, I started to do my research on quant finance. During this time, I could discover a lot of stuff and with that stuff, a lot of questions came to my mind. A lot of news or economic journals/magazines write about HFT/Algorithmic trading. Most of them say that the companies or software developers prefer to use C++. In some articles, the writers talk about Java, C#, C or even ASM. I tried to find the reason for C++, but I weren't successful. This topic doesn't provide answers that I need (Why is C++ still a very popular language in quantitative finance?)

Here are my questions: 1. Why C++? That some companies might use ASM (and I can only imagine ASM in HFT where milliseconds play a role), that's fine. But in medium frequency trading or in algorithms? Is it because of speed? I looked for quant finance libraries for C++, but I couldn't find a lot. The only thing is QuantLib, MatLib and TA-Lib. But no chart APIs/Libs or tutorials. Seems like no one doing tutorials. 2. Why do some people choose Java? I know, Java is very popular language and has a lot of APIs/Libs and the community is growing. But if the speed might play a role, then Java can't be the fastest (because of virtual environment). Or am I wrong? 3. Why no one is using Python for medium frequency trading or algo trading? Python has a lot of Apis/Libs like MatLib, TA-Lib, Pyqtgraph. Ok, I have to say, Python is not the fastest. 4. In this discussion Why is C++ still a very popular language in quantitative finance?, some people claim that C# might be much better for quant finance developing. Is it really true? How about Libs, APIs, Tutorials etc?

And my final question, what is the important property for choosing a language for quant finance? I don't talk about ASM because it's the fastest language and it's used for very complex calculations that have to be made fast. But what's about C++, C#, Python and Java? For me, it's important that there should be Libs and Tutorials/Examples. And the beginning, I started with python, but after all I have read, I'm not sure about Python anymore.

$\endgroup$
  • 1
    $\begingroup$ This has been discussed all over the place, and your question applies to more fields than quant finance, so expand your google search. For example, there is a discussion about the merits of different languages here: quant.stackexchange.com/questions/16792/…. As far as library support goes, C++ is natively compatible with all C and Fortran libraries, in addition to having an innumerable selection of C++ libraries, so it wins by default. $\endgroup$ – Tyler Olsen Jun 3 '15 at 16:35
  • 4
    $\begingroup$ The simpler answer here is to use what your employer pays you to use. $\endgroup$ – pyCthon Jun 3 '15 at 17:27
7
$\begingroup$

I think you might find this answer in The future language of quant programming? useful.


People get this problem wrong because they always end up discussing the theoretical advantages of these languages rather than the practical uses of these languages.

Theoretically speaking:

  • Haskell is elegant and has many of the theoretical advantages (language conciseness, orthogonality, parametric polymorphism, ADTs, higher-order functions, smart compiler), has been around for 25 years, but still isn't mainstream in finance.

  • Python is an ugly language. The syntax is adored for its expressiveness, but design decisions such as the GIL, dynamic typing, object-oriented paradigm etc. are inherently anti-parallel and decades down the road when we have hundreds of cores on each processor, our children are going to laugh at the obscurity and obsoleteness of such languages (among other things such as floppy disks).

Yet today almost everyone would encourage you to pick up Python. Why?

A language's (or any technology's, for that matter) future is decided by its community, the richness of its libraries and development tools and the self-perpetuating nature of legacy code in that language, and never its theoretical advantages. We can write essays about how we hate Java; the ROOT and Boost libraries; the verbosity of XML, but these things are here to stay because they've achieved a critical mass of users who are willing to build production strength tools or libraries around them. Dozens of functional languages such as F# will come and go, but C++ will almost certainly remain because of the sheer amount of legacy code in C++. Besides, C++ '11 is a huge milestone in sorting out the theoretical mishaps along its development path.

A few choices I'd approach cautiously:

  • Languages built around concurrent and functional paradigms: Scala, F#. I'd say to approach it cautiously because it's used in production at Dropbox, Lime, Tower Research, Credit Suisse etc. but these languages have taken a much longer time to rise to mainstream use than you'd expect them to given the current trends in processor architecture. It's hard for me to tell you whether or not investing your time now in these languages will pay off exactly 5 years from now, but we all seem to agree that these languages eventually will.
  • Domain-specific languages: Julia. Unfortunately, Julia markets itself with "C-speed numerical inner loops". It attracts the same subset of the Python crowd who would argue with these Julia users that this is irrelevant since they can always drop to Cython. Both crowds espouse a doomed paradigm and attract low quality developers. (I say unfortunately, because Julia has a great number of things that people don't realize: type-parametric multimethods, symmetric coroutines, clean interfaces with foreign languages, Lisp influences and metaprogramming support etc.)

With that, I'd encourage a few choices:

  • Languages with big brother support: Go, Swift, C#. Aside from Google's support, Go has become very popular in China; Microsoft had made a huge move forward by open-sourcing C#; and plenty of high quality UI development tools always spawn around Apple's core languages.
  • Languages intended to supplant C/C++ as a systems-level programming language: D, Nimrod. D already has Facebook's backing, and Nimrod retains the expressiveness of Python's syntax while achieving impressive benchmarks and being used for certain systems-level programming projects. Beware however that both still rely on the GC approach to memory management.

Have any of the above achieved a critical mass of good developers? I don't think so. The real solution for you is that a programming language really isn't difficult to pick up! What's more important is that you pick up how to design a program rather than a specific language. Spend time with the 6 major language paradigms:

  • Imperative programming (C) and class abstractions (C++, C#, Java)
  • Functional abstraction (Lisp, ML, F#)
  • Declarative specifications (C++ templates, Haskell, Prolog)
  • Syntactic abstraction (Lisp)
  • Parallelism (Cilk, SISAL, Clojure, Erlang)
  • Coroutines (C#, F#, Haskell, Scheme, Icon)

Quantitative trading often invokes concepts from these three core fields:

  • Algorithms, design patterns and data structures: B-trees, skip lists, memoization, DP etc.
  • Systems programming: Memory addressing, assembly, linking, heap/stack, cache etc.
  • Databases: Normalization, two phase commit, replication, mirroring, schema design etc.

And if you move closer to the quant developer end of the spectrum:

  • Distributed systems
  • Operating systems
  • Networks
$\endgroup$
5
$\begingroup$

Unfortunately, there is no correct answer for this question, it's like what car you should drive on your weekend.

C++ is a popular language in quantitative finance, but it's usually (but not always!) only used to build the application backbone, such as derivative pricing. Why C++? C++ is a good choice because C++ is platform independent, we can natively build an option pricing code for Linux, Mac, Windows etc. QuantLib is a good example.

C# is another very popular language in finance. We can use C# to create a trading application, parse XML data from another bank, create a web-server etc. Of course, we can also do derivative pricing in C# but we might not be able to optimise the performance. In C++, we could split the workloads with OpenMP, vectorise a Monte-Carlo loops etc etc, harder with C#.

C# is definitely not a better language than C++ in quantitative finance. It really depends on what you want to do. For example, nobody would use C# for HPC trading.

Not everybody in quantitative finance can do hard-core programming, most don't. Python (Excel VBL or R) would be a better language for them.

If you want to learn something for your first job, start off with C++. Try to understand QuantLib.

$\endgroup$
  • $\begingroup$ Here's my double questions because my question need also opinion about coding. Stackoverflow-Question What do you think about combining of C++ and Python/C#? C++ for algorithmic part and Python or C# for visual part (GUI)? $\endgroup$ – Speakard Jun 4 '15 at 8:09
  • $\begingroup$ I don't think you should even think about the language itself. If you understand the algorithm, you can already make lots of money. I don't. $\endgroup$ – SmallChess Jun 4 '15 at 8:47
  • $\begingroup$ @Speakard I am usually using Python to build a prototype, so much easier than C++. Once it done, time for a hard-core coding $\endgroup$ – Ulysses Jun 4 '15 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.