[BangPypers] Wall street may embrace Python

Rajeev J Sebastian rajeev.sebastian at gmail.com
Mon Apr 26 13:17:33 CEST 2010

On Mon, Apr 26, 2010 at 4:13 PM, Sirtaj Singh Kang <sirtaj at sirtaj.net> wrote:
> On 26-Apr-10, at 3:46 PM, Dhananjay Nene wrote:
> [snip]
>> 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.
> Well the question I'm asking is, what are the implicit qualifications of the
> humans who are going to interpret these specifications? I see two profiles:
> 1) Financial, actuarial and legal experts with some programming experience.
> 2) Programming experts with financial, actuarial and legal experience.
> While there are people who fit both these profiles, there is a reason they
> get paid high-six figure USD salaries. Python alone is fine, but consider
> bog-standard recurring financial patterns like compound interest and
> graduated tax brackets. These imply functions that will occur often in these
> specifications, further implying (de-facto-)standard libraries containing
> highly domain-specific financial routines will be written. These are already
> embedded proto-DSLs! So you're not side-stepping DSLs by using python, only
> hiding them in plain sight. But you are not necessarily gaining the benefits
> of using an independent, well-specified declarative grammar the primary one
> being that you are possibly burdening non-programmers with general purpose
> programming constructs that are not their primary focus. There is a reason
> so many finance guys use R and (gah!) Excel to do their financial modelling
> - they are not interested in programming.
> Anyhow I'll stop here, I understand that the SEC requires only a subset of
> what I'm talking about, but the scope for these kinds of agreements goes
> well past the SEC and is something worth studying and implementing in its
> own right for fun and profit.

With all due respect, I disagree that a DSL is useful for this
purpose. In fact, I would disagree with DSLs in most cases, especially
if its supposed to be used for programming. The reason for this is
that creating a good language is much more harder than creating a
language, and such efforts tend to end up with crappy languages.

As an example, take the CMAKE language (vs something like scons/waf).
As a more specific example, take the way parameters are
declared/passed to procedures/routines/functions in CMAKE vs how they
are declared/passed in python. Python's is much more elegant, flexible
and consistent. In their search for the perfect DSL for building
software, they just made yet another (crappy) programming language.

Rajeev J Sebastian

More information about the BangPypers mailing list