type MapTypeConverter() =
    inherit JsonConverter()

    let doRead (reader:JsonReader) = 
        reader.Read() |> ignore

    let readKeyValuePair (serializer:JsonSerializer) (argTypes:Type []) (reader:JsonReader) =
        doRead reader // "key"
        doRead reader // value
        let key = serializer.Deserialize(reader, argTypes.[0])
        doRead reader // "value"
        doRead reader // value
        let value = serializer.Deserialize(reader, argTypes.[1])
        doRead reader // }
        FSharpValue.MakeTuple([|key;value|], FSharpType.MakeTupleType(argTypes))

    let readArray elementReaderF (reader:JsonReader) =
        doRead reader // [
        if reader.TokenType = JsonToken.StartArray then
            [|
                while reader.TokenType <> JsonToken.EndArray do
                    doRead reader // {
                    if reader.TokenType = JsonToken.StartObject then
                        let element = elementReaderF reader
                        yield element
            |]
        else
            Array.empty

    let writeKeyValuePair (serializer:JsonSerializer) (writer:JsonWriter) kv =
        let kvType = kv.GetType()
        let k = kvType.GetProperty("Key").GetValue(kv, null)
        let v = kvType.GetProperty("Value").GetValue(kv, null)
        writer.WriteStartObject()
        writer.WritePropertyName("key")
        serializer.Serialize(writer,k)
        writer.WritePropertyName("value")
        serializer.Serialize(writer,v)
        writer.WriteEndObject()

    let writeArray elementWriterF (writer:JsonWriter) (kvs:System.Collections.IEnumerable) =
        writer.WriteStartArray()
        for kv in kvs do
            elementWriterF writer kv
        writer.WriteEndArray()

    override x.CanConvert(typ:Type) =
        typ.IsGenericType && typ.GetGenericTypeDefinition() = typedefof<Map<_,_>>

    override x.WriteJson(writer:JsonWriter, value:obj, serializer:JsonSerializer) =
        if value <> null then
            let valueType = value.GetType()
            if valueType.IsGenericType then
                let baseType = valueType.GetGenericTypeDefinition()
                if baseType = typedefof<Map<_,_>> then
                    let kvs = value :?> System.Collections.IEnumerable
                    writer.WriteStartObject()
                    writer.WritePropertyName("pairs")
                    writeArray (writeKeyValuePair serializer) writer kvs
                    writer.WriteEndObject()   

    override x.ReadJson(reader:JsonReader, objectType:Type, existingValue:obj, serializer:JsonSerializer) =
        let argTypes = objectType.GetGenericArguments()
        let tupleType = FSharpType.MakeTupleType(argTypes)
        let constructedIEnumerableType = typedefof<IEnumerable<_>>.GetGenericTypeDefinition().MakeGenericType(tupleType)
        if reader.TokenType <> JsonToken.Null then
            doRead reader // "pairs"
            let kvs = readArray (readKeyValuePair serializer argTypes) reader
            doRead reader // }
            let kvs' = System.Array.CreateInstance(tupleType, kvs.Length)
            System.Array.Copy(kvs, kvs', kvs.Length)
            let methodInfo = objectType.GetMethod("Create", BindingFlags.Static ||| BindingFlags.NonPublic, null, [|constructedIEnumerableType|], null)
            methodInfo.Invoke(null, [|kvs'|])
        else
            box Map.empty

The MapTypeConverter can be added to the list of converters used by the Newtonsoft JSON library:

let settings = 
    let jss = new JsonSerializerSettings()
    jss.Converters.Add(new MapTypeConverter())
    ...
    jss

Add a couple of helper functions:

let ofObject payload = 
    JsonConvert.SerializeObject(payload,Formatting.None, settings)

let toObject<'a> js = 
    JsonConvert.DeserializeObject<'a>(js, settings)

Then F# Maps can be converted to and from JSON like so:

let m = List.zip ["a";"b";"c"] [1..3] |> Map.ofList
let j = Json.ofObject m
let o =Json.toObject<Map<string,int>> j
m = o

Resulting in the following:

val m : Map<string,int> = map [("a", 1); ("b", 2); ("c", 3)]
val j : string =
  "{"pairs":[{"key":"a","value":1},{"key":"b","value":2},{"key":"+[16 chars]
val o : Map<string,int> = map [("a", 1); ("b", 2); ("c", 3)]
val it : bool = true

1. I use the functional programming style as much as possible (notonlyoo.org)
2. In the few places I can't I am very very very careful.

That's it. Everything else follows from these guiding principles. This is not specific to F# but F#, and other languages like it, strongly encourage and support this approach.

Whole classes of errors disappear because of the following:

1. No nulls
   • there are no nulls, there are no null reference exceptions
     • F# has types that express absence more safely, Options, Choices ....
2. Immutable data
   • no complex state interaction errors
     • F# is immutable by default
3. Very strong type system
   • the compiler works hard to stop me writing nonsense
     • F# type inference and repl gives immediate feedback on nonsense

4. Composition of small functions

   • a small function is easy to reason about, easy to test, and it will continue to work when composed with other small functions, if there is an error it will be in a single small function. Reuse is pervasive.
     • F# supports first class functions
     • F# has a syntax friendly to function definition and composition

5. Asynchronous programming abstractions

   • no tedious error prone chaining, no asynchronous heisenbug errors
     
     • F# asynchronous workflows make composing asynchronous computation easy and error free
     • F# agent abstraction makes dealing with state and concurrency easier to reason about

6. Higher-order functions over collections

   • no indexing errors, boundary errors
     • F# has a rich library of functions over collections
7. Units of measure
   • no calculation errors caused by unit misunderstandings
     • F# supports typing of numeric types

There is no magic to this. The functional programming style is a simple and safe paradigm in which to express solutions. F# provides excellent support for this style.

Comparison of Lines of Code

Summary

Here are the numbers:

Metric	C# Project	F# Project	The F# Difference
Useful lines	183856	7112	26x
Comment lines	57624	182	32x
Null check lines	3036	27	112x
Blank lines	33678	1416	24x
Brace lines	62282	265	235x
Team Size	7	2	3.5x
Project Duration	5 years	4 months	15x
Defects since go live	too many	zero	tending to infinity

Conclusion

WTF C#!!, OMG F#!!

... more seriously

It is hard to draw any conclusions comparing different projects written by different teams using only various line counts as a metrics.

I am both a C# dev and an F# dev. I can only offer subjective anecdotal evidence based on my experience of delivering projects in both languages (I am too busy delivering software to do anything else). I will leave rigour to others (btw let me know if you write a code analyser that can produce metrics for both C# and F#, I would love to run it on the projects I have and report the results).

That said, the one stat in the summary that I find most compelling is the defect rate. I have now delivered three business critical projects written in F#. I am still waiting for the first bug to come in. This is not the case with the C# projects I have delivered. I will continue to monitor and report on this. It might be that I am just on a lucky streak, but I suspect that the clarity and concision of F# code contributes greatly to its correctness.

Updates:

More details on the F# project here.

More details on the scarcity of bugs in F# code here.

Saxon Matt performs another C#/F# code comparison here.

R has many useful functions for slicing and dicing data, particularly if you work in an industry built on CSV files. What is missing though are some of the function operators that I am used to using from my work with F#. This means I keep having to type brackets to terminate long expressions:

(a(b(c(d(2)))))

Fortunately functions are first class citizens in R and you can define infix operators. So the operators I am used to using in F# (>>, <<, |> and <|) are only a function definition away:

"%>>%" <- function(a,b) {
   function(x) {
     b(a(x))
   }
}

"%<<%" <- function(a,b) {
  function(x) {
    a(b(x))
  }
}

"%|>%" <- function(x,f) {
  f(x)
}

"%<|%" <- function(f,x) {
  f(x)
}

Now I can write function compositions without the hefty bracket tax:

(a %>>% b %>>% c %>>% d)(2)

and pipeline function applications too

2 %|>% function(x) { 2 * x } %|>% function(x) { 2 + x }

Now my R code can look a bit more like my F# code.

The introductory slide pack is here.

The code samples I will be covering are available on BitBucket here.

The FSharpEnt library is here.

This site is aimed at capturing the zeitgeist of the nascent Not Only OO movement.

Fortunately installing Visual Studio 2003, .NET 1.1 and all of the associated service packs gave me plenty of time to consider my options. By the time all the installers had completed I had decided to use node.js, implemented and had running my first node.js server using node's express web development framework. As it states in the excellent express guide and using the command line node package manager (npm), this is as simple as:

// Install express
$ npm install express
// Create server
$ express apistub && cd apistub
// Install dependence
$ npm install -d
// Run the server
$ node app.js

To add the API handlers to match the specification required a little extra effort:

// Login API
app.post('/apistub/controllers/ApiLogin/', function(req, res) {
  req.session.identifier = uuid.v4();
  console.log("LoginAPI [%s]", req.session.identifier);
  res.writeHead(404, authenticatedCookie(req.session.identifier));
  res.end();
})

// Logout API
app.post('/home/common/jsp/smlogout.jsp', function(req, res) {
  console.log("LogoutAPI [%s]", req.session.identifier);
  req.session.destroy();
  res.writeHead(302);
  res.end();
});

// Entry API
app.post('/apistub/controllers/:api/', function(req,res) {
  var xmlBaseFolder = 'api\\entry\\';
  var xsdBaseFolder = 'schema\\entry\\';
  handleApiCall(req,res,xmlBaseFolder,xsdBaseFolder);
});

// Exit API
app.post('/exit/controllers/:api/', function(req,res) {
  var xmlBaseFolder = 'api\\exit\\';
  var xsdBaseFolder = 'schema\\exit\\';
  handleApiCall(req,res,xmlBaseFolder,xsdBaseFolder);
});

The functional APIs send an XML document in the body of the request and return another XML document in the body of the response. Ideally I would like to validate the request XML against the schemas published in the specification. This is where things got tricky. As a .NET developer I am used to having libraries readily to hand to solve such problems. The node runtime is very minimal and XML schema validation is not something you get out-of-the-box.

Eventually I decided to fire-up my newly installed Visual Studio 2003 and create a .NET 1.1 console application that accepted an XML file and XML schema file as arguments and validated the XML against the schema using the usual (circa 2003) .NET libraries. I could then execute the XML validation application from within node like so:

var handleApiCall = function(req,res,xmlBaseFolder,xsdBaseFolder) {
  console.log("%s [%s]", req.params.api, req.session.identifier);
  // Validate session cookie.
  if (req.cookies.smsession != req.session.identifier) {
    res.writeHead(401, notAuthenticatedCookie(req.session.identifier));    
    res.end();
  } else { 
    // Validate request xml against request schema.
    var xmlFile = xmlBaseFolder + req.params.api + 'Request.xml';
    var schemaFile = xsdBaseFolder + req.params.api + 'Request.xsd';
    fs.writeFileSync(xmlFile, req.body.INPUT);
    var child = spawn(validateXml, [xmlFile, schemaFile]);
    child.stdout.on('data', function(data) {
      console.log('stdout: ' + data);
    });
    child.on('exit', function(code){
      if (code == 0) {
        // Request is valid so send response xml.
        var responseXmlFile = 
            xmlBaseFolder + req.params.api + 'Response.xml';
        var responseXml = fs.readFileSync(responseXmlFile);
        res.writeHead(200, authenticatedCookie(req.session.identifier));
        res.end(responseXml);
      } else {
        // Request is invalid so send error xml.
        res.writeHead(500, authenticatedCookie(req.session.identifier));
        res.end(errorInvalidXml);
      }
    });
  }
}

The response cookies were set using:

var authenticatedCookie = function(identifier) {
  return [['Set-Cookie', 
    'APIAUTHENTICATION=xxxx; APIAUTHORIZATION=xxxx; SMSESSION=' 
    + identifier + 
    '; TEST_STUB']];  
}

var notAuthenticatedCookie = function(identifier) {
  return [['Set-Cookie',
    'APIAUTHENTICATION=xxxx; APIAUTHORIZATION=xxxx; SMSESSION='
    + identifier +
    '; TEST_STUB']];
}

Job done! Integration testing can proceed using a simple, lightweight, self-contained HTTP server to mimic the behaviour of the third party API. I liked the results and can see it being used for stubbing other HTTP APIs in my landscape.

An alternative .NET only approach would have been to use the shiny new ASP.NET Web API. However, this would have introduced .NET 4 dependencies into the legacy application and, at the time of writing, the support for cookies is not good - although it is on its way.

The graph above (you will not see anything in IE8 and below) represents a domain model for a power market comprising settled (past), trading (present) and forecast (future) data.

Each node in the graph represents something of interest in the market, e.g. energy production, energy consumption, temperature, wind, energy price, capacity, flow, dynamic forecast, foreign exchange etc. modelled as a collection of time series data over a rolling time window.

Some of the nodes subscribe to market datastreams and update their state on receipt of market data messages. Once their state is updated they notify connected nodes which in turn update their state based on the newly arrived data. For example, the dynamic forecast nodes would trigger a recalculation of their market forecast.

NoOO (Not Only Object Oriented) + NoSQL

OO is supposed by some to be good for domain modelling and a possible implementation for the domain model would be as an object graph persisted in a relational database. However, inspired by Joe Armstrong's assertion that Erlang is the most objected oriented language, I opted to implement the domain model as a collection of message passing actors - this has some very useful consequences.

The domain model is concurrent. Updates to a node asynchronously and concurrently trigger updates to other nodes.

Each node in the network is the guardian of its own state and is responsible for its persistence in a document database. Gone are the complications of ORMs and managing units of work. The persisted state is eventually consistent, ideal for a domain model being continually updated in real-time where consistency is a slippery concept.

The implementation used F# mailbox processors for the actors and RavenDB for the document store (a previous post presented the concept for this, but now the implementation is complete). The visualisation uses d3 (hover the nodes to see the labels, click and drag to rearrange nodes).