Software in general

Real world F#: my experience (part two)

The second project I recently completed in F# is a completely different animal. While the first one is a pet project I’ve put together in my spare time (with no deadline at all), this one has been a full-time work for my company (for this reason I cannot disclose some details or share source code). Additionally, time available was limited. Very limited. Like 2 weeks limited. That’s 10 working days plus a 2-days emergency buffer.

A load simulator tool

My company produces a high performance client-server platform that ships with our own proprietary database engine. After some important changes to the server and database codebase, we needed to test the system’s behavior under heavy load, i.e. when a large number of users are connected and firing queries.

As you can guess, hiring and coordinating hundreds of people to load the system the way you need is very impractical, if possible at all. Maybe it’s doable if you have your own Army of Clones, but we don’t have one, so we had to somehow automate the process. Keep in mind that the server interface is proprietary, i.e. it’s not http, SQL, or anything similar: we have to go through our library and API to access the server. For that reason we could not use any existing tool.

The application I was going to build was meant for internal use but it was clear that something usable by non-über-geeks would have been nice to have at some point (for example to help sizing hardware for large customers). Anyways, being the deadline very close, it was imperative (no pun intended) to focus on the most important stuff.

Writing your own DSL

I decided to define an external DSL to describe the simulation scenarios. The language would let you express the creation of users, connections, queries, pauses, etc. in a simple way.
The second decision was to use F#. Fortunately nobody objected (again no pun intended). I was to work on the project alone, so I could basically use whatever I liked.

Once I defined the grammar I went to step 2, i.e. parsing. Obviously I was not going to reinvent the wheel by rolling out my own lexer and parser so the choice was between parser generators (FsLex/FsYacc, Irony for C# & co.) and combinator libraries à la FParsec. After taking some advice from the great F# community on Twitter (thanks Robert!), I opted for FParsec. I admit it looked a bit intimidating, but the idea of not introducing a tooling step in the build process was appealing, plus I had never used a combinator library before and was curious.

Here starts the amazement. As mentioned, at first FParsec looks slightly cryptic, but once you get the main concepts and get over a few gotchas it just “clicks”. You quickly reach a point where reading the parser code is almost like reading the grammar definition. Making changes is a matter of a few minutes with a very low risk of introducing new errors. FParsec gives you an enormous flexibility and even if the learning curve is steeper than learning parser generators I suggest you look at it if you’ve never done it before. The official documentation is great too.

Anyways, in a few days I had a parser that lifted the input program to the abstract syntax tree. Sweet!

Note: in case you are wondering, the language I defined was not super complicated but also not trivial. It supports regular loops as well as parallel ones (iterations are executed in parallel), nested loops and a plethora of options on all the various commands. I opted for a rich syntax that results in programs that are almost written in natural language. I cannot disclose all the details, but you can get an idea by looking at the screenshots.


Walking the tree

Second amazement: thanks to discriminated unions and pattern matching, walking the syntax tree is an incredibly fluid and easy process. The code is so compact and elegant that I keep opening that file just to look at it. No boilerplate, no class proliferation, no wasted characters. Just the code.

Unfortunately I could not leverage the powerful F# concurrency features to run parallel loops because the client library that interfaces with our server is not thread-safe, so all I could do was starting new threads with each its own separate AppDomain. My skills on asynchronous workflows & co. are still limited so I don’t know if there’s a better way. If that’s the case, I’d love to hear your feedback in the comments.

GUI and extras

With parsing and interpreting done, the bulk of the job was over. I just needed to add logging and a less geeky interface than the command line. With room to spare, I created a WPF GUI that controls the execution and reads logs to display status and stats. This was nothing particularly exotic, but I was able to fit in some nice touches like a graphical timeline to represent operations executed on the different threads. I wrote the GUI in XAML/C# using MVVM-Light. The parser/interpreter runs in a separate process, so that in case of a crash (not a remote possibility when you are pushing the hardware limits) the GUI keeps running and tells you what happened.


So 10 days had passed and this is what had been done:

  • the DSL grammar definition
  • a parser and an interpreter for it. It took slightly more than necessary because I had to learn FParsec along the way (this talk by Robert Pickering has been very helpful).
  • a GUI with some bells and whistles

plus some extras (that as you know better than me, are very time consuming):

  • a (admittedly basic) distributable package
  • the syntax highlighting definition for Notepad++ Smile
  • several code samples that show the DSL capabilities
  • the user manual and language specification (I got some help with that)
  • a tutorial

Developing the GUI and producing the extras went at normal speed, but I’m positive that writing this parser and interpreter in C# would have taken me close to the ten days alone. Maybe my standards are low, I don’t know, but I’m honestly blown away by what I could achieve in such a short time. Also notice that I’m much more experienced in C# than in F#.

Truth to be told, I had another advantage: this project was done in the year ending period when several people are on holidays and the office is very quiet. I also put in some late evenings, but I have a family with two kids, I just cannot code 24*7 even if I wanted.

The stars of the show

The goal of this post is not telling the world how fast I work. It’s impossible for anyone to judge if a project would have needed 2 or 100 days without knowing all the details. No, I’m writing this because I know all the details and I know that F# gave me a huge advantage. Much more so than I imagined when I started.

These are things that I think make F# ideal for a project like this:

Higher order functions

These are what allow libraries like FParsec to exist, amongst the rest.

Discriminated unions, tuples and pattern matching

This trio is worth alone the price of entry. They make for very terse code and bring other great advantages on the table as well.

It works the first time

I still don’t get why it is so. Maybe it’s because of the lack of nulls. Maybe it’s because (as I’ve written in part one) I think functional programming forces you to think more and write/debug less. The net result is that when I write F# I mostly get it right the first time. Because of the higher-order functions there are less corner cases that suddenly appear and crash everything.

Now most of these features are available in several functional languages, however the seamless .NET integration was fundamental in my case (the libraries I had to use are .NET), and some F#-only constructs make coding fun and speedy at the same time.


If you’re not living under a rock (like I’m literally doing right now –but that’s another story) you’ve sure heard of F#. Maybe you’ve even seen some examples, but as I’ve heard many times from C# developers, they looked incomprehensible. Don’t let that stop you, it’s just not true. If you’re new to functional programming it looks that way because F# is (mostly) a functional language, i.e. you’re not only learning a new language, you’re learning a new paradigm. A different way of thinking of your programs. It does take some effort, for sure. Is it worth it? It’s up to you to decide. To me, getting back to functional programming with F# after several years of OOP/C# has been a real breath of fresh air.

If you decide to learn more, here are some great places to start:

Advice for getting started with F# by Richard Minerich
An overview of functional programming by Dorian Corompt (recursion, lists, more to come…)

I suggest starting with the basics: you can already accomplish a lot with just lists, sequences, tuples, unions and pattern matching. When you feel ready you can move on to the more advanced topics.
Have fun!

Again, many thanks to Steffen and Samuel for the feedback!

When to unit test private methods?

in TDD you are often confronted with the question “should I restrict my unit test to public methods or include private ones as well?”.

There isn’t a widely accepted consensus and there are many articles around on the subject. I’ve been thinking about it recently and this is my take on it.

A class’ public interface is a contract between the class and its users. When you test a class’ public interface you are trying to ensure that it respects the terms of the contract. So testing a public interface is technically enough to ensure that your program is correct (within the scope of unit testing of course, not in a general sense).

Generally nobody cares how your class is internally implemented as long as it works as advertised. Private members are an implementation detail and are used by public members anyways (otherwise you could just delete them), so tests on the public interface cover private members as well.

However, tests on private methods have a benefit: they can help you spot errors closer to where they are originated. You can see it this way: tests on public methods tell you that something went wrong, while tests on private methods can tell you where something went wrong. In other words they bring some comfort.

While additional comfort is nice to have, it always comes at a cost. These are the main costs you’ll assume when deciding to test private members:

  • You’ll have to write more tests.
  • Maintenance becomes quite stressful as you’ll be changing/adding/removing several tests every time you make a change in a class implementation.
  • You miss the benefits of LDD (Laziness-Driven Development –invented by myself, don’t bother looking in wikipedia). In short, if a developer must write tests for public members only, she will keep them private unless really necessary, just because it takes less work. And keeping the public interface as narrow as possible is a good thing.

In order to answer the original question you’ll have to decide if the benefits are greater than the costs.

Personally, I only test public members and occasionally make an exception for private members that produce values difficult to verify at a glance.

When you combine the output of methods that produce “obvious values” it’s generally easy to spot what went wrong (a null reference, an incompletely initialized object, a wrongly formatted string, etc.). On the other hand, when methods generate for ex. floating point values, it’s difficult to quickly tell if something is wrong, thus it’s difficult to understand what caused a test to fail.

For example, I have a public GetPlexoidMass() function that computes the mass of a plexoid using a complex formula based on sine and cosine*. It made sense for me to test the private Sin and Cos functions as well, so that when a test for GetPlexoidMass turns red it takes me less time to figure out what caused the error without debugging every single step in the formula. The intermediate results inside GetPlexoidMass are floating point numbers and it’s otherwise difficult to understand which one is wrong without an accurate and time-consuming analysis.

This is a case you often find in number manipulation and/or mathematical-intensive libraries, usually found at an application’s core. This kind of function is harder to find the more you move towards the application surface. I would go as far as saying that feeling the constant need to test private members near the application surface may be a code smell and could indicate a problem in the application layering.

I hope these elements may help you make the right choice. If you have other criteria or considerations please let discuss in the comments!


* dummy example of course

Best of Swiss Silverlight 2010

During this year’s Shape 2010 conference in Zurich-Oerlikon, Microsoft Switzerland announced the winners of the Best of Swiss Silverlight 2010 Award in collaboration with the Best of Swiss Web Association, simsa and Netzwoche.


Incredibly my application Trails of Switzerland won the Bronze award. I was completely taken by surprise (not to mention super excited) because I didn’t really expect anything when I started the project. In fact it was just a “weekend project” to try a couple of things. When I saw the award application form I thought it could be worth a try so I polished a bit the front-end and added a couple of cool gadgets.

I was familiar with the competition’s application procedure also because I already did it a few times before for my company (that won this year’s .NET Award by the way).


My application leverages Silverlight’s DeepZoom component to show a full topographic map of Switzerland. The base image is a huge 19 Gigapixels (~3 Gigabytes) JPEG, but movement and zooming is wonderfully smooth.

The tricky part was mapping the GPS data to the map and then keeping content synchronized with the DeepZoom zooming and panning.


Currently Trails of Switzerland is in closed-beta at and will probably never go live (except if someone wants to buy it from me) for the simple reason that copyrights on the maps are incredibly expensive and I cannot afford to buy them “just for fun”.
To be honest I must say that the Swisstopo maps are of incredible precision and quality, but still are way too expensive for a no-profit application.

The good part is that Trails of Switzerland could probably be ported to Windows Phone 7 (with a major restyling of course) as DeepZoom seems to work very smoothly there too.

I’d like to congratulate the other contest winners (Coresystems AG/Misapor, Extrafilm AG, VASP Datatecture AG/ETHZ, Portia AG/Immostreet AG): your applications were really mind-blowing!


The conference was very interesting as well. In particular Bob Muglia should have taken notes from Ronnie’s talk on HTML5/Silverlight. If you have watched the PDC2010 keynote (and the twitter/blog-storm that followed) you know what I’m talking about.

As always Laurent’s Bugnion’s talks were interesting, but also many others were worth the trip (in particular from a Windows Phone 7 and design/UX standpoint).

Moral: you never can tell

Moral of the story is you never know where a weekend project is going to bring you. It seems that someone else also agrees on this. This is one of the things I love in this field.


Thanks to Microsoft Switzerland and most of all thanks to my wife for the continuous support and for understanding when I forget stuff/don’t listen because I’m thinking about code (i.e. most of the time) :-)

The Old New Thing* – a theme for Thunderbird 3

Yesterday I downloaded Thunderbird 3, the latest incarnation of the popular email client. While I like the new features and appreciate the work they put in this release, I don’t like the icons.
They are coherent with the Windows 7 default theme, but I still think they are a bit too bright and distracting. On the other hand the icons in the Thunderbird 2 default theme were perfect on this regard.

Faster done than said – I packaged the old icons in the default TB3 theme. To make things clear, I haven’t created anything, I just took the TB2 icons and put them in the TB3 default theme.
You can download it from here until it gets approved at mozilla addons.

A couple of screenshots: default TB3 theme:


The Old New Thing in action:


*not related to Raymond Chen’s excellent weblog – I’m not very creative in chosing names, sorry.

update: now marked to work with any 3.* version of Thunderbird.

A disturbing trend

Today I was reading through the list of speakers for an upcoming conference on software design, user interaction, etc. It seems that everyone there is working for some company with a cool “web 2.0” name that does something social and collaborative.
Call me stupid, but looking at these companies’ websites I really don’t understand what they do. I mean what they produce. I mean what they sell to pay the bills. The buzzword-meter is at the top end of the scale, but I still don’t get it.

Maybe in two years I will read this post and realize I was wrong (as usually) –for now my buzzword-meter and my BS-meter are very closely related.


Edit: it seems that these people think that social networking will produce huge sales in the next years. You can download the full report here. Yes, the PDF download costs $1749. Maybe I start understanding…

Decisions and why you should remember them

Jim is a developer and is working on the GUI. His GUI has several buttons. Jim decides that the buttons will have the default operating system’s look and feel, which is gray and not too appealing.

The product manager sees the GUI and tells Jim to change the button’s color. They will definitely look better with a blue hue. Jim makes the change.

After two weeks Jim notices that the user can change the application background, and the blue buttons look fugly with any background color except the default one. He shows the product manager the proof that the gray buttons were slightly less sexy but worked better with any background.
The manager is convinced and tells Jim to switch back to the original buttons.

Everyone is happy, except six months later the product manager is using the application and notices the gray buttons. They look dull.
His mind his busy and overloaded: he doesn’t remember the discussion that took place months ago. He calls Jim and tells him to make buttons blue.
Jim’s mind is slightly less busy, he remembers there was a reason why they changed back to the gray buttons. Unfortunately he doesn’t remember why.
He has no way to convince the manager that the gray buttons are better. He walks back to his place and makes the buttons blue again.

Two weeks later…

I admit this example is idiotic, and many things could be said about GUI standards, precise specifications, etc… but that’s not the point.
The point is, you often take decisions that don’t look like decisions. They are not so important to require a formal meeting and nothing formal is written about them. Those “hidden” decisions look innocent but they often make one waste a lot of time.

That’s why I now have a “Decisions” folder on my desktop with plain .txt files that hopefully won’t be needed but probably will.

(And if you are thinking that source control takes care of this, you are only partially correct according to my experience. If your software is quickly evolving, getting back and working a 6 months old piece of code usually takes a lot of time and effort.)