[BangPypers] Wall street may embrace Python
dhananjay.nene at gmail.com
Mon Apr 26 13:14:32 CEST 2010
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
> > 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
> > > sensible, pragmatic one (lots of python programmers around,
> > > financial/statistical libraries are available and mature etc) but IMHO
> > > more declarative language would have been nicer from a provability
> > > standpoint. Being able to write programs that reason about the
> > 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
> > communication of the how the waterfall implications are worked out (eg.
> > much does each stakeholder get paid and what are the conditions under
> > that gets decided) and at least in terms of standard programming
> > 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
> 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
> > > are already lots of research papers available) we'll see more
> > > languages being used for this instead, with python becoming the
> > > 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
> > > 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).
More information about the BangPypers