MFE: To do or not to do?

[Daniel Duffy]

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.

 

[Daniel Duffy]

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.

 

[Yike Lu]

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?

 

[Daniel Duffy]

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.

 

[Yike Lu]

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.

 

[Daniel Duffy]

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..

 

[Daniel Duffy]

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.

 

[Daniel Duffy]

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?

 

[pingu]

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.

 

[APalley]

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).

 

[Daniel Duffy]

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?

 

[Yike Lu]

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.

 

[Daniel Duffy]

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.

 

[Daniel Duffy]

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.

 

[Yike Lu]

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.

 

[Daniel Duffy]

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.

 

[kunalkumargur]

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 ?

 

[Daniel Duffy]

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?

 

[Yike Lu]

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.

 

[ExSan]

I would like to rescue this

...
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).