Im just about to begin the programming aspect of my education towards being a Quant. I know what languages are currently being used and how popular they are. However, I have several good friends getting their masters in computer science and related engineering degrees who tell me that C++ and similar languages are surely outdated for what Quants do.

Now despite that the work builds on itself and thus a need for C++ and similar languages are currently needed, do you see a change in the languages being used over the next 10 years? If so, what expected languages do you anticipate will be used?

P.s. I know this is a bit more discussion based than Stackexchange normally deals with. However, I am polling from multiple sites with the hope of being able to write on this topic to provide help to those in the future (as there is almost nothing on the web on this topic). Further, as the number of active quant sites is limited, to acquire a large enough data set to be useful, Stackexchange was a great resource to use. - Sorry for any inconvenience.

  • $\begingroup$ Relevant: quant.stackexchange.com/questions/306/… $\endgroup$
    – John
    Feb 27, 2015 at 18:35
  • $\begingroup$ Thanks John. I had already found that article and it helps show the current set up. Absolutely relevant, however I am more curious if people think quant programming will remain withen theses languages, C++, C#, Java, ect.. or change to some other language which is easier or more specific to a quants need. Cheers and thanks for the response. $\endgroup$
    – Sean Holt
    Feb 27, 2015 at 23:53
  • 2
    $\begingroup$ My sense is that what you're more concerned with what language to learn than the actual future for quant programming languages. The popular languages won't change enough over 10 years to worry about it. Regardless, if you learn a popular language, e.g. C, then you'll pick up the skills necessary to learn other languages if you need them. Moreover, you don't have to re-invent the wheel. C++ may have a bloated syntax, but it's fast and there's a library for everything. Or learn python, it's slow, but the syntax is great and there's a library for everything. $\endgroup$
    – John
    Feb 28, 2015 at 1:50
  • 1
    $\begingroup$ The answer is simple, learn and use what your employer pays you to use. Having a solid understanding of the fundamentals that you can take with you across languages is more important. $\endgroup$
    – pyCthon
    Apr 20, 2015 at 17:40
  • $\begingroup$ I would say it's actually very useful to know lots of different languages, as various constructs tend to be more common in some languages and less in others - and knowing these various constructs is often very useful. $\endgroup$
    – will
    Jun 15, 2019 at 11:35

2 Answers 2


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

You're going to get a pretty broad range of answers with this kind of question, but I'll throw in my two cents. I'm not going to answer your question about the "next big thing" in programming languages, because that's just an opinion survey. Instead, I'm going to describe to you the characteristics of a few popular (and mature and well-supported/documented) languages, so you can pick one for your needs. All of these languages have been around for at least 10 years, so it shows that they have stood the test of time. Let's break down a quant's programming needs into different segments: research, and production.

When conducting research (eg, backtesting a strategy) many people (myself included) prefer to use a high-level interpreted language in order to reduce the number of lines of code between an idea and test results. This is because, although these languages are often much slower than their compiled counterparts, programmer time is much more valuable than execution time at this stage of the game. It is worth bearing in mind, however, that a lot of research is going into making these languages faster, because they're so easy to use! These languages allow you to make small changes, fix bugs, and visualize results in far fewer lines of code than languages like C/C++/Java. They are almost always supported by (and bundled with) a wide variety of domain-specific libraries that extend the functionality of the language.

Some of the most popular research languages are Matlab, Python (with numpy), and R. Someone who has never programmed in their lives can pick up the basics of these languages and write some simple code in less than a day. A free alternative to Matlab is Octave, if you don't want to shell out for the commercial package. If you choose Octave, though, you should be aware that it is just about the slowest scientific computing language available. One language to keep an eye on in the future is a language called Julia. This is an interpreted (ish) language that is designed in such a way as to achieve C-like performance on a wide variety of numerical computing tasks. (There are lots of good papers out there if you're curious about how they do it.) It's a very young language that is rapidly changing (and breaking backward-compatibility), so it might be best to wait for it to mature a bit more before investing time/resources learning it.

For production code, you choose a language based on the demands of your application. If you're trying to do HFT and run it from an interpreted language, you're gonna have a bad time. Interpreted languages are simply not fast enough (yet!) to compete with compiled languages. If you're looking for pure performance, you're not going to beat C or C++ (Fortran excluded from this discussion because I'm really not a fan, and would never encourage anyone to use it). These languages afford the programmer very fine-grained control over every aspect of the program execution, but if you don't want the control, you have to deal with it anyway. If you're not writing assembly, C is about as "close to the metal" as you can get.

The first step backward from the C/C++ family will bring you to Java and C#. The big feature that you'll notice here is "Garbage Collection." If you don't know what this is, don't worry about the details, but it saves you from having to manage your program's memory consumption manually. Since the no-free-lunch idea should be familiar to readers of this site, you might guess that this incurs a performance cost, which can be crippling if you rely on a real-time system. The garbage collector feels a bit like a hiccup in the middle of an otherwise smooth execution. In most applications, you aren't going to notice it. There's a reason that fighter-jet avionics aren't written in Java, and this is it. If you feel that your system needs the same level of real-time control as an airplane, don't pick Garbage Collected languages.

From here, you start getting away from languages that people currently seem to use for quantitative programming. I will make a case for one last one that is very important, if not for model execution. Bash/shell scripts. If you're on a *nix system, you absolutely need to be familiar with these to automate system maintenance tasks.

  • $\begingroup$ Could you please elaborate more on "Garbage Collected languages"? $\endgroup$
    – Ascorpio
    Oct 6, 2015 at 18:33
  • $\begingroup$ This isn't really an appropriate place to teach what Garbage Collection is. I encourage you to Google it and read about it. $\endgroup$ Oct 6, 2015 at 18:36

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