My new book, Practical C++ Financial Programming, has just been released by Apress: http://amzn.to/1C8ekwg.
Practical C++ Financial Programming is a hands-on book for programmers wanting to apply C++ to programming problems in the financial industry. The book explains those aspects of the language that are more frequently used in writing financial software, including the STL, templates, and various numerical libraries. The book also describes many of the important problems in financial engineering that are part of the day-to-day work of financial programmers in large investment banks and hedge funds.

Focus is on providing working solutions for common programming problems. Examples are plentiful and provide value in the form of ready-to-use solutions that you can immediately apply in your day-to-day work. You’ll learn to design efficient, numerical classes for use in finance, as well as to use those classes provided by Boost and other libraries. You’ll see examples of matrix manipulations, curve fitting, histogram generation, numerical integration, and differential equation analysis, and you’ll learn how all these techniques can be applied to some of the most common areas of financial software development. These areas include performance price forecasting, optimizing investment portfolios, and more. The book style is quick and to-the-point, delivering a refreshing view of what one needs to master in order to thrive as a C++ programmer in the financial industry.

• Covers aspects of C++ especially relevant to financial programming.
• Provides working solutions to commonly-encountered problems in finance.
• Delivers in a refreshing and easy style with a strong focus on the practical.

What you’ll learn

• Understand the fundamental problem types in the financial market.
• Design algorithms to solve financial programming problems.
• Extend C++ through Python extensions and LUA modules.
• Employ third-party numeric libraries such as those from Boost.
• Properly engage key C++ features such as templates and exception handling.
• Benefit from new features in C++14, such as auto variables and closures.

Who this book is for

Practical C++ Financial Programming is for professionals or advanced students who have interest in learning C++ financial programming, especially in preparation for a professional career. Readers should have a working-knowledge of programming in C, C++, or some other C-like language. The book is also useful to current practitioners at financial institutions as a ready-reference to common development problems and techniques.

Table of Contents

1. The Fixed-Income Market
2. The Equities Market
3. C++ Programming Techniques in Finance
4. Common Libraries for Financial Code
5. Designing Numerical Classes
6. Plotting Financial Data
7. Linear Algebra
8. Interpolation
9. Calculating Roots of Equations
10. Numerical Integration
11. Solving Partial Differential Equations
12. Algorithm Optimization
13. Portfolio Optimization
14. Monte Carlo Methods for Equity markets
15. Extending Financial Libraries
16. C++ with R and Octave
17. Multithreading
18. Appendix A: C++14 Features

Source Code

You can also access source code for the book using its git repository.

Here is a link to the source code for the book Objective-C Programmer’s Reference, published by Apress.

All the explanation about how this code works is contained in the book.

While Java is a very practical language, used nowadays to implement a large array of software applications, it also has its own share of problems. I am not the first and won’t be the last person to touch on the many issues raised by its design, especially in the areas of syntax and support for non-OO concepts.

While design problems are an interesting issue for technical discussion (especially if you are a programming aficionado), it is clearly not the main reason why someone would decide to use a language or not. Mostly, you have to answer pragmatic considerations such as “do you know how to use the language well?” and “does the language provide support for the type of problems I want to solve?”

Despite this, here I will consider only two of the design problems in Java that I haven’t seen discussed in other places.

Safety versus Performance

The first problem is related to the security focus of the language. As Java was initially sold as the language of the Internet, the fact that it was designed for safety looks like a very important issue. After all, nobody wants to download and install software that is unsafe and untrusted.

The mistake of Java, however, is that it tries to achieve safety at the level of byte-code execution, thinking that this is the most important aspect of security – or at least so important that it would be able to fix most of the security issues we might encounter in a networked world. For example, every time you load a Java class (or set of classes), the runtime mechanism has to spend a good amount of time trying to determine if the code is safe or not.

Security checks at the byte-code level take time and effort from the part of the runtime system. The big problem with this, however, is that only a small fraction of all code written in Java really needs the security checks that are in place. For example, even if you’re writing code that will never be in contact with the Internet, you still need to pay the price for this heightened level of security when using the Java runtime. The unintended consequence of such decisions is that the security system exists mostly to slow down the execution of programs, while complicating the class loading process.

Moreover, it is now understood that security at the programming language level is of very little importance for the safety of the overall system. If a malicious programmer wants to do something bad through a downloaded application, there are thousands of avenues that can be pursued, for example, by just getting enough information directly from the user. In most cases this can be done without even having to bother executing unsafe code.

That is why modern mobile applications are digitally signed: to make sure you know its origin. Trust, in the digital world as everywhere else, comes from knowing who created the code. It is part of a reputation system, not simply result of the analysis of the code itself. Moreover, with all the security measures imagined by its designers, Java turned out to become a big vector of malware infection. So much for the supposed safety offered by the language.

Over-Engineering the JVM

Another important innovation of Java is that it made the JVM, its virtual machine, the center of attentions. Unlike other languages that consider the description of the virtual machine simply as a detail that is hidden from users, Java decided to make it a public requirement for implementers, in order to guarantee the compatibility of code written at the JVM level and provide the Java-compatible seal.

While there are interesting advantages in using a well-defined set of operations interpreted by a virtual machine (for example, the ability to transfer compiled code over different architectures), the end result of this type of low-level focus is to bring unnecessary attention to specific areas, in detriment to the overall needs of the language. Java is nowadays certainly paying the price for these early decisions.

In a new language, the syntax and runtime system should be the main focus – not the virtual machine where the programs are executed. Case in point: the implementation of Javascript is constantly improving, with a performance that nowadays approaches (and sometimes exceeds) that of Java, at least for some application areas. The main reason is that designers of Javascript engines have fewer limitations on what they can do. In particular, they can improve the intermediate code as the execution engine matures and new approaches for optimization are necessary.

The same has been true for other interpreted languages, such as Smalltalk. But this natural evolution of the op-codes and other internal representations of compiled code cannot be easily achieved in Java, because the definition of the JVM over-specifies its execution mechanism. For example, it determines the exact representation of the compiled byte-codes. Therefore, even if a better way of representing and executing Java programs becomes available, it cannot be used by compliant virtual machines.

These are issues that may be seen as easy to overcome, but that in fact permeate the way the language is approached by users and implementers. Avoiding this is not possible for Java anymore, and programmers have to learn to live with the limitations of these early decisions, or look for better ways to express themselves. Either way, it is important to learn from past problems and avoid repeating them. Newer languages such as Javascript seem to have used a few of these lessons.

About the Author

Carlos Oliveira is a software engineer and the author of Objective-C Programmers Reference.

Related Books

Here are some other books on this topic:

The Pragmatic Programmer: From Journeyman to Master