Why C++?

[Terryphi]

Hi There,

It seems that there seems to be a lot of discussion about C++ in the quant community. Why is that? Is there much use of more modern languages (C#, Python, etc..)?

 

[TehRaio]

dude do your homework, and look this us

 

[Daniel Duffy]

Hi There,

It seems that there seems to be a lot of discussion about C++ in the quant community. Why is that? Is there much use of more modern languages (C#, Python, etc..)?

Where have you seen these discussions?


BTW C++ is only 35 years old :D

 

[Sicong Li]

I use Python sometimes. In my opinion, understanding C++ helps me a lot to understand Python. I also heard some applications that require C++ since it's very powerful.

 

[ShowMeTheLight]

If all you are doing is run-of-the-mill serial algorithms (or even simple parallel algorithms), I don't think you need C++ these days. However, a lot of these companies have huge investments in legacy software, which probably explains their focus on maintaining C++. But I do see many quant job adds now asking for Python, R and Java. It probably depends on how old the firm is. Long term, I see C/C++ programmers becoming like the old COBOL coders who were suddenly hot during Y2K when all of the legacy banking code had to be updated. However, we are probably 10 or more years away from that day.

If you want to do real high performance computing, C or C++ is the best way to go. There is a great body of HPC libraries, dating back from the 70s (LAPACK, BLAS, MPI) and newer variants like MKL, CUDA libraries, PETSc. These are all either FORTRAN or have C wrappers.

If you use interpreted/byte code languages like Java, C#, Matlab or Python, sooner or later you bump up against the limitations. For instance, I've found Java has trouble when too many files are open (it doesn't close file handles rapidly) or with efficient memory management/garbage collection. When you get to the thousands of files and tens of GB level, these things start popping up.

That said, I think you could design a very effective byte code language for HPC. The main problem is that all of the decades of work was done in FORTRAN or C. I do wish organizations would scrap some of that or at least write good wrappers for modern languages. Its even hard to find C++ wrappers for most of this stuff.

 

[Daniel Duffy]

Long term, I see C/C++ programmers becoming like the old COBOL coders who were suddenly hot during Y2K when all of the legacy banking code had to be updated. However, we are probably 10 or more years away from that day.

Legacy code NEVER gets updated. C++ will be here for ever.

Python is the new Matlab, nice but not when you are in a storm.

I am thinking about GO in 10 years time.https://en.wikipedia.org/wiki/Go_(programming_language)
After that ..... cloud computing?

BTW I started life on FORTRAN IV (66) and COBOL :D

 

[alain]

Long term, I see C/C++ programmers becoming like the old COBOL coders who were suddenly hot during Y2K when all of the legacy banking code had to be updated. However, we are probably 10 or more years away from that day.

Legacy code NEVER gets updated. C++ will be here for ever.

Python is the new Matlab, nice but not when you are in a storm.

I am thinking about GO in 10 years time.https://en.wikipedia.org/wiki/Go_(programming_language)
After that ..... cloud computing?

BTW I started life on FORTRAN IV (66) and COBOL :D

Legacy code gets replaced. I don't know what you mean by "storm" by Python is here to stay and for the long haul. It's free. There are tons of libraries for it and it's very easy to learn, read and understand

FORTRAN is with us. I don't think FORTRAN is going to be replaced (at least not in the scientific community). I can't say the same about C++.

COBOL is still with us as well but it's being SLOWLY replaced.

 

[Daniel Duffy]

Legacy code gets replaced. I don't know what you mean by "storm" by Python is here to stay and for the long haul. It's free. There are tons of libraries for it and it's very easy to learn, read and understand

FORTRAN is with us. I don't think FORTRAN is going to be replaced (at least not in the scientific community). I can't say the same about C++.

COBOL is still with us as well but it's being SLOWLY replaced.

It depends on the organization I suppose. To take an example, I know one application (non-finance) that was written in VC++ 6.0 and it will never be replaced.

It means that someone has given a budget to upgrade legacy code? It does not happen by some random event and do developers actually enjoy the exercise?
If we take a C++ quant library that has been running for 20 years, are you going to port it to Python or C#?

My remarks about Python were anecdotal; the quant writes a POC in Python and then it is ported to C++. Is it fast enough?

In a sense, FORTRAN is more appropriate than C++ for number-crunching.

 

[Daniel Duffy]

Lots of languages are nice, useful et. etc. but C++ - for good or bad - is still the most professional one around. In many disciplines it is the standard and will remain so for years to come.

I do notice that C# is also popular. But it tilts when you want to do real things.

I don't normally (mis)quote Winston Churchill but I like this

“C++ is the worst form of government, except for all the others.”

 

[pingu]

Lots of languages are nice, useful et. etc. but C++ - for good or bad - is still the most professional one around. In many disciplines it is the standard and will remain so for years to come.

I do notice that C# is also popular. But it tilts when you want to do real things.

I don't normally (mis)quote Winston Churchill but I like this

“C++ is the worst form of government, except for all the others.”

I don't agree with you. C or Java or C# are the most professional around. C++ has too many issues and that's why people don't use it for new projects.

The new changes to the C++ standard came a little too late too.

 

[pingu]

It depends on the organization I suppose. To take an example, I know one application (non-finance) that was written in VC++ 6.0 and it will never be replaced.

It means that someone has given a budget to upgrade legacy code? It does not happen by some random event and do developers actually enjoy the exercise?
If we take a C++ quant library that has been running for 20 years, are you going to port it to Python or C#?

My remarks about Python were anecdotal; the quant writes a POC in Python and then it is ported to C++. Is it fast enough?

In a sense, FORTRAN is more appropriate than C++ for number-crunching.

the C++ quant libraries get wrapped in some other language so they stagnate. When it comes to porting, it all depends but C++ it's being left behind.

regarding proof of concepts, what I see is the POC get productionized by refactoring the python code and only dropping to compiled language for those pieces that need to be sped up and current python tools won't cut it. However usually C is the choice in python land.

On the other hand, if you use R to do the prototyping, then C++ is used by using RCpp which have a nice integration.

 

[Daniel Duffy]

I don't agree with you. C or Java or C# are the most professional around. C++ has too many issues and that's why people don't use it for new projects.

The new changes to the C++ standard came a little too late too.

There is no requirement to agree
I use C# a lot as well. It's nice. But it is less flexible than C++.

It would have ben better if C++11 arrived in 2005.

 

[Daniel Duffy]

the C++ quant libraries get wrapped in some other language so they stagnate. When it comes to porting, it all depends but C++ it's being left behind.

regarding proof of concepts, what I see is the POC get productionized by refactoring the python code and only dropping to compiled language for those pieces that need to be sped up and current python tools won't cut it. However usually C is the choice in python land.

On the other hand, if you use R to do the prototyping, then C++ is used by using RCpp which have a nice integration.

No silver bullet.
One can call C# from C++ using C++/CLI.

 

[Daniel Duffy]

I would say: if you like a language, use it; if you don't well just don't :D