April 19, 2010, 12:44 PM — Failure is difficult. Sometimes success is even more so.
What if, for example, Python not only:
- becomes popular for its role in the Plone content management system, SciPy scientific programming suite, Mailman mailing-list manager, and other specialized applications or frameworks;
- is adopted by many leading schools around the world;
- is chosen as a preferred scripting language for such prominent projects as OLPC, Ubuntu,
GNOME, and so on; - is the one language Google originally exposes for its crucial Google Application Engine entry in the "cloud computing" sweepstakes;
- shows up a in flattering light in popular cartoons;
but even becomes part of US administrative law? It could happen, and soon.
On 7 April 2010, the US Securities and Exchange Commission (SEC), the federal agency charged "... to protect investors, maintain fair, orderly, and efficient markets, and facilitate capital formation", proposed new rules covering "Asset-Backed Securities" [warning: 667-page PDF]. Administratively, this is a reaction to the trillion-dollar financial atrocities of the last few years, as well as a natural manifestation of the Obama administration's commitment to enhance procedural transparency. Shockingly, "... Python, a commonly used open source interpretive programming language ..." shows up on page 1 of the description. What is that about?
Programmers' introduction to Wall Street
The nominal social function of Wall Street (or The City for those in the UK, and so on) is middleware, or, as the finance literature labels it, intermediation. You're young, you want to buy your first house, you've got lots of income, but not much in the way of savings; it'd be cool if you could somehow borrow money from oldsters who have more than they know how to spend, and promise to pay it back. Banks, mortgage brokers, and all sort of other institutions exist to bring you two together. Most of the time, when we think about Web applications, we get to concentrate just on the server and the browser, and assume away all the routing, error-correction, DNS, and other action in the middle that just happens. Banks are supposed to do the same: they take care of all the details of protocol and process and "API" so that we get on with our financial lives.
Bankers are also like us in that they split their time between operating--showing up for day-to-day work--and innovating. It's a big deal to them when someone invents the financial equivalent of "list comprehensions" or "co-routines"; in principal, new techniques help them become more efficient, so they serve their customers better, make more money for themselves, and everyone wins. They even lean back at the end of a week and argue "emacs vs. vi", except translated into financial terms.
A crucial correspondence in this analogy has to do with canonicalization. As David Clark said long ago, "We believe in rough consensus and running code". Financiers "send it by legal".
Do you see the problem (there are actually several, but today we'll focus on only the primary one)? We have robust mechanisms for reaching agreement about "running code"; even Heisenbugs, importabilities, and version skews slow us down only marginally. When legal disputes arise, though, projects can lock up for years.
What's the solution? Well, with Release 33-9117, the SEC is considering substitution of Python or another programming language for legal English as a basis for some of its regulations.
Consequences
One respected commentator has already written, "[t]his is absolutely the right way to go ..." It even echoes a couple projects of mine (more on those, later), although I advertise pay-offs in the milllions of dollars, rather than billions of 33-9117. What will the consequences be when we win, though? Something like this--perhaps in Java or Perl or Ocaml rather than Python--will happen, sooner or later. It'll be exciting and maybe even rewarding to respond to the new markets opened up, of course: courses to teach, books to write, and applications--lots of new applications--to code. How will Python work, though, after the lawyers get in their counterpunches? When I go to Python Conferences, I expect to talk about optimizations, and whether Python can handle one more GUI toolkit, and even, briefly, how much "sizzle" Python has for venture capitalists; what will it feel like when our attention is on new syntax that the financial whizzes insist is necessary, and the US government backs them?
Part of the story of IronPython, about which I've been writing all month, is that it represented a new kind of risk for Python and its practitioners. IronPython has been in large part a Microsoft project, and there have been worries since IronPython was begun that Microsoft would distort Python in proprietary directions. IronPython has worked out better than I expected: Microsoft has been a good partner to Python, at least to this point. Python's in good shape for travel to an even larger and more hazardous realm than Redmond, that of the legal and financial worlds. It's inevitable, though, that along with the benefits, costs will also come.
