On Mon, Apr 26, 2010 at 4:13 PM, Sirtaj Singh Kang <sir...@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. Regards Rajeev J Sebastian _______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
