• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

MFE: To do or not to do?

I am in the Python/R camp, for reasons of inertia C++ skills will be still necessary/valuable in many settings, but I see more and more (not first hand, from snippets in the press) that at least the front office/research groups don't bother with it anymore and prototype with Python or another higher level language.
And C# is playing a similar role to some extent; however, production systems are being written in C#.

The C++ learning curve is steep; C# and Python are easier.
 
As, usual, we can bring Linus' opinion about C++ :)

Linus Torvalds on C++

His bark is worse than his bite, God love him.

He's been spouting the same bile for as long as I can remember.
 
Last edited:
In the sense that it can be extended by generic libraries. I am less interested in run-time reflection and such.
Well now we get to the heart of the matter. "Can be extended by generic libraries" -- does this not describe every modern language though?
 
Well now we get to the heart of the matter. "Can be extended by generic libraries" -- does this not describe every modern language though?

Not really. Unless you consider duck typing as achieving generic code.

I am referring to C# Generics and C++ Templates.
 
Not really. Unless you consider duck typing as achieving generic code.

I am referring to C# Generics and C++ Templates.
I don't see how duck typing / dynamic typing is worse in terms of "customization". It's weaker in safety and guarantees for the obvious reasons, but they provide better flexibility (which is our chosen metric here... though there be some disagreement).

And for the record, what I mean by customization is... the ability to monkey around with the language internals. You are right that those things are not used in the day-to-day course of business. However, when they are used, the alternative is usually pretty terrible. One cannot dismiss such features because the average programmer in the language doesn't use them; they are in fact not meant for the average programmer. They are meant for eg, debuggers, IDEs, etc, which has very far reaching consequences for the shape of the engineering that happens in a language.
 
At this stage, we are focusing on language features. The real issues are:

1. What is my application (pacemaker or research prototype,,,,) and its hard requirements?
2. What is the most suitable language for 1?
3. Do I have the programmers to do 1 with 2?

One cannot dismiss such features because the average programmer in the language doesn't use them; they are in fact not meant for the average programmer.
OK, we are talking about a very small subset of programming activity, for sure. Btw the word 'average' is meaningless. Meta programming is also standard, yes?

I am not talking _only_ about myself but the developers that are my clients. Each to his own, as I already mentioned. Silly language discussions..
 
Last edited:
I don't see how duck typing / dynamic typing is worse in terms of "customization". It's weaker in safety and guarantees for the obvious reasons, but they provide better flexibility (which is our chosen metric here... though there be some disagreement).

And for the record, what I mean by customization is... the ability to monkey around with the language internals. You are right that those things are not used in the day-to-day course of business. However, when they are used, the alternative is usually pretty terrible. One cannot dismiss such features because the average programmer in the language doesn't use them; they are in fact not meant for the average programmer. They are meant for eg, debuggers, IDEs, etc, which has very far reaching consequences for the shape of the engineering that happens in a language.
 
What I don't get is why a quant needs to get into the internals of a language. The goal is to develop financial models, not CS. Or am I missing something?

I know a lot of developers in several domains and hardly any of them (need to) use meta programming on a regular basis.

The simple question is: what is the compelling reason to want to use these advanced techniques instead of workarounds?
 
What I don't get is why a quant needs to get into the internals of a language. The goal is to develop financial models, not CS. Or am I missing something?

You are completely right. That's why there is no real reason for Quants to learn C++ nowadays.
 
You are completely right. That's why there is no real reason for Quants to learn C++ nowadays.
I'm not going to argue the merits of Python vs. C++ (though I do have strong opinions); I code in both on a daily basis and they both have their practical benefits and shortcomings.

However, to imply that Quants don't use C++ nowadays is false. The quants I work with definitely code in C++ (and not just legacy code). They use Python for the higher level work (i.e. the security representations and GUIs).
 
You are completely right. That's why there is no real reason for Quants to learn C++ nowadays.
Yawn. Nice try and a bit trite don't you think?

And now the to the rest of my post that you took out of context.

I know a lot of developers in several domains and hardly any of them (need to) use meta programming on a regular basis.

The simple question is: what is the compelling reason to want to use these advanced techniques instead of workarounds?
 
The simple question is: what is the compelling reason to want to use these advanced techniques instead of workarounds?
Once again, it's not for day2day dev work, but rather for something like an ORM layer, debugger, IDE, or when you need to add in a truly new feature and can't wait the (2011 - 1998 = 13) years for somebody else to put it in (think auto and anonymous functions).

A workaround by definition is not-ideal, usually sacrificing on maintainability. You are essentially building on a crooked foundation, even in the simple cases. When your core dev tools make these kinds of sacrifices, things just get ever more crooked.

The less work-arounds a language requires (or the more cleanly they can be hidden), the higher the heights to which it can rise.

For the general question of language internals, it's not really a binary question, but rather a continuum. I've found that a good rule of thumb is: the less CS/software engineering a quant knows, the more liable he is to make an utter mess of things, to the point where his project can become a veritable black-hole of man hours. I've experienced this multiple times, including cases where I've been the quant creating the black hole. Language choice is a always a huge factor. When I encounter such a quant, the first thing I do is burn the resume.

Like it or not, virtually all quant jobs involve producing software, so virtually all quants need to be good software engineers, lest they drown in their own filth.
 
I talked to a few people (N.B. I am the messenger, so they are not my words). What they say is Python/R in the data processing camp while C++ and C# are for derivatives' pricing. In particular, there seems to be growing interest in C# among hedge funds.
 
Last edited:
Like it or not, virtually all quant jobs involve producing software, so virtually all quants need to be good software engineers, lest they drown in their own filth.

I suspect this remark pertains to one-person projects with no 'interference' (for want of a better word) from other team members?

Life become less clear-cut when it is a multi-man, multi-year, multi-language project.
 
I suspect this remark pertains to one-person projects with no 'interference' (for want of a better word) from other team members?

Life become less clear-cut when it is a multi-man, multi-year, multi-language project.
Software engineering skills become even more important in that context, although you can lean on other people to help teach you.

Really the important thing when hiring is that the quant recognizes the importance of software engineering as core skill to be practiced and improved upon. The old school "learn as little as necessary to do the job" attitude is toxic to firms, though some are better positioned to absorb the toxicity.
 
Software engineering skills become even more important in that context, although you can lean on other people to help teach you.

Really the important thing when hiring is that the quant recognizes the importance of software engineering as core skill to be practiced and improved upon. The old school "learn as little as necessary to do the job" attitude is toxic to firms, though some are better positioned to absorb the toxicity.

Agree 100%, Yike.

I see history repeating itself; when engineering(oil, gas, semiconductors) was the future in the West newly-minted mathematicians would work on products and they had to become competent in Fortran and C post haste.
 
Last edited:
Hi All,

I have graduated in 2014 from one of the top university(Acceptance rate<2%) from India and currently working at operational role.But I am interested in making my career in finance.I have registered for CFA level 1 exam in Dec 2016.I have decent knowledge of C++and R.
What are chances that I will get admitted to top ten university of US for MFin programme ?
 
Back to languages..

We have been discussing the relative merits of C++ and Python. But the kind of stuff going on I think that they are less flexible than the functional programming languages Haskell and F#.

And mathematics is all about functions A-Z, yes?
 
I wouldn't use the word "flexible".

I think the functional style and the extra math does make functional languages more rigorous, but it removes some flexibility.

It's always a tradeoff. Flexibility vs strong guarantees. Python to me represents the higher flexibility end of the continuum. C++ should represent the stronger guarantees side, but there are some notable gaps (memory management / leaks).

The functional languages have found a pretty good middle ground that ceteris paribus should be better. Type inference is strictly better than old C++ style static typing, and mostly better than duck typing.

However, Haskell focuses a bit too much on math/lazy eval/purity, which makes it difficult to program in. Monads... yeah... monads. And generally speaking, library / tool support isn't nearly as strong.
 
Back
Top