

Computer scientist responds to SEC requiring Python - dfj225
http://www.sec.gov/comments/s7-08-10/s70810-9.htm

======
nickpinkston
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.

------
po
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.

~~~
jmtulloss
He addressed this by saying that requiring a version would leave you unable to
fix bugs when they were found, which could then be exploited.

------
tworats
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.

------
RiderOfGiraffes
For more background and previous discussions see:

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

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

------
praeclarum
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.

------
T_S_
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.

------
DaniFong
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.

------
andrewljohnson
"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.

