Computer scientist responds to SEC requiring Python

I have to give it to the SEC though for even requiring such model. My dream is every financial product (from credit cards to CDOs) to come with the model and as standardized inputs as possible. People could then make websites like: WillIDefault.com that would show the risk you're taking - including the conditionals of the contract.

You could satisfy his objections by saying:

Use only the x.x version of python, only these (x) approved libraries are allowed, and you must publish any data you use.

True, he is only pointing out that the SEC requirement has a flaw, but it seems easily fixable to me.

Summarized as: due to one largely theoretical and two solvable potential issues with a widely understood, proven, and practical language, I propose we adopt an imaginary, non-existent language with a programming model foreign to most.

"no standard specification of the Python language" - given the existence of at least 4 implementations of the language (cpython, ironpython, jython, pypy), it's hard to seriously argue that the language is poorly specified.

Purely functional - you'd be hard pressed to find 1 in 10 good programmers who'd be productive in a purely functional language.

For more background and previous discussions see:

http://news.ycombinator.com/item?id=1272541

http://news.ycombinator.com/item?id=1578133

Wow, a "computer scientist with a background in the formal specification of programming languages" thinks that the SEC should be "using a formally-specified pure functional programming language".

Yes, and when I worked at GM, I thought everyone should buy GM cars. Go figure.

A strange thing about the SEC proposal is all these structured deals are already structured with programming languages. They are usually proprietary languages used to run scenarios and evaluate deal structures. These could simply be made public. It would be a more enforceable standard than having two sets of code.

I agree with the author of the article that a functional programming language like haskell would be a nicer way to go than python, but we should always remember that the real governing documents--the prospectus, and the more important but more obscure trust deed--are written in legal language. The math only covers part of the semantics of a financial transaction.

This is a pretty interesting proposal, and I must say, on first impression I think that implementing a Python-base solution would be a massive improvement to our current state of affairs, to a solution that might be the best 'good enough' solution implementable soon.

"you should listen to a bunch of academics, and use Erlang for securities, which will lead to less tricky programs from financial engineers."

The article purports roughly this with sincerity.