• 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!

which is more useful in the real world? Python or C++...

which is more useful? Python or C++

  • Python

  • C++


Results are only viewable after voting.
Not all MSc students know C++, so to learn PDE/FDM Python is fine. For production, C++ is the only choice.
The two sweeps of the ADE scheme are:

[CODE title="ADE"]
for i in range(1, len(self.u) - 1):
x = self.u[i - 1]
y = self.uold
z = self.uold[i + 1]

self.u = (self.up1(z - x) + self.up2 y + self.up3*(x - y + z)) / self.up4

for i in reversed(range(1, len(self.v) - 1)):
y = self.vold
x = self.vold[i - 1]
z = self.v[i + 1]

self.v = (self.down1 * (z - x) + self.down2y + self.down3(z - y + x)) / self.down4[/CODE]
 
If history is anything to go on, at some stage we will encounter the same software maintenance problems with ML applications as with 99.99% of legacy code. The root cause is not the choice of language but the fact that these applications are created by non-programmers who are in all probability not familiar with software design (making blueprints before you jump into code). It is an accident waiting to happen..

Don't take my word for it; hear what Google has to say.



Good, forthright interview! Anyone who has read Brooks' "Mythical Man Month" will know that one of the biggest challenges in software projects is maintainability and eventually products become a big ball of mud. This is an ubiquitous problem since many years and it is caused by well-known problems such as bottom-up work practices, programming from the start blocks (no design) and not defining component interfaces up-front. It is one of the unfortunate OOP legacies. This issue is acknowledged and discussed following @41.30
 
Last edited:
Last edited:
People tend to compare languages based on many kinds of metrics, e.g. cute features, easy to use, functionality etc.

A possible bad scenario is Python code becoming unmaintainable because those writing the software (for example, applied mathematicians) have had no exposure to design principles of Design Patterns.

C++ v Python? the latter is (much) more difficult to maintain. And there's an associated price tag.

Corollary: discussions on software maintainability tend to fall on deaf ears.
 
Last edited:
People tend to compare languages based on many kinds of metrics, e.g. cute features, easy to use, functionality etc.

A possible bad scenario is Python code becoming unmaintainable because those writing the software (for example, applied mathematicians) have had no exposure to design principles of Design Patterns.

C++ v Python? the latter is (much) more difficult to maintain. And there's an associated price tag.

Corollary: discussions on software maintainability tend to fall on deaf ears.
On the other hand, I have seen (many) professional quants who wrote memory issue codes in C++.. use const_cast in order to make things easier for themselves.. forgot to initialize variable in constructor.. no concept of modulization so very long body of function or even worse copy paste code everywhere.. assign auto_ptr which causes the object to be destroyed(luckily we have unique_ptr now in C++ 11...)

Then it sometimes makes me wonder that at least they will not make this mistake in a dumber language. Many quants I have worked with do not have the concept of “stability” coding. You would be lucky if they simply don’t write memory issue code, let alone all these strategy pattern type of stuff... in reality, if you fortunately meet one who can write scallable and stable code, he/she is a super star...
 
@Daniel Duffy what can we do as quants to get on the path of righteousness, short of CS studies?

The problems you mention seem like problems because I think you are credible, but I can’t say I understand them.

How much of the theory do we need? Where is the line?

I don’t want to be part of the problem.
 
I minored in CS, didn’t learn any of that stuff. I think those are things you learn on the job.
This is quite anecdotal.


//
CS education tends to focus on theoretical things (can be useful) and less on software engineering/programming.
CS does not mean you can create maintainable software.

And you may or may not learn good software practice on the job. It depends.
 
Last edited:
@Daniel Duffy what can we do as quants to get on the path of righteousness, short of CS studies?

The problems you mention seem like problems because I think you are credible, but I can’t say I understand them.

How much of the theory do we need? Where is the line?

I don’t want to be part of the problem.
There are many scenarios. One is that the originator of undocumented and unstructured code has moved on and someone has to maintain it.

Anonymous but real quote from the trenches...

"The usual suspect: obviously clever applied mathematician, but otherwise completely untrained as software developer “writes a script to do thing X”. As soon as this newly-born wonder has passed some tests (meaning that the program does not crash anymore) and taken into production, previously observed insignificant symptoms will be escalating over time into serious signs of deadly plague (runtime issues, maintainability issues, you name it).

People, who are usually so proudly describing themselves as “Applied Mathematician” are almost surely building some type of time bombs with their scripts, because they (usually, but there are exceptions) have no interest on software design issues on any level."

I also have a zillion examples from my own past.
 
Last edited:
I like this one

“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.”
 
There are many scenarios. One is that the originator of undocumented and unstructured code has moved on and someone has to maintain it.

Anonymous but real quote from the trenches...

"The usual suspect: obviously clever applied mathematician, but otherwise completely untrained as software developer “writes a script to do thing X”. As soon as this newly-born wonder has passed some tests (meaning that the program does not crash anymore) and taken into production, previously observed insignificant symptoms will be escalating over time into serious signs of deadly plague (runtime issues, maintainability issues, you name it).

People, who are usually so proudly describing themselves as “Applied Mathematician” are almost surely building some type of time bombs with their scripts, because they (usually, but there are exceptions) have no interest on software design issues on any level."

I also have a zillion examples from my own past.

LMAO, your comment just made my day... I have seen this everyday at my work.. even worse, there are idiots failing the regression tests but since such model feature is not used in production, they would sneakily remove the test case.

Speaking of which, this works both way when you have a pure software engineer working in the model library but completely lack of understanding of the theory.. this folks simply blindly re-uses existing code and able to spit out some numbers and then that's it...

A good Quant should be all around (yet I know this is unreasonable sometimes) but it is true.. Programming + Math are required. Lacking either one won't work...

P.S.: that is why you see so many fake quants nowadays...
 
Last edited:
The following has to be said is the arrogance of some applied mathematicians who think software design is easy (FYI I am a mathematician, 1st program written in 1971).

Analogy: I know judokas who are USELESS in karate and ju-jutsu.

“A little learning is a dangerous thing.
Drink deep, or taste not the Pierian Spring;
There shallow draughts intoxicate the brain,
and drinking largely sobers us again.”
― Alexander Pope, An Essay on Criticism


And I am being deadly serious!
 
How about Julia, the future king of machine learning? I didn't see no one mention it.
It's just another language.
Other recent languages on the catwalk are Swift, Go, Rust, etc. etc. They rise and fall.

BTW, Julia is #44 in the TIOBE index.

The essential difficulty is avoiding big balls of software mud. Quiche languages won't help in this regard IMHO.


The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.
Fred Brooks
 
Last edited:
On a somewhat related comparison, I ported C++ code to price financial derivatives (options) to Python to get a feeling for relative run-time performance., This is essentially a one-step algorithm in a double nested 'for' loop and random number generators are used in both cases (Mersenne Twister 19937)
Conclusion C++ is 60 times faster!

Just looking at the random number generator part, using Numba improves performance appreciably (Python is 1 1/2 times slower). In more complicated code it is not obvious how to use numba. In this case 'pure' Python would not be suitable for production purposes but it would be useful for prototyping.
 
Back
Top