On Mon, Apr 26, 2010 at 4:12 PM, Anand Balachandran Pillai < abpil...@gmail.com> wrote:
> On Mon, Apr 26, 2010 at 3:46 PM, Dhananjay Nene <dhananjay.n...@gmail.com > >wrote: > > > On Mon, Apr 26, 2010 at 3:18 PM, Sirtaj Singh Kang <sir...@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 _______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
