
Adventures in financial and software engineering - blondie9x
https://falconair.github.io/2015/01/30/composingcontracts.html
======
osullivj
I started working in financial tech in 97, and I've seen a number of "one
model to rule them all" efforts come and go since. Back in the late 90s I saw
consultants touting Java coded UML models as the way for banks to build the
definitive object model of their trading operations. In the early 2000s I
worked on JP Morgan's Kapital, an early 90s Smalltalk risk management system
using the Gemstone DB. That was supposed to be the last word in derivatives
abstraction. And more recently I spent some time working on JP's Athena
project, a Python NoSQL system with an implicitly functional graph programming
system that enables Python code to behave like spreadsheets. I suspect the
ability of traders to invent products, and more recently regulators to invent
rules, will always outstrip the ability of coders to invent clean abstractions
that will factor the financial domain neatly.

~~~
boothead
There is one (at least) of these systems live based on the original paper by
Simon Peyton Jones in a dialect of Haskell.

JPM/BAML/GS have fallen down due in large part to their choice of language in
my view. A graph database written in a hurry in C++ then glued together with
tens of millions of lines of hacked up python is not the way to build a bank
wide platform in my book!

~~~
nicolapede
What is the paper's title? I'd like to understand the theory behind this
approach.

~~~
gjm11
Probably this one: [http://research.microsoft.com/en-
us/um/people/simonpj/Papers...](http://research.microsoft.com/en-
us/um/people/simonpj/Papers/financial-contracts/contracts-icfp.htm)
("Composing contracts: an adventure in financial engineering"). If you have
the book called "The fun of programming" (abound functional programming), you
have an updated version of that paper; the chapter is called "How to write a
financial contract".

[EDITED to add: This is also the first link in the OP.]

------
lucozade
Declarative descriptions for financial contracts and markets having been
actively used for a long time now.

Executable descriptions not so much. The issue really is that it's solving
problems we don't have with a solution that gets in the way of solving the
problems we do. That's not to say people haven't tried, far from it. But
successes tend to be either very rare or very niche.

------
jackgavigan
FpML (Financial Products Markup Language) was conceived shortly before the
paper referenced in the blog post.[1]

One of the paper's authors went on to create MLFi, a modelling language for
finance[2]

This stuff is a bit esoteric but I think it will attract more attention
because of its relevance to smart contracts.

1: [http://www.fpml.org/](http://www.fpml.org/)

2: [https://www.lexifi.com/product/technology/contract-
descripti...](https://www.lexifi.com/product/technology/contract-description-
language)

------
tdees40
I put together a Haskell proof of concept Monte Carlo pricing tool loosely
based on SPJ's work:

[https://github.com/boundedvariation/quantfin](https://github.com/boundedvariation/quantfin)

Still needs some love, but it was a pretty cool experience.

~~~
zhte415
I did similar, but I did it Excel. It was cool, not an experiment, and it was
done quickly, as Excel is the ultimate Agile tool in finance.

------
pandatigox
I'm digressing a bit, but what language is used here? A skim-over looks like
Prolog, but recommendation links at the bottom say Scala. Are the functions
(when, and) predefined and not part of the language itself?

~~~
desdiv
It's Scala. They show the definitions of the "When" and "And" in the post:

    
    
      case class And(contract1: Contract, contract2: Contract) extends Contract
      case class When(date: LocalDate, contract: Contract) extends Contract
    

It's basically a DSL on top of Scala.

------
platz
I'm a fan of the combinator way, but of course now you have to 'interpret' or
'evaluate' the structure to know what the contract means, so it might be hard
to run a 'query' over a bazillion of them sitting in a database - you'd have
to interpret each one (each one is a little black box).

This is assuming that running a query or search over all the contracts is
something that is useful to do, which I have no idea if that is the case
(though seems like a common task in applications programming).

------
cheez
I worked on aa commercial product called F3 which, among other things,
implemented this type of contract specification as a subset of its
functionality. Unfortunately, I'm not sure if they ever learned how to sell it
well. One of the most memorable stints in my career so far.

------
baq
there was a blog post or an article by somebody at jane street about their own
contract DSL a few years ago. can't find the link now though.

~~~
cheez
The paper that kicked this all off is in the references section. I believe the
original company was called lexifi

------
jiantastic
Looks to be a really interesting article. Would really appreciate a font
change and justified text though.

~~~
paperwork
Good idea. I'll justify the text. What's wrong with the font?

