Hi,I was reading Daniel Duffy's book "Introduction to C++ for Financial Engineers". In the First chapter, I came across the following comments from the author.QuoteC++ has become very popular in Quantitative Finance and its importance will grow rather than diminish in the coming years (in my humble opinion). EndQuoteI was wondering if this is really true. My understanding was that the demand of C++ is mainly due to a huge numebrs legacy applications already written in it. New applications are being written in Java or C#. So, it's usage will slowly diminish as it gets gradually replaced by other language like Java & C#. Of course this will take its time. But, I can't see how C++'s importance will grow in the coming years.Welcome comments from others who are somehow related or interested in the IT trends in the Finance industry.Regards,Victor123

QuoteDuffy: C++ has become very popular in Quantitative Finance and its importance will grow rather than diminish in the coming years (in my humble opinion). QuoteI was wondering if this is really trueOf course it's true, I wrote it (just kidding)Seriously, if you wish to pursue this discussion I will try to give the reasons why I think this is so...BTW you write a legacy system as soon as the first successful demo is given to the customer. In the 90's C++ programmmers had no idea that they were building legacy system for the future, really.It would be interesting to hear what the Wilmott C++ developers think of the future. It's so hard to predict.

C# will change with time because it is owned by Microsoft,and if Microsoft decides to change it, then it will change.They may even decide one day to discontinue the product.However, C++ will not change because it is open-sourceand owned by all the people who worked on it openly.So in my opinion C++ will never die and C# might quitepossibly die.However, I really like C# and use it at work with mycolleagues. Because it is so damn easy to use comparedto other languages. One can focus on ideas and thenjust code them; not having to worry about how to dothe coding, or worrying about shit like garbage collection.My heart is with C++ though I don't have the timeto learn it for now, but one day I hopefully will. For thesake of being a cool coder.

May be Azul Systems JVM will replace C++ one day.

QuoteOriginally posted by: ananihdvMay be Azul Systems JVM will replace C++ one day.In the 90's it was claimed that Java would replace C++. There was a lot of hype, too, especially all the new hardware. For the applications mentioned in the above product announcement, I do not think C++ is the appropriate language. Are we comparing apples and oranges?

QuoteOriginally posted by: Y0daC# will change with time because it is owned by Microsoft,and if Microsoft decides to change it, then it will change.They may even decide one day to discontinue the product.However, C++ will not change because it is open-sourceand owned by all the people who worked on it openly.So in my opinion C++ will never die and C# might quitepossibly die.However, I really like C# and use it at work with mycolleagues. Because it is so damn easy to use comparedto other languages. One can focus on ideas and thenjust code them; not having to worry about how to dothe coding, or worrying about shit like garbage collection.My heart is with C++ though I don't have the timeto learn it for now, but one day I hopefully will. For thesake of being a cool coder.Isn't the whole point of garbage collection that you don't have to worry about it?Maybe I've missed the point.

QuoteOriginally posted by: Y0daHowever, I really like C# and use it at work with mycolleagues. Because it is so damn easy to use comparedto other languages. One can focus on ideas and thenjust code them; not having to worry about how to dothe coding, or worrying about shit like garbage collection.This is why I would fear for the future of C++. To the extent that a language increases programmer productivity by hiding administrative details (e.g. garbage collection) is the extent that that language will become favored for a broad class of development projects. Language choice, in this regard, depends on which types of software are more sensitive to programmer productivity and latency versus CPU productivity and latency. Software that needs to maximize execution speed and minimize latency (e.g., algo trading and core operating system code) will always depend on languages that aren't too far from the silicon. Software that needs to minimize programmer labor and latency (=time-to-first-version) will move toward higher-generation languages (what DCFC calls quiche languages).The other unknown issue is how the rise of multicore computing will affect language choice. Will there be new or modified languages, IDEs, and compliers that naturally help the programmer create parallel code for multiple cores? To the extent that the development environment can guide/make smart choices about hosting or partitioning an application on variable numbers of cores is the extent that programmers will be able to do HPC without knowing much about HPC.

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: Y0daHowever, I really like C# and use it at work with mycolleagues. Because it is so damn easy to use comparedto other languages. One can focus on ideas and thenjust code them; not having to worry about how to dothe coding, or worrying about shit like garbage collection.This is why I would fear for the future of C++. To the extent that a language increases programmer productivity by hiding administrative details (e.g. garbage collection) is the extent that that language will become favored for a broad class of development projects..I disagree. Memory management is not administration, it is an essential developer activity. For some applications, we cannot leave garbage collection to the compiler (because it is too unpredictable) and the developer _must_ have explicit control over memory.QuoteThe other unknown issue is how the rise of multicore computing will affect language choice. Will there be new or modified languages, IDEs, and compliers that naturally help the programmer create parallel code for multiple cores? I think it will push C++ even more to the forefront (OpenMP, MPI). Of course, C# and Java will probably remain popular.QuoteTo the extent that the development environment can guide/make smart choices about hosting or partitioning an application on variable numbers of cores is the extent that programmers will be able to do HPC without knowing much about HPC. It would be nice, but I do not see it happening soon. It's just too difficult at the moment.QuoteIsn't the whole point of garbage collection that you don't have to worry about it?Of course, but as long as the developer is in control!In C++, memory mgt. woes can be allievated a bit with1. Good design, Builder and Object Pool patterns2. Boost shared pointers

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: Y0daThe other unknown issue is how the rise of multicore computing will affect language choice. Will there be new or modified languages, IDEs, and compliers that naturally help the programmer create parallel code for multiple cores? Take a look at Experimental concurrent programmng language

QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: Y0daThe other unknown issue is how the rise of multicore computing will affect language choice. Will there be new or modified languages, IDEs, and compliers that naturally help the programmer create parallel code for multiple cores? Take a look at Experimental concurrent programmng language

YAEL == yet another experimental language. Anyone remember Taligent, San Francisco, ... projects? That's why business managers wish to save investments in software. What to do when the plug is pulled on these products?

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: Traden4AlphaThis is why I would fear for the future of C++. To the extent that a language increases programmer productivity by hiding administrative details (e.g. garbage collection) is the extent that that language will become favored for a broad class of development projects..I disagree. Memory management is not administration, it is an essential developer activity. For some applications, we cannot leave garbage collection to the compiler (because it is too unpredictable) and the developer _must_ have explicit control over memory.I agree that some applications need developer-managed memory control. But what percentage?QuoteQuoteThe other unknown issue is how the rise of multicore computing will affect language choice. Will there be new or modified languages, IDEs, and compliers that naturally help the programmer create parallel code for multiple cores? I think it will push C++ even more to the forefront (OpenMP, MPI). Of course, C# and Java will probably remain popular.I can't help but feel that OpenMP and MPI are just bolt-on patches. Moreover, they force the designer to decide between shared memory vs. messaging-passing approaches to parallelism. I can't help but think that the true solution will be embedded in the language and compiler, rather than through add-on API library.QuoteQuoteTo the extent that the development environment can guide/make smart choices about hosting or partitioning an application on variable numbers of cores is the extent that programmers will be able to do HPC without knowing much about HPC. It would be nice, but I do not see it happening soon. It's just too difficult at the moment.Perhaps it is hard, but the language development group that solves it first will see their popularity rise. There was a time when a JIT compiler was too hard. Maybe the next frontier is JIT parallelism that uses a language and compiler that automatically handles the scaling of problems to multiple cores using a language or IDE that helps developers create easily parallelized code.

QuoteI agree that some applications need developer-managed memory control. But what percentage?Somewhere in the range [10, 20] feels right. What I see with many C++ code is that 'new' is all over the place, and this is a design error IMHO.CounterExample: a SensorUnit consisting of Sensors is responsible for 1) managing data from its sensor feeds and 2) initialising the sensors.Introducing 2) will be a maintenance fiasco. SensorUnit violates SRPUsing 2) will be a memory nightmare. We kanniet blame C++ for this

QuoteOriginally posted by: victor123 My understanding was that the demand of C++ is mainly due to a huge numebrs legacy applications already written in it. New applications are being written in Java or C#. So, it's usage will slowly diminish as it gets gradually replaced by other language like Java & C#. Of course this will take its time. But, I can't see how C++'s importance will grow in the coming years.If you measure the popularity of a language by the demand for training, then C# is the most popular language today. I remember taking C++ courses from developmentor when C++ was a popular language. Today if you check their training schedule there is no demand for C++(even for those offered by Scott Meyers). Also, magazines like C++ Report are not being published anymore(not even online) because there are no authors who can write decent articles and nobody to read those magazines.

QuoteIf you measure the popularity of a language by the demand for training, then C# is the most popular language todayCan you quantify this?For the record, our company gives C# and C++ courses, to finance people and various kinds of application engineers. Both are popular. I find that C++ developers can adapt to C# very quickly. We also have 'experimental data' on what is and what is not popular...QuoteAlso, magazines like C++ Report are not being published anymore(not even online) because there are no authors who can write decent articles and nobody to read those magazines. This is old news and somewhat of a non-sequitor. SIGS - the publisher of C++ report and other - ceased to exist end 90's. I was an author for SIGS (Analysis Journal, see link) so I have some experience with this publisher. End 90's was just before the dotcom crash, so a lot of things happened around that time. After that, people moved on.So, C++ Report's demise could be caused by factors other than just waning interest in C++? Google... http://www.amazon.com/Wisdom-Gurus-Sigs ... 0134998499