## Blog: Ramón Soto Mathiesen

### Argue for robustness

So many of us working on a daily basis with F# always claim that we are able to make more robust and bulletproof applications with fewer lines of code than we would need if we used the C’s (C,C++,C#, …). So how do we achieve this?

I will try to explain this in a less theoretical way so people don’t get lost in translation. Besides I will provide the usual foo/bar examples as well as a basic real world example.

Let’s start by defining a couple of functions:

We can all agree that the function look pretty robust right? The main operation is performed inside a try/with statement, for the C’s think of it as a try/catch statement. Now if the operation fails, 2/0 is possible in foobar, the log function will be called with the input parameter x and the exception ex. What seems a bit strange in the functions is that both operations, try/with, finishes in Some/None. This is one of the powerful features of F#, Some/None is a union type between the type and no-value. In other words, either you have a value of the given type Some of 'a or you don’t any value at all None. If you are familiar to ML-like languages, you will have seen this as datatype 'a option = NONE | SOME of 'a, in a identical form for OCaml as type 'a option = None | Some of 'a (you might be able to argue that F# is the OCaml .NET version) and finally as data Maybe a = Just a | Nothing in Haskell.

Remark: Just for correctness, the log function is implemented with the Console.WriteLine method, which is threadsafe and in combination with sprintf/"%A", to make it generic.

### Robustness but verbosity

Now that we have the robust functions. lets combine a couple of them together as we do when we write code:

We can see that we get a type error as the function bar takes an int as input and not an int option type. Let’s re-write the code in a correct way:

I think it’s easy to argument for robustness and correctness but you might think: “Less code you say?”. And you are right, this kind of implementation would be really annoying to write for every single function you would have to pipe the result to.

The more theoretical approach to simplify the code but still maintaining correctness, would be to implement the Maybe Monad (monads are called Computation expressions in F#):

Where we can use the monad to write the previous code as:

By using the monad we don’t have to write function | Some v -> some_function v | None -> None for each time we pipe the value but, it’s still some kind of annoying having to write all the temporary variables x,y,z in order to get the final result. The ideal scenario would be to write the following code:

But this is not possible as we need to bind the functions together. Actually that is what let! does. The let! operator is just syntactic sugar for calling the Bind method.

Remark: The Maybe Monad can be implemented in less verbose code by using the built-in Option.bind function:

### Infix operator to the rescue (»=)

So how do we get as close to 2 |> foo |> bar |> foobar but without compromising on correctness and robustness? Well the answer is quite simple

What we need to do is to introduce the following infix operator:

Now we can combine functions together in the following manner:

Which is pretty close to what we wanted to achieve, 2 |> foo |> bar |> foobar, right?

Another thing to have in mind when using binded functions is to think of the bind as how Short-circuit evaluation works. SCE denotes the semantics of some Boolean operators in some programming languages in which the second argument is executed or evaluated only if the first argument does not suffice to determine the value of the expression. For example: when the first argument of the AND function evaluates to false , the overall value must be false; and when the first argument of the OR function evaluates to true, the overall value must be true. Binding functions is more or less the same, where the output from the first function is bounded to the input of the second. If the first function returns None, then the second is never called and None is returned for the whole expression. Let’s see this in an example using foobar and 0 as input:

After foobar throws an exception and return None, none of the other following foobar functions are evaluated. Cool right?

### Another infix operator to the rescue (|=)

As in real life you might want to get the value of the type and use it in other frameworks that doesn’t have support for Some/None . What you can do is to do something like:

or

This will limit your code to unit = () or to throw and exception. which would be OK if it’s encapsulated in a try/with statement. But sometimes you will just want be able to assign a value that means no change in the final result of the computation. For example: 0 in a sum of integers, 1 in a product of integers, an empty list in a concatenation, and so on. To achieve this I usually implement the following infix operator:

This will now allow us to use the value as the given type and if there is no value then use the specified default value:

Remark: As with the Maybe Monad, this infix operator can also be implemented in less verbose code by using the built-in Option.fold function:

### So let’s use the infix operators on a basic real world example

Now that we have the receipt to create correct and robust one-liner functions, let’s define two functions for this example. The first will return Some array of even numbers from an arbitrary array. And the second will return Some array of the top 10 biggest numbers from an arbitrary array.

For the first function it’s easy to argument for it to never break. If the array doesn’t contain any even numbers, Some empty array will be returned. But for the second function we can see that there will always be returned a Some sub-array of size 10. What will happen when the input array is of a smaller size? Let’s execute the code:

We can see that the first evaluation returns an array of ten even numbers from 2000 to 1982 while the second returns an empty array and logs the out of boundary exception to the console.

Remark: Please never write code like this, it’s always more desirable to check for the size of the array than to get an out of boundary exception. This was just to make a point of bulletproof functions and hereby applications by using F#.

### Conclusion

Well now that I gave you the receipt for creating small robust and bulletproof functions, or Lego blocks as I call them, that can easily be tested for correctness and robustness, now it’s your turn to create your blocks, combine them to create bigger blocks and make robust applications. Happy coding and remember to have fun.

### Where to go from here

Finally if you want to get a deeper understanding of what is happening here, please spend an of your life watching this amazing video:

I’ve been employed @ Delegate A/S for about a year. In this short period I have created some tools for our CRM developers/consultants in order to make working with Microsoft Dynamics CRM more smoothly. One of these tools is DAXIF# which is defined as A set of tools that in combination with other MS tools make it easier to work with CRM/xRM on a daily basis (also for developers who are not familiar with the platform)

The interface is through F# script files that can be executed from a command prompt or directly from Visual Studio (the best IDE for F# scripts):

The main reason to use F# to create this set of tools is as usual the same sales speech we use to give again and again and again: Error free projects with smaller code base, where there is a need to use one programming language (no. Bat files or PowerShell, …). Where big data, external data sources, parallelism, concurrency, asynchronous processor are trivial to use.:

One of the things I learned from this project was that I actually could make F# scripted and self documented Unit Test that can be executed without having to build the final .DLL:

DAXIF# is proprietary so you will need a license to use it. We don’t provide licenses to other CRM Partner/competitors

Keep updated for the upcoming website and NuGet package.

• Link to slides from MF#K (English): Slides

• Link to slides from CRM Partner Community (Danish): Slides

• Geek alert: A few references to Dota 2 might appear in the code:

or in the project structure:

I tried to implement the bitonicsorter I wrote about in my masters thesis. The result is the following code:

It still lacks of speed, even with the use of the included libraries Array.Parallel or Async.Parallel / Async.RunSynchronously (fork/join) but it was fun to write as usual.

REMARK: It’s much more readable than the code I wrote back in the days …

Last June I was in Madrid for TechEd Conference. The main focus was The Cloud. Microsoft has actually done a really good job and the platform is very mature. I’m not going to lie by saying that I will prefer to host everything in the cloud than doing it on-premise. A few PowerShell scripts and voila you got yourself the desired environments. And with the instance slider, you got yourself the amount of instances that you could need for a specific period. Try to do something similar with your on-premises infrastructure. Another awesome feature is that from now on you will only pay for the environments if they are running. This means that DEV and TEST can be shut down while they are not being used:

Lucian Wischik gave three talks with regards to async arriving to C# 5.0 (no callbacks needed). Hmmmm, I wonder were we have seen this before, who said F#?

Another really interesting talk was David Starr regarding Brownfield Development. We all have seen this huge amount of spaghetti code right?

But how do we actually ensure that we don’t get to this point? And how do we avoid that methods grow to become huge? I think the main problem is because we use a toolbox that actually allows this to happen, mostly cos it’s part of it’s verbosity

… well the answer isn’t that difficult. Even though Dustin Campbell gave a good talk, Microsoft really needs to understand that they are not going to catch the businessmen attention by showing a how F# is really good to solve Project Euler problems. What Microsoft needs to do, is to show on one of their platforms how using F# provides a more clean and robust way to make quality software, and we might able to help out on this one, stay tuned:

Finally, not everything in Madrid had to be hard work, there were also time to some pleasure:

As it has been a while since I went to TechEd and because I have to give a small talk for the rest of Delegate A/S employees, I needed to get the PowerPoints and some videos. I was a bit bored and cos I love F# I decided to make a small file crawler. Things I noticed while creating the app is how simple it is to convert from a sequential to parallel app. Just convert the sequence to an array and then apply parallelism, as simple as that. The only issue I found while converting the app to run in parallel is that printfn is not thread-safe so a few changes to Console.WriteLine and sprintf and voila, it’s 100% parallel. This is one of the strong sides of F#, like any other .NET language, it has access to the whole Frameworks API.

Remark: There is no need to actually change the algorithm, so it is still as readable as it was before. Like stated before, change three lines and voila, the app runs in parallel …

The crawler is called from a terminal like this:

And will save the files and write the following output:

p.s.: It wouldn’t be that difficult to convert the code above to a generic website file crawler …