[BangPypers] Wall street may embrace Python

[Dhananjay Nene]

On Mon, Apr 26, 2010 at 4:12 PM, Anand Balachandran Pillai <
abpillai at gmail.com> wrote:

> On Mon, Apr 26, 2010 at 3:46 PM, Dhananjay Nene <dhananjay.nene at gmail.com
> >wrote:
>
> > On Mon, Apr 26, 2010 at 3:18 PM, Sirtaj Singh Kang <sirtaj at sirtaj.net
> > >wrote:
>
> > This is not a deal-breaker of course, and this decision to use Python is
> a
> > > sensible, pragmatic one (lots of python programmers around,
> > > financial/statistical libraries are available and mature etc) but IMHO
> a
> > > more declarative language would have been nicer from a provability
> > > standpoint. Being able to write programs that reason about the
> contracts
> > is
> > > very important and trying to do it for a general purpose language like
> > > python will be difficult.
> > >
> >
> > I think a DSL based contract (or more precisely waterfall specification)
> > may
> > be more concise and self descriptive. But that would require a definition
> > of
> > a new language grammar.  However reasoning about the contracts is not in
> > the
> > scope of the SEC specification. The scope is (in my understanding) a
> clear
> > communication of the how the waterfall implications are worked out (eg.
> how
> > much does each stakeholder get paid and what are the conditions under
> which
> > that gets decided) and at least in terms of standard programming
> languages
> > Python does pretty well.
> >
>
> Precisely. The program that SEC mentions is a "waterfall program" which
> calculates which investor gets paid first, second etc, when and how much
> etc
>
> in monetizing a commercial mortgage backed security asset. I read
> through the relevant sections of the SEC PDF and this does not look
> like it needs a DSL contract but more of routine programming.
>

Apologies at persisting in this .. but I do think it is a very
unconventional usecase for programs to be used as specifications.

The scenario here is that the program (as in the python code) is the means
of communication  - it is *not necessarily* a runtime construct.
Organisation A models its understanding of the various fiscal implications
and publishes as a appendix of python code in a document. This document is
filed with SEC and then finds its way to Organisation B. In a very strange
situation here "the code is the specification of understanding" and replaces
"english legalese as a specification of understanding".


> > > I think over time once smart contract research becomes more mature
> (there
> > > are already lots of research papers available) we'll see more
> declarative
> > > languages being used for this instead, with python becoming the
> de-facto
> > > support language to build tools around them.
> > >
> > > Meanwhile, I'll repeat something I say far too much but anyway: domain
> > > knowledge is just as important as programming chops. Folks who want to
> > get
> > > in on the ground floor with these kinds of applications of python
> should
> > > start learning the vocabulary and process flows of finance ASAP.
> >
>
> +1. Btw, I am not sure if the requirements will get diluted to Excel
> etc later since the filing is very clear on open source technologies
> and mentions "Python" exactly 15 times.


Need not necessarily be excel. If I am a member of Organisation B - I could
use the document in a number of ways. eg.

a. Just run the python program and hopefully it meets my needs.
b. I might call up my python consultant and ask him to convert it into my
preferred format (excel? :)) so that I can do some "playing around".
c. I might have a bunch of inhouse six figure earning PhDs who might break
it to pieces and come back with an exciting looking PPT after doing some
deep map-reduce jobs :) or may further use an outsourced developer who may
create a program for me to do some senstivity analysis.

When I say excel - I mean in the preferred format of the user.  For small
users excel is simply the most easiest amenable sensitivity analysis tool.
Python ain't replacing that.

*The key point is python as the host language for specification here is a
far more important aspect than python as the runtime environment to actually
run the code in.  *


> The requirements seem
> to be very clear on an open source, interpreted programming language
> which is unlike a closd, binary executable machine program.
>

In case of option a above :  Python is merely the host language and is as
good as any so long as a reliable, well understood and trusted runtime is
readily available (which is why I guess it focuses on the openness).
-- 
--------------------------------------------------------
blog: http://blog.dhananjaynene.com
twitter: http://twitter.com/dnene