[BangPypers] Wall street may embrace Python

[Anand Balachandran Pillai]

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:
>
> >
> > On 26-Apr-10, at 2:25 PM, Dhananjay Nene wrote:
> > [snip]
> >
> >  I do see one strong plus here for Python. That is a very natural
> language
> >>>
> >> for expression (as in being one of the most readable programming
> languages
> >> for non programmers) without resorting to any specific DSLs etc.
> >>
> >
> > On the contrary, I think treating python as a DSL host (as some are
> > implying here) is not such a great idea.
>
>
> Not sure how it got misunderstood but I meant python is easily
> understandable "without" resorting to DSLs etc. What I specifically meant
> to
> state is that perhaps it might be easier to write code which ie easier to
> understand than python - but that is more likely to involve a DSL rather
> than just a natural programming language.
>
>
> > In my experience the language is not so good at allowing small languages
> to
> > be embedded without resorting to lisp-like nested lists/tuples.
>
>
> I agree. Python is not the first language of choice for writing internal
> DSLs.
>
> 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.



>
>
> >
> > 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. The requirements seem
to be very clear on an open source, interpreted programming language
which is unlike a closd, binary executable machine program.


> >
> > -Taj.
>
>
>
> Dhananjay
>
> --
> --------------------------------------------------------
> blog: http://blog.dhananjaynene.com
> twitter: http://twitter.com/dnene
> _______________________________________________
> BangPypers mailing list
> BangPypers at python.org
> http://mail.python.org/mailman/listinfo/bangpypers
>



-- 
--Anand