We are proposing to require that most ABS issuers file a computer program that gives effect to the flow of funds, or “waterfall,” provisions of the transaction. We are proposing that the computer program be filed on EDGAR in the form of downloadable source code in Python....
It's vindication for agoric computing!
I share the same question as Prof. Varma, however. Isn't it problematic that Python is ill-specified? It is surely convenient to write and read, but a contract needs to be especially rigorously defined. Using a program to describe a contract has the potential to be very reliable, but only if the programming language is particularly well defined.
There are much better specified alternatives. Some have suggested Java as well-specified, and I'd agree, so long as the precise libraries used are also delineated. A more tempting candidate for me would be Scheme or SML. In addition to being well-defined, functional languages lack overriding and thus yield programs that are easier to analyze. Object-oriented languages, by allowing every method to be overridden, yield tremendous power and convenience but make it harder to prove definitive statements about a program. Just imagine trying to say something about E=mc^2 when all of E, m, c, squaring, multiplication, and equality can be overridden.
Some commenters in the above blog article suggest spreadsheets as being a closer match to how financial analysts would like to work. Spreadsheets, it is claimed, would allow the analysts to examine intermediate results. That's very interesting, but are there any spreadsheet-friendly languages that are particularly well specified? All the ones I've encountered are defined by their implementation.