Skip to content

Why Haskell ?

Shawn Zhang edited this page Dec 9, 2023 · 7 revisions

Maintenance

I've been tried with Python and Clojure . Dynamic programming languages are not best fit in structured finance, where we are expected lots of combination of data models. It may look efficient to start with dynamic but it ultimately become extremely hard to maintain, especially with more types of fee/bonds/payment types were included.

Data Modelling

Haskell prevails in data models with ADT/Recursive types and static type checking , which ensure the correctness and concise data modeling.

Recursive Type ->

In structured finance there are many calculation/ratios involved, which is a number derived from from another. the derived can be a sum or a multiplier ,with rounding , or a cap or a floor. All these calculation could be done in language like Java with writing hundreds line of boilerplate codes. With Haskell, it can easily represents like :

Value  =  Pool Float
       |  Bond Float
       |  Sum Value Value

Without un-necessary combinations of

  • Sum of Pool1 and Poll2
  • Sum of Bond and Pool
  • Sum of Bond2 and Bond2

Imagine the number of types in structured finance, the benefit of recursive types yield tremendous help in terms of expressiveness and low maintenance cost.

Here is another example with Deal Status

data Status = Preclosing Status
            | Revolving
            | Amortizing

Here, the Preclosing precedes either Revolving or Amortizing, the recursive type is concise in expressing this. Without recursive types :

data Status = PreclosingRevolving
            | PreclosingAmortizing
            | Revolving
            | Amortizing

Handling Nested Structure

there is a state of art library in Clojure specter which is great handling deep nested structure. Luckily ,lens works well with Haskell as well. It is useful when dealing a big deal object with fees/accounts/bonds/etc.

Performance

Given the native compiling, the performance is comforting.

State Management

image