April 20, 2010
Securities and Exchange Commision:
I am a computer scientist with a background in the formal specification of programming languages.
It has come to my attention that the SEC intends to asset-backed securities (ABS) be accompanied by a computer software model that investors can use to understand the asset's possible behaviors under different scenarios (File Number S7-08-10 : p. 205, "Waterfall Computer Program"). While an excellent idea in concept, the choice of language in which the program is written makes a huge difference in terms of how useful it will be for this purpose, and unfortunately, the choice of Python as the standard programming language meets some, but not all requirements that I as an investor would desire.
Positives of Python:
- Reasonably easy for a trained programmer to read if the code is not written in an intentionally confusing style (But I would assume any competent financial engineer would endeavor to create programs that are as confusing as possible while maintaining plausible deniability.)
- Open-source interpreter available to all free of charge.
Negatives of Python:
- There is no standard specification of the Python language. The closest thing to a standard is the 363,886 lines of low-level C code implementing the open-source CPython interpreter, which is constantly being changed by its developers, completely independent of the United States government. For reference, if this code were printed in a format similar to SEC File Number S7-08-10, it would occupy over 15,000 pages! As with a written document of such enormity, the CPython interpreter surely contains numerous errors. If a particular version of Python is selected as the standard, this means as errors are discovered over time, there will be more and more opportunities for crafty financial engineers to create confusing programs.
- The proposal does not prevent programs from referencing large bodies of other code (known as libraries) which are required to execute the program correctly.
- The proposal does not prevent programs from requiring access to a proprietary data set in order to execute correctly.
The solution:
It is possible to do better. I would recommend using a formally-specified pure functional programming language. What this means, in loose terms, is a language which has been specified in concise mathematical terms, to such detail that one can confidently write precise mathematical proofs about programs. I would strongly recommend conferring with an expert on this subject, such as:
Simon Peyton-Jones, computer science researcher at Microsoft Research, Cambridge, UK and author of "Composing contracts: an adventure in financial engineering"
Greg Morrisett, Associate Dean for Computer Science and Engineering, Harvard University, Cambridge, MA
Benjamin C. Pierce, Professor of Compuer Science, The University of Pennsylvania, Philadelphia, PA
Andrew Appel, Professor of Computer Science, Princeton University, Princeton, NJ
Matthias Felleisen, Professor of Computer Science, Northeastern University, Boston, MA
Galois, Inc., Portland, OR
(or any of our other many esteemed colleagues in the formal programming language semantics community)
Sameer Sundresh
Ph.D., Computer Science, University of Illinois at Urbana-Champaign
Pattern Insight, Inc.
Mountain View, California, USA