At the beginning of this week, I asked, "Will Wall Street require Python?", as an initial reaction to the appearance of Python, Perl, and Java in certain proposed new Securities and Exchange Commission (SEC) regulations.
Since then, I've confirmed my unwritten first impression: there's a lot more going on with current and proposed disclosure practices than I can afford to track, and possibly even know. Briefly, I've had to attend to and even been registered with the SEC and CFTC before, and I'll require significant rewards before it happens again. At the policy level, keep in mind that the trading world is at least as Kafkaesque as Joe Conason, Gabriel Winant (whether writing about coal mines or Frank Luntz), Mark Chu-Carroll, or Jon Stewart, or even the SEC's own inspectors portray. It's clear, moreover, in the specific case at hand, that at least one of the co-authors of the proposed rules is deeply confused about computing artifacts: even if we are charitable about the claim that Python "... converts one program statement into machine language, executes it, and then proceeds to the next statement", there appears to be deep confusion in the document about executable vs. "script" vs. "features ... beyond the ... browser's native ability to ... display HTML", especially in regard to security.
What I can usefully do now, though, is collect here a few of the language-specific ideas I've come across that are pertinent to disclosure reform:
What's the goal?
Let's stipulate for the moment that the aim of this initiative is to enhance the transparency of filings on derivatives and eventually other instruments: rather than rely exclusively on legal English, which is fragile enough that a misplaced comma can entirely reverse a passage's meaning, and difficult even for lawyers to read, replace or at least supplement it with an unambiguous computing language. Python was provided as an example of a computing language that is particularly readable, has a history of deployment on Wall Street, is open source, and is "interpreted" (which the document seems to regard as good magic for security considerations).
I think there are sincere people in the Federal government working toward laudable improvements in transparency. I'm certainly a coder in Python, and its origins as a "first language" have served it well; it increasingly appears as pseudo-code, for instance, precisely because it has the reputation of being readable even by non-users.
Even the best programming languages only abstract or manage problems of analysis and expression, however, not eliminate them. Perl's "line-noise syntax" is often uncharitably compared with Python; the second edition of Programming Perl, for example, cheerfully boasts or perhaps concedes that, "any technology sufficiently advanced is indistinguishable from a Perl script." For all the wisecracks about Perl's unreadability, though, Leon Timmermans is right to observe that, "Perl 5, Python, Ruby, they’re almost the same" (and Lua, Tcl, Rexx, and a few others also fit in this bin). Even when a language is as "English-like" as COBOL, programming doesn't become easy. The apparently less lofty goal of guaranteeing that the results of specific programs can be determined by inspection is just as far out of reach.
Improvement is possible, though, if we go to domain-specific languages (DSLs). Alain Frisch helpfully pointed to the work of LexiFi, which implements DSLs in Ocaml for the rather restricted domain of derivative specification. At a technical level, that sounds like a far more realistic combination than hopes that a general-purpose procedural language will be able to express more general financial arrangements. My own time working with expert systems, financial markets, and DSLs only confirms that large-sense "artificial intelligence" ambitions lead to insanity.
Timmerman's paean to Perl 6 and all the existing literature on proof techniques suggest that a functional language (ML? Haskell?) might be a good starting point for attempts to "mechanize" the specification of financial instruments. The biggest surprise in this discussion for me has been the relative absence of attention to declarative languages. Excel, for instance, is shamefully wrong in several ways, but there's no question that financiers are comfortable with its computing model!
My conclusion: whatever Washington and New York (and London and Chicago and ...) work out, there'll be plenty of interesting work and technically challenging requirements in financial specification to sort out.