To Whom it may concern:
In the document entitled
SECURITIES AND EXCHANGE COMMISSION
17 CFR Parts 200, 229, 230, 232, 239, 240, 243 and 249
Release Nos. 33-9117; 34-61858; File No. S7-08-10
RIN 3235-AK37
ASSET-BACKED SECURITIES
a number of changes to Item 601 of Regulation S-K, Rules 101, 201, 202 and 305 of Regulation S-T, a new Rule 314 of Regulation S-T and changes to Form 8-K are proposed. These changes are proposed to accommodate the filing of the ‘waterfall’ computer program. The document requests comments on this proposal.
Is it appropriate for us to require most ABS issuers to file the waterfall computer program?
As mentioned in the proposal, ABS issuers are currently required to submit an informal, ‘English language’ description of the waterfall. A computer program would be far more formal and less likely to be ambiguous or misinterpreted.
Is it appropriate to require issuers to submit the waterfall computer program in a single programming language, such as Python, to give investors the benefit of a standardized process? If so, is Python the best choice or are there other open source programming language alternatives (such as PERL) that would be better suited for these purposes?
The proposal goes to great lengths to justify the choice of Python as the language in which the waterfall program should be expressed. Unfortunately, every one of the justifications is either incorrect or irrelevant.
- Python is an open source interpreted programming language. — Python is more accurately described as a family of programming languages with several implementations. The Python Software Foundation supports one particular implementation, but both Microsoft and Nokia offer alternative implementations. The Python Software Foundation provides an interpreter, but there are versions of Python that are fully compiled, byte-code compiled, or JIT compiled.
- Open source means that the source code is available to all users.— This is true, but irrelevant. INTERCAL is an open source language, yet it is completely unsuitable for the purposes of writing a waterfall program. On the other hand, the Microsoft implementation of ECMAScript is proprietary, yet ECMAScript is certainly a language to consider for waterfall programs.
- An interpreted language is a programming language that requires an interpreter in the target computer for program execution. — Interpretation is a technique for implementing a language. Few languages require an interpreter, and as noted above, compilers for Python exist.
- Since Python is an interpreted language that does not need to be compiled prior to running it, executable code would not need to be published on EDGAR. We define executable code in Rule 11 of Regulation S-T [17 CFR 239.11] as instructions to a computer to carry out operations that use features beyond the viewer's, reader's, or Internet browser's native ability to interpret and display HTML, PDF, and static graphic files. Such code may be in binary (machine language) or in script form. Executable code includes disruptive code.— A Python program is most certainly ‘executable’ by the definition supplied.
The proposal appears to be suggesting that safety is an important desideratum. This includes the safety of the EDGAR system as well as the safety of the investors that would presumably use the waterfall program. The proposal concludes that a language that is executed by an interpreter would be inherently safer than a compiled language. This is false. There has been a considerable amount of research into computer safety, and it is clear that safety is very hard to achieve even if it is the highest priority in the design. Provable safety is not, and never has been, a goal of Python.
To conclude, I believe that a formal description of the waterfall algorithms written as a computer program may be quite beneficial to investors. The proposal, however, fails to enumerate the desiderata for the language such a program would be written in. The proposal makes a few erroneous assertions and then puts forward Python as a suggested language. While Python is a popular language, it was never intended to be used as a critical component of such an important part of the U.S. economy.
I suggest that Securities and Exchange Commission, if they intend to pursue the path of requiring a formal waterfall program to be provided, follow a formal process for finding or developing a suitable language. First, the requirements for such a language need to be specified. Second, these requirements should be compared against existing and proposed languages. Finally, one or more of the languages should be adopted and implemented.
Sincerely,
Joe Marshall
Joe Marshall
Your main point seems to be that SEC considers safety to be in important criterion in the choice of language for implementing the waterfall program, and that despite their arguments, Python is not a "safe" language.
ReplyDeleteIt is true that Python is not provably "safe". There are very few things that a computer can prove about a Python program, as anyone who has contributed to one of the implementations can tell you.
However, the process of negotiating the contract for an Asset-Backed Security is a human process, so there is no requirement that a computer be able to verify the safety of a program. These waterfall programs should be simple, and easy to verify for a human, which is what I believe they were really driving at with their selection. It is possible to write incomprehensible Python programs that exhibit "unsafe" behavior, but the human signing the contract has the option to complain to the author that the program is incomprehensible, and therefore they will not buy the security unless the author rewrites it.
The key criteria that I think they are looking for is not safety but the ability to clearly and concisely express the rules of the contract. I believe that Python would in fact be a good medium for allowing traders to communicate and negotiate the terms of their contract. Not only does it already have a following in the world of finance, but the language is known for its readability and friendliness to beginners.
I haven't read the whole proposal, but from the thrust of the bits you quote, I understand the SEC's point to be this: Python can be interpreted by a freely and widely available interpreter. If there were no such interpreter (as is the case for C++, Cobol, and Fortran, for example), it would be necessary for the SEC to publish executable code distinct from the source, exposing the SEC and the public to the risks borne by anyone who publishes opaque code of any sort. With Python, the risk is greatly limited.
ReplyDelete