It's All Geek to Me!

« Vishy's Indian English Dictionary: doubt | Main | Blogging the Mahabharata: Introduction »

July 13, 2006

Dynamic languages in the finance industry

Lisp, the ancient patriarch of computer languages, is derided as much in industrial circles as it is revered in academia. "What good is Lisp when you can't design real production systems with it?", its detractors have asked for a number of years. For all these years—multiple generations in the accelerated timescales of technology—such derision was hard to counter. Lisp and related languages were respected for the way in which they molded the thought processes of young computer scientists, but not for much else. And yet, now, if you look in the right places, Lisp and other languages that owe an intellectual debt to the Lisp programming environment are making a comeback. Recognized names in industry now employ functional and dynamically typed languages, including Python, Ruby, OCaml and Lisp itself as cornerstones of their operations. The financial services industry, one of the powerhouses of the modern economy, stands to profit immensely from this trend in particular. Let us see why functional and dynamically typed languages and the financial services industry can be such a great match for each other.

Before we proceed, there is a technical distinction to be made between functional languages and dynamically typed languages. Functional languages are exponents of a style of programming that considers any computer program as a function mapping input values to output values. On the other hand, dynamically typed languages, also known as dynamic languages, treat program objects differently in different execution contexts rather than requiring them to identify their type at compile time. Typically, dynamic languages erase the distinction between compile time and runtime because their compiler and runtime can be invoked in one go. The dynamic languages referred to above as being in vogue also support functional programming. Keeping this in mind, in the context of this essay only, we will use these terms interchangeably.

Computer applications in the financial services industry can be classified broadly into modeling, reporting and transaction-executing applications. Consider applications that model financial instruments and price them for the open market. Aside from sundry trading of stocks, bonds and other financial instruments, financial services firms profit by inventing new kinds of securities in-house and building armies of financial services experts around them. Once a new security starts trading in the open market, the technical infrastructure to model and price it also follows close behind. Currently, a financial services professional (FSP) must explain the financial concepts underpinning a new type of security to an applications programmer. The application programmer then produces an application that is aware of this new type of security by modeling it in object-oriented languages like C++, Java or C#. Building a compile-time type scaffolding around a new conceptual domain is not a trivial task. Most of the time, the sole purpose of such work is to pacify the compiler and has nothing to do with the conceptual domain of financial instruments.

Dynamic languages forgo strict compile time checking and view an object's type more as the set of operations it can perform rather than an inherent property of the object. Ruby, for instance, calls its dynamic typing 'duck typing', which comes from the adage 'If it quacks like a duck, it is a duck.' In other words, an object need only perform the operations characteristic of a type to qualify as an instance of that type. This feature turns out to be unusually handy in the financial services world. When modeling and pricing a complex security like an option on an option on a swap or a collateralized debt obligation (CDO) backed by another (also known as a "CDO-squared"), it's more important to know what behavior that security is capable of rather than ascribing it a meaningful type ahead of time. For example, the same set of operations apply to disparate kinds of derivative securities, regardless of whether they are based on an actual asset or another derivative. Correspondingly, in an object model representing these derivatives, it is more important to be able to put them in a collection and apply the same operation to them rather than care about the specific security from which they derive their value. A statically typed environment with compile time checks turns out to be more an encumbrance than a boon in such a situation. This is exactly where dynamic languages step in. They get out of the way of application developers by freeing them of strictly technical type-related concerns. Thus, they reduce the amount of work that goes into modeling a new financial product and save valuable application development time.

In fact, with the right choice of dynamic language, the line between FSPs and application programmers can be blurred, which brings us to the second benefit of dynamic programming languages to the financial industry. Time is easily the most valuable commodity in the financial services industry. For a company in this industry, a faster development cycle for financial computer applications could mean stealing that edge over its competitors in a hotly contested marketplace, where secrets don't stay secret for very long. The effort involved in developing financial software is split in a dichotomy between FSPs and technical-minded application programmers. Inevitable misunderstandings of requirements, along with other communication-related overhead, can quickly eat up valuable time in development cycles. Most dynamic languages today provide highly integrated development and execution environments, where it is possible to freeze the execution of a production application, introspect objects and their behaviors, and make changes to the system even as it is running. Back-and-forth communication between business units and application programmers can thus be greatly reduced. Additionally, today's dynamic languages are far easier to embed in larger applications than their statically typed counterparts. By using them, the application programmer can furnish the FSP with building blocks that let them program in a mini-language of their own. The FSPs do what they know best: modeling financial instruments; application programmers also sidestep any possibility of miscommunication by also doing what they know best: building good layers of abstraction.

Let us build upon the idea of abstraction a bit further to arrive at the third advantage of dynamic languages. An abstraction layer, it bears repeating, is a very powerful concept. For evidence of this claim, look no further than the copy of Microsoft Excel running on an FSP's desktop. Sometimes, the entire business of a financial services firm hinges upon Microsoft Excel. FSPs use Excel in a big way to get things done because they tell it what quantities they want it to calculate rather than how it should calculate them. This style of programming, called "declarative" programming, as opposed to the "procedural" variety application programmers are intimate with, is powerful because it operates at a higher level. It allows its users to ignore the details that don't ultimately matter. Functional languages are excellent at modeling an operation as a sequence of logical steps, where each step can be seen as transforming its input in some way before passing it along to its successor. Programs written in functional languages can inspect their own structure, modify it and generate other programs with astonishing ease. Imagine a "program of programs", a toolbox that contains other little programs to perform different kinds of operations. An FSP can model a workflow in this program of programs by dragging and dropping boxes, connecting them with arrows and defining how information flows across the boxes. Application programmers using visual development environments such as Visual Studio do this already when developing graphical user interfaces. The possibilities are essentially infinite if a high-level modeling approach such as this was adopted by FSPs by harnessing the power of functional languages.

Functional and dynamic languages are not appropriate for every kind of financial application. In cases such as trade engines, where raw performance is paramount, there is no substitute for the nose-to-the-ground approach of highly optimized programs written in traditional programming languages. Some firms may also be squeamish on multiple counts about using dynamic languages because most of them are open-source and don't have large corporations backing them. Yet, it is no coincidence that hedge funds and other financial services firms of the nimbler variety have built entire businesses around dynamic languages. It is ultimately poetic that the programming languages so well suited to an industry as dynamic as the financial services industry are also called dynamic languages.

Posted by Vishy at July 13, 2006 10:49 PM

Comments

Posted by: Mike Hales at August 14, 2006 11:28 AM

Posted by: Isaac Gouy at August 14, 2006 05:45 PM

Posted by: dennis at August 15, 2006 10:05 AM

Posted by: Isaac Gouy at August 17, 2006 01:10 PM

Posted by: Vishy at August 18, 2006 12:54 AM