Choosing The “Right” Hammer To Hit the Nail (aka the “right” programming language)

Setting the Scene

Last summer I worked as a software developer in a large firm that provided financial market data and services to clients worldwide.  The delivery of financial news and market data from exchanges is highly time-sensitive, approaching real-time. Hence their system was heavily optimised for performance with the back end primarily developed in C++. I was tasked with prototyping a survey tool for this platform. The required back end libraries for this tool were available in both Python and C++. However I was advised against developing the back end in Python to ensure consistency with the rest of the applications maintained by the team. Additionally, I was told that the Python libraries were essentially a wrapper around the C++ code so should use C++ for efficiency. I was neither experienced in C++, Python or large scale system development and of course I went along with it and used C++.

This got me thinking about the using the right development language for the task, if and when the choice was available. This blog post will discuss this with respect to the case I have outlined above.

Please note that this is not a discussion about whether Python is a better programming language than C++, or vice-versa. This post aims to highlight problems when choosing the “right” programming language with respect to the case outlined above.

Development Issues: C++ vs. Python

As a beginner to both the internal framework and C++  the development of the back end was a slow, arduous process. Python is definitely an easier language to write than C++ as it is more intuitive and it doesn’t require as much boilerplate code as C++.This meant that methods which could be written in five lines in Python instead took around twenty lines in C++ (not always the case).

I felt that using C++ for this led to more errors in my code and also a slower debugging rate. Of course I am not stating that more lines of code lead to more bugs. However given that the methods implemented in C++ were far longer than their Python equivalent and this combined with the complex system infrastructure to compile and test files made finding errors and testing a time consuming process. I felt that in this particular case, the use of Python, a more concise language than C++ would have made it easier to read code and find errors.

The sheer amount of boilerplate code required by the internal  C++  libraries also making changes a time consuming process.  This in turn made iterative development a slow process. I felt that in this case Python would have been better suited to this particular task.

With regards to performance, the Python libraries were also optimised. However they were not suitable for performance critical application development for this system because they compiled down to C++. Hence any applications dealing with larger volumes of data would be slower if developed in Python on this particular system. However my application was non performance critical so using Python would not have led to the application running noticeably slower.

In the end, I was able to deliver the prototype on time and got experience in coding in a language I had previously never used. However the slower development time, by using C++, meant that I didn’t have a great deal of time to implement all the features planned out at the start or refine the application with the feedback received from the demonstration. Due to this I felt that Python was better suited for the purposes of rapid prototyping as opposed to C++. Especially due to that fact that the back end was not performing complex tasks and was just storing and retrieving information from the database. Hence Python would have been more effective in terms of ease of use, readability of code and would have allowed me to develop and present a more complete solution.

The Other Side

I can understand why my team lead advised me against the using Python in this case. Their main concern was maintenance. The back end development across all their applications was carried out in C++ and had I developed the back end of the application in Python and left after eleven weeks. However it would be up to the team to maintain it. Hence maintenance may have taken longer due to unfamiliarity with the library being used.

Additionally, the team I worked in was quite small with only four developers who had started supporting more internal applications. Given this, there is a case to be made for the team not wanting to maintain and switch between applications developed in different languages and using various libraries. This does not make them less capable or inflexible but there are standards and procedures in software development for a particular reason – to help make the process more efficient. Hence limiting the number of languages used to develop the back end definitely helps making the development process more efficient.

Conclusion

Every programming language (the metaphorical hammer) has its own set of limitations and advantages over others. Hence different languages are used for different tasks (the nail). In this case while I may have felt that Python was better suited for rapid prototyping, I can definitely agree with the decision to use C++. However this may not always be the case and while spending massive amounts of time weighing the pros and cons of using language X versus language Y is not advised; giving a little bit of consideration about which language is better suited to a particular task is definitely worthwhile. It will help ensure that a developer or development team is making the best use of their time and delivering robust, efficient tools to their clients.