-
Notifications
You must be signed in to change notification settings - Fork 4
Why Haskell ?
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.
Haskell prevails in data models with ADT/Recursive types and static type checking , which ensure the correctness and concise data modeling.
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
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.
Given the native compiling, the performance is comforting.