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

Another perspective on programming languages concerns the following:

1. It is a one-man show or a multi-team effort.
2. How easy to maintain and extend the code base.
3. The half-life of the software product.
4. How easy to interoperate with existing libraries.
5. How easy to debug.

These questions are also relevant in the context of a Python environment.

There is no silver bullet. At some stage you hit a wall with all languages. It is a question or knowing where it is and how to slow down before hitting it.
C++ is bad overall at all of these points. For 2 and 5, C++ is one of the worst if not the worst of the mainstream languages.
 
C++ is bad overall at all of these points. For 2 and 5, C++ is one of the worst if not the worst of the mainstream languages.
Oops :)
Just out of curiosity, have you worked on (large) C++ projects?

Are the problems caused by the language or the way the developers 'use' the language? Can you quantify let's say the top [3,5] issues? and how does Python mitigate these shortcoming?
 
Last edited:
Oops :)
Just out of curiosity, have you worked on (large) C++ projects?

Are the problems caused by the language or the way the developers 'use' the language? Can you quantify let's say the top [3,5] issues? and how does Python mitigate these shortcoming?
I have and those projects were all IT related and a mess. We had to agree on what subset of C++ to use and not deviate of that subset to avoid problems.

Also, you can never separate the "language" from the way developers "use" the language.

You also seem really focused on Python as if it was your main competitor, which could be.
Python main advantage is that is very easy to read and understand. Also there is usually one obvious way of doing things and they become very clear with experience.

You should learn Python. The advantages will become obvious right away. There is only one thing that is bad about python. It's usually slow in comparison to compiled languages but there are workarounds.
 
We had to agree on what subset of C++ to use and not deviate of that subset to avoid problems.

Can you be more specific?

BTW I don't see Python as a competitor. It's just another language, like all languages.

You should learn Python. The advantages will become obvious right away.
Can I do maths. Would love to.

There is only one thing that is bad about python. It's usually slow in comparison to compiled languages but there are workarounds.
This is a show stopper for certain classes of applications, e.g. process-control, medical, derivatives book etc.
 
Last edited:
When I asked about customization, I was expecting you to use your particular expertise to filter down the possibilities and give some real examples. It's not helpful to point to a link.

Also, when "customization" is mentioned, I mean meta-programming facilities, such as classes that create classes. Things that have to be implemented via the compiler are not customizations.

You should learn Python. The advantages will become obvious right away.
Can I do maths. Would love to.

There is only one thing that is bad about python. It's usually slow in comparison to compiled languages but there are workarounds.
This is a show stopper for certain classes of applications, e.g. process-control, medical, derivatives book etc.
The workarounds are completely and utterly standard. Numpy + scipy + pandas are the must have library stack for math under Python, but they are great libraries, fast, good syntax, and very standard.

In fact, it's far more accurate to say that Python is bad at low-latency, but high throughput math can be and is frequently done.

Daniel, the annoyance here is that the more you write, the more apparent it is that you don't have experience with really powerful high level languages, the best of which combine high level concepts with exceptional (although not best in class) execution speeds. This has happened to me over and over, the other side doesn't have the experience so therefore isn't even equipped to have a meaningful discussion. It's the Blub paradox (Beating the Averages). The power difference between Python and C++ is easily on the order of 10x (in terms of what I've personally been able accomplish in one vs the other). The lines of code required to do an arbitrary task is easily 10x less, which directly translates into maintainability.
 
I have and those projects were all IT related and a mess. We had to agree on what subset of C++ to use and not deviate of that subset to avoid problems.

Also, you can never separate the "language" from the way developers "use" the language.

You also seem really focused on Python as if it was your main competitor, which could be.
Python main advantage is that is very easy to read and understand. Also there is usually one obvious way of doing things and they become very clear with experience.

You should learn Python. The advantages will become obvious right away. There is only one thing that is bad about python. It's usually slow in comparison to compiled languages but there are workarounds.
When I asked about customization, I was expecting you to use your particular expertise to filter down the possibilities and give some real examples. It's not helpful to point to a link.

Also, when "customization" is mentioned, I mean meta-programming facilities, such as classes that create classes. Things that have to be implemented via the compiler are not customizations.


The workarounds are completely and utterly standard. Numpy + scipy + pandas are the must have library stack for math under Python, but they are great libraries, fast, good syntax, and very standard.

In fact, it's far more accurate to say that Python is bad at low-latency, but high throughput math can be and is frequently done.

Daniel, the annoyance here is that the more you write, the more apparent it is that you don't have experience with really . This has happened to me over and over, the other side doesn't have the experience so therefore isn't even equipped to have a meaningful discussion. It's the Blub paradox (Beating the Averages). The power difference between Python and C++ is easily on the order of 10x (in terms of what I've personally been able accomplish in one vs the other). The lines of code required to do an arbitrary task is easily 10x less, which directly translates into maintainability.

Yike Lu,
LOL
Thank you for telling me (incorrectly) which languages I do know. I won't go into the languages I used since 1972 :) So, what has it that APL, Smalltalk, Fortran, COBOL, Prolog, Lisp, Objective C, C++11, C# and Haskell don't have. ;)

powerful high level languages, the best of which combine high level concepts with exceptional (although not best in class) execution speeds.

This means nothing.Can you be more specific? Do you mean the following features?

Python supports multiple programming paradigms, including object-oriented, imperative and functional programming or procedural styles. It features a dynamic type system and automatic memory management and has a large and comprehensive standard library.[28]

Many of these are shared by many languages, including C++11. C++17 will have even more features.
 
Last edited:
This discussion remind me of the discussion on C++ versus

Smalltalk
Objective-C
Eiffel
Java

in the 80s and 90s.

They're back.
 
Also, when "customization" is mentioned, I mean meta-programming facilities, such as classes that create classes.

Been there, done that in C#, for example. It's a marginal feature, nice to have.

Cool, but probably not type safe??

Most production developers don't use these techniques (for a number of reasons).

Sorry about that, but I don't see how it improves things all that much.
 
Last edited:
Python supports multiple programming paradigms, including object-oriented, imperative and functional programming or procedural styles. It features a dynamic type system and automatic memory management and has a large and comprehensive standard library.[28]

Many of these are shared by many languages, including C++11.
Ignoring other languages as it's not germane to the discussion. C++11 doesn't have dynamic types, nor automatic memory management. Smart pointers aren't automatic memory management (as attested by many segfaults that can still happen when they're used), and auto is not dynamic typing, it's static type inference. Are we even speaking the same language, have you bothered to make sure your definitions are right? And just so we're clear, so long as newer C++ has to inter-op with legacy C++ code, it will never have fully automatic memory management.

And to add, C++ classes are not first-class, the standard library doesn't have a string tokenizer (it's in Boost, it might make it in subsequent versions, which is years off), there is no package manager, no run-time interpreter.
 
Also, when "customization" is mentioned, I mean meta-programming facilities, such as classes that create classes.

Been there, done that in C#, for example. It's a marginal feature, nice to have.

Cool, but probably not type safe??

Most production developers don't use these techniques (for a number of reasons).

Sorry about that, but I don't see how it improves things all that much.
What exactly does customizing a language even mean to you then?
 
Ignoring other languages as it's not germane to the discussion. C++11 doesn't have dynamic types, nor automatic memory management. Smart pointers aren't automatic memory management (as attested by many segfaults that can still happen when they're used), and auto is not dynamic typing, it's static type inference. Are we even speaking the same language, have you bothered to make sure your definitions are right? And just so we're clear, so long as newer C++ has to inter-op with legacy C++ code, it will never have fully automatic memory management.

And to add, C++ classes are not first-class, the standard library doesn't have a string tokenizer (it's in Boost, it might make it in subsequent versions, which is years off), there is no package manager, no run-time interpreter.

One man's meat is another man's poison.

 
the standard library doesn't have a string tokenizer (it's in Boost, it might make it in subsequent versions, which is years off)

Yes it does in C++11, it is called <regex>, but not in C++98.

See the link I posted.
 
No, you brought it up originally, referencing how customizable C++ was. What does it mean to you?
In the sense that it can be extended by generic libraries. I am less interested in run-time reflection and such.
And it treats me like an adult. I like to take care of my own memory management. Garbage collection is meshuggah.

In summary, each to his own. At the end of the day.
 
Last edited:
And it treats me like an adult. I like to take care of my own memory management. Garbage collection is meshuggah.
Garbage collection is the future. it's here to stay. It seems you are stuck in the 80s when it comes to programming. C++ has libraries the implement GC. The reason GC is not part of the language has to do with the non-deterministic nature of the GC. There is a ton of legacy C++ code already written that can't take advantage of this.

From what I see, not a lot of new projects are being developed in C++ and that's the main issue going forward.

As, usual, we can bring Linus' opinion about C++ :)

Linus Torvalds on C++
 
This is a show stopper for certain classes of applications, e.g. process-control, medical, derivatives book etc.
All those applications can be developed in python + C/C++ since the speed they need is not really as critical as you think and that's what people are doing now. Write 80-90% of the code in a high level language and only re-rewrite pieces that are time critical in C/C++.
 
Garbage collection is the future. it's here to stay. It seems you are stuck in the 80s when it comes to programming. C++ has libraries the implement GC. The reason GC is not part of the language has to do with the non-deterministic nature of the GC. There is a ton of legacy C++ code already written that can't take advantage of this.

From what I see, not a lot of new projects are being developed in C++ and that's the main issue going forward.

As, usual, we can bring Linus' opinion about C++ :)

Linus Torvalds on C++

You should get out more.
 
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.
 
Back
Top