"... 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."
If this was actually implemented, it'd be incredible. No more ambiguity when you have to define all the parameters and outcomes explicitly!
It'd be incredibly stupid. The language and some other programming languages don't even have proper standards written out or they change on the whims on their creators or community. Which version of Python will you use? 2.x or 3? Oh hey and will you use the map and filter functions or use generators instead or maybe you'll use a for-loop? What are the rules for that?
Don't kid yourself, there's still a lot of room for ambiguity.
You may be able to obfuscate the code, but so long as the investor can easily test your model with values of their choice, it doesn't matter if you use a map or a for-loop.
Is a monkey-patching friendly language really the best thing for this? (Asks the Smalltalk guy, whose language is just as monkey-patching friendly and is used in a lot of Financial apps.)
Functional languages would be much better for this purpose.
Python has some FP features. More importantly, it's incredibly easy to learn, available on just about every platform (JVM users and .Net users can use it, Mac, Linux, Windows, etc).
Python has some FP features. More importantly, it's incredibly easy to learn, available on just about every platform (JVM users and .Net users can use it, Mac, Linux, Windows, etc).
Yes, but having "some FP features" is a far cry from being able to use FP to do lots of reasoning about your program.
It's not intended to be a complex statistical model. It's intended to replace XML Files that may have included calculations, with a system that allows people to plug their assumptions into the program and get an answer, rather than parsing XML and turning that into a program.
My understanding is that the type of calculations they're talking about, if you need complex Functional Programming you're doing it wrong.
Good languages actively fight off poor programming. Take ML or Haskell: if you didn't think about the problem well enough beforehand, it won't compile.
Absolutely agreed. In fact all sorts of conflicts and ambiguities can easily get missed, as well as ambiguous terms such as the bond issuer at its discretion can rearrange payments. (Yes, this has happened. And money was diverted from top tranches to lower rated ones.) Furthermore the entire reverse engineering process is a lot of work for a very imperfect result.
So this is definitely a big improvement.
But my point remains that it is not perfect. There still are ambiguities.
I'm sure someone will apply Gödel's incompleteness theorem to the Python syntax, and complain that they want to do something that isn't expressible in python (or any other language you choose).
If this works well, this might cause more legal fields to work with computer languages, enable more legal automation , and could be really disruptive to the legal profession.
If this was actually implemented, it'd be incredible. No more ambiguity when you have to define all the parameters and outcomes explicitly!