F#, the ACM, and the SEC

It all started with a twit from @mulambda: “Phil Wadler lists #fsharp as a candidate for SEC regulation spec language: http://tinyurl.com/2edfxka” I downloaded the, nonetheless, Association for Computer Machinery answer to the Securities and Exchange Commission proposal (and ask for comments) on requiring Python programs to be provided to explain contractual cash flow provisions. I quickly skimmed the ACM document and twitted “Java, C#, and F# recommended by the #ACM for SEC regulation spec language http://is.gd/e49Vt #fsharp /via @mulambda”. Later, I read with more care the ACM answer and I found that I really should clarify my twit:

1. First of all, in no place the ACM explicitly recommends Java, C# or F# (sorry for my over-enthusiastic extrapolation )
2. What the document does do, is to put Java, C#, and F# in a (very?) positive light at several places:
1. “Safe execution of code written by one party on a machine owned by a different party was not a strong concern in the design of Python. It was a strong concern in the design of other systems, including Java and the .Net framework (which supports multiple languages, including C#, F#, and Iron Python)” Page 4.
2. “The widely accessible interpreted implementations of Python and Perl execute more slowly than compiled languages such as Java, C#, F#, and Scheme by as much as one or two orders of magnitude” Page 4.
3. “Python has a specification written in English, but its specification has not received the same careful attention as those of Java or C#. Page 5
4. “Java, C#, and F# are designed to be executed efficiently, Python and Perl implementations are significantly less efficient” Page 6
5. “Statically typed languages are generally considered to produce more reliable and easier to maintain code, while dynamically typed languages are generally considered to produce more flexible
   code and to be better suited for prototyping. Java, C#, F# are statically typed; Python and Perl are dynamically typed” Page 6 The bolding is mine, this one is specially controversial but I for one (more like 1 cent) think it’s a good point.
6. “Some programming languages have been designed with security in mind, and some of their implementations include “sandboxes” that can securely execute untrusted code. Java, C#, and F# are such languages; Python and Perl are not” Page 6
7. “Java and C# have had significant effort put into producing precise specifications; F#, Python, and Perl less so. SML and Scheme possess full formal mathematical specifications; F# is descended from SML”
3. What the ACM does explicitly recommend (page 1):
1. “Other programming languages may be more appropriate than Python”
2. “Security should be enhanced by executing the code in a "virtual sandbox." ”
3. “The SEC should consider developing a domain-specific programming language or library for writing waterfall programs.”

And it is this last recommendation on DSLs that carries interesting news for F# because at the end of page 6 it states “Experience seems to show that higher-order programming languages such as F# provide a particularly good basis for domain-specific languages. There are financial domain-specific languages available in F#” . And for an encouraging ending in page 7, answering the question “Is it appropriate to require issuers to submit the waterfall computer program in a single programming language, such as Python, to give investors the benefit of a standardized process?”, the answer includes “Other choices, such as F#, may be more appropriate than Python” .

So, I think I should really replace my original twit with something like this:

Java, C#, and F# mentioned by the ACM as possibly better alternatives for the SEC regulation spec language. Furthermore, the ACM recommends the creation of a DSL and mentions F# as a good candidate for doing so.

Finally, let me clarify that I have nothing against Python, on the contrary I like most of (the little I know of) it, and I’m fully aware of the myriads of working solutions written in Python, so more power to the Python people! It’s only that I think that, looking forward -particularly in the financial industry, we are better served by functional languages like F#.