On Mon, Apr 26, 2010 at 3:18 PM, Sirtaj Singh Kang <sir...@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. > > 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. > > -Taj. Dhananjay -- -------------------------------------------------------- blog: http://blog.dhananjaynene.com twitter: http://twitter.com/dnene _______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers