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.
3 comments:
Hi Lex,
My biggest problem with today's spreadsheets is that errors don't propagate. Defining new values in terms of old ones does not propagate errors and implicitly ignores old errors.
So, for example, in Excel, if A1='20.03, A2=20.03, a3=sum(a11:a2) results in 20.03 and no error warning, because sum discarded the value in A1 treated as a number. Informally trained people tend not to understand the global implications of ignoring errors locally, so if errors are allowed to propagate silently it can be very hard to see that, "The value is 20.03, but be warned that some of the values used to calculate the result had to be implicitly discarded, click here to see a view of which ones." That's just good software design, but no spreadsheets do it.
Good point, Z-Bo. I didn't know that behavior was typical. Errors should certainly propagate for any calculation you really care about.
Here's another example.
If you circularly reference something in an expression, Excel will pop-up a warning, but then the warning will not persist.
So, for instance, in A1 type in =A1
This will warn you about a circular reference, but when you click OK, nothing propagates. That's not a very helpful system.
See http://office2010.microsoft.com/client/helppreview.aspx?AssetId=HP100662439990&lcid=1033&NS=EXCEL&Version=12&queryid=&respos=1
Post a Comment