Category Archives: F#

Red mist

Sometimes you get so upset about something you need to blog about it, and ranting on Twitter, Facebook and Channel 9 comments just did not quite seem enough.

The insult, and the injury

I watched a Channel 9 talk about the “future of C# and VB” by Jay Schmeltzer from DEVintersection where he went over the future of the .NET stack, and started out by looking over the Stack Overflow statistics of programming languages that I have addressed before. He showed the graph of Most Popular Technologies showing C# placed prominently fourth behind Java, SQL and JavaScript, then Jay showed the category Most Loved languages, where Microsoft  have a runaway hit with F# on third place, and then C# way down on 10th place. Obviously, VB was right on top of the Most Feared, but that you knew already. Jay expressed much pride in having C# all the way up on 10th of most loved languages and then said “and we have Microsoft’s F# up here on 3rd, but that is of course more of a … well,  C# is of course mainstream in a different way”. So in other words, not even a pretence that F# is a first class citizen in .NET.

Contrast with Apple. From almost single handed creating Objective C into something that is in existence and popular despite the crushing superiority in funding and mindshare of C++ – Apple basically told everybody that (the F# clone) Swift is it from now on. They basically did a VB6 -> C# sort of story, telling everybody that they were welcome to use that old stuff but they really should get on board with the modern technologies.

Contrast that with the above statement from top brass at Microsoft.

So basically, in this blog I am trying to collect ways which a dark matter C# developer can just start using F# today thanks to the extremely ambitious efforts of the friendly and hard-working F# community, and show to the extreme extent Microsoft isn’t bothering at all – ignoring the goldmine they are sitting on. I’m trying to find ways which make things easier for existing Microsoft-focused developers, so I will be collating the things you can use to go F# today for the crummy ASP.NET LOB apps that make up the bread and butter of the C# world.

The comeback

My goal is providing ways which you can go F# today, and immediately write less code with fewer bugs that do the things your C# code does today. You will eventually discover cooler things, like package management using Paket (wich support Nuget package streams and maintaining dependencies directly from GitHub or similar) amd the very F# web framework and using FAKE as a build system rather than MSBuild, which helps if you have complex builds where you would like to not mess with XML and rather read F# code. You may perhaps find other ways to persist data that are more natural to use in F# and you will have little problem learning them once you get over the hump, but just to make the barrier to entry extremely low, let’s keep things familiar and non-scary. The things that would come for free if Microsoft had devoted more than a fraction of means towards F# in Visual Studio is the templating that makes C# so easy to use when creating websites and web services. To achieve that ease-of-use we have to rely on the community, and they have despite the odds come up with a few competitive options over the years. I have compiled these on my F# for C# people page which I hope to keep updated.

Desktop OS for developers

The results of the latest StackOverflow Developer Survey just came out, showing – among other interesting things – that Windows is dying as a developer OS. Not one to abandon ship any time soon I’d still like to offer up some suggestions.


  • Make the commandline deterministic.
  • Copying files across the network cannot be a lottery.
  • Stop rebooting UI-frameworks
  • Make F# the flagship language

Back in the day, Microsoft through VB and Visual C++ overcame some of the hurdles of developing software for Windows – then the only, effectively, desktop OS in the enterprise. Developers, and their managers, rallied behind these products and several million kilometres of code was written over a couple of decades.

The hurdles that were overcome were related to the boilerplate needed to register window classes, creating a window and responding to the basic window messages required to show the window in Windows and have the program behave as expected vis-a-vis the expectations a Windows user might have. Nowhere in VB6 samples was anybody discussing how to write tests or how, really, to write good code. In fact, sample code, simplified on purpose to only showcase one feature at a time, would not contain any distractions such as test code.

When Classic ASP was created, a lot of this philosophy came a cross to the web, and Microsoft managed to create something as horrible as PHP, but with less features, telling a bunch of people that it’s OK to be a cowboy.

When the .NET framework was created as a response to Java, a lot of VB6 and ASP.NET  programmers came across and I think Microsoft started to see what they had created. Things like Patterns & Practices came out and the certification programmes were taking software design and testing into consideration. Sadly, however, they tended to give poor advice that was only marginally better than what was out there in the wild.

Missed the boat on civilised software development

It was a shock to the system when the ALT.NET movement came out and started to bring in things that were completely mainstream in the Java community but almost esoteric in .NET. Continuous integration – unit testing – TDD – DDD. Microsoft tried to keep up by creating TFS that apart from source code version in had ALM tools to manage bugs and features as well as a built-in build server but it became clear to more and more developers that Microsoft really didn’t understand the whole thing about testing first or how lean software development needs to happen.

While Apple had used their iron fist to force people to dump Mac OS for the completely different, Unix-based operating system OS X (with large bits of NextStep brought across, like the API and InterfaceBuilder) – Microsoft were considering their enterprise customers and never made a clean break with Gdi32. Longhorn was supposed to solve everything, making WPF native and super fast, obsoleting the old BitBlt malarkey and instead ushering in a brighter future.

As you are probably aware, this never happened. .NET code in the kernel was a horrible idea and the OS division banned .NET from anything ever being shipped with Windows, salvaged whatever they could duct tape together – and the result of that was Vista. Yes, .NET was banned from Windows and stayed banned up until Powershell became mainstream a long, long time later. Now, with Universal Windows Apps, a potentially viable combo of C++ code and vector UI has finally been introduced, but since it is the fifth complete UI stack reboot since Longhorn folded, it is probably too little too late and too many previously enthusiastic Silverlight or WPF people have already fallen by the wayside. Oh and many of the new APIs are still really hard to write tests around, and it is easy finding yourself in a situation where you need to install Visual Studio and some SDK on a build server, because the dependency relies on the Registry or the GAC rather than things that come with the source.


As Jeffrey Snover mentions in several talks, Windows wasn’t really designed with automation in mind. OLE Automation possibly, but scripting? Nooo. Now, with more grown-up ways of developing software – automation becomes more critical. The Windows world has developed alternate ways of deploying software to end-user machines than work quite well, but for things like automated integration tests and build automation you should still be able to rely on scripting to set things up.

This is where Windows really lets the developer community down. Simple operations in Windows aren’t deterministic. For a large majority of things you call on the command-line  – you are the only one responsible for determining if the command ran successfully. The program you called from the command-line may very well have failed despite it returning a 0 exit code. The execution just might not have finished despite the process having ended, so some files may still be locked. For a while, you never know. Oh, and mounting network drives is magic and often fails for no reason.

End result

Some people leave for Mac because everything just works, if you can live with bad security practices  and sometimes a long delay before you get some things like Java updates. Some people leave for Linux because if you script everything, you don’t really mind all those times you have to reinstall because thing like a change in screen resolution or a security update killed the OS to the point you can’t log in anymore, you just throw away the partition and rerun the scripts. Also, from a developer standpoint, everything just works, in terms of available tools and frameworks.

What to do about it

If Microsoft wants to keep making developer tools and frameworks, they need to start listening to the developers that engage whenever Microsoft open sources things. They most likely have valuable input into how things are used by your serious users – beyond the tutorials.

Stop spending resources duplicating things already existing for Windows or .NET as that strikes precisely at the enthusiasts that Microsoft needs in order to stop hemorrhaging developers.

What is .NET Core – really? Stop rewriting the same things over and over. At least solve the problems the rewrite was supposed to address first before adding fluff. Also – giving people the ability to work cross-platform means people will, so you are sabotaging yourselves while building some good-will, admittedly.

Most importantly – treat F# like Apple treats Swift. Something like – we don’t hate C# – there is a lot of legacy there but F# is new, trendier and better. F# is far better than Swift and has been used in high spec applications for nine years already. Still Microsoft after years of beta testing still manages to release a JITer that has broken tail call optimisation (a cornerstone of functional runtimes as it lets you do recursion effectively). That is simply UNACCEPTABLE and I would have publicly shamed then fired so many managers for letting that happen. Microsoft needs to take F# seriously – ensure it gets the best possible performance, tooling and templating. It is a golden opportunity to separate professional developers from the morons you find if you google “ login form” or similar.

In other words – there are many simple things Microsoft could do to turn the tide, but Im not sure they will manage, despite the huge strides taken of late. It is also evident that developers hold a grudge for ages.

F# puzzle

One of my colleagues at Jayway launched a functional puzzle and solicited responses via Github gists. The challenge was as follows:

  1. Write a function that, given a sequence of either positive or negative integers, returns true if any subset of the list sums up to zero. Eg:
    find-solutions ([-7 4 3 8 -5]) => true
    find-solutions ([-6 2 3]) => false
  2. Make it work with any number, not just zero. Eg:
    find-solutions (0, [-7 4 3 8 -5]) => true
    find-solutions (13, [-7 4 3 8 -5]) => false
  3. Make it return all matching sequences, instead of a boolean. Eg:
    find-solutions (0, [-7 4 3 8 -5]) => [ [-7 4 3] [-7 4 8 -5] ]
    find-solutions (13, [-7 4 3 8 -5]) => []
  4. Make it take any predicate for the sum, not just equal to a number. Eg:
    find-solutions (isZero, [-7 4 3 8 -5]) => [ [-7 4 3] [-7 4 8 -5] ]
    find-solutions (isOdd, [-7 4 3]) => [ [-7] [3] [-7 4] [4 3] ]

Of course, me being an F# n00b I ended up at StackOverflow within hours of trying my hand at this, and I also asked among code monkeys on Facebook,  so I will not submit an answer is it wouldn’t be my own. My colleagues went ahead and figured out solutions on their own rather than use Google engineering like I did.

Anyway, as you can imagine, the first bit is the hard one. With higher order functions, delegating the actual filtering is done easily thereafter by supplying  the comparer function as a parameter.

So what do you do? I looked at many solutions, but couldn’t manage to use the comme il faut solution with a permutation tree, but went with a list of permutations instead which I then could trivially recurse through to see if I ever find a match.

If you are using Google engineering to solve F# problems, be aware that the old function Seq.map_concat has been renamed Seq.collect, which is a clear improvement.

In my case I found my permutation function on StackOverflow, provided by the excellent Tomáš Petříček, see blogroll, and just added my c0dez to find matches. This is from a console app, so hence the EntryPoint business.

let rec permutations list taken = 
  seq { if Set.count taken = List.length list then yield [] else
        for l in list do
          if not (Set.contains l taken) then 
            for perm in permutations list (Set.add l taken)  do
              yield l::perm }

let rec isMakingZero acc lst =
    match lst with
     | [] -> false
     | a :: tail -> (acc + a = 0) || isMakingZero (acc + a) tail 

let rec testpaths pathlist =
    if Seq.length pathlist = 0 then
        isMakingZero 0 (Seq.head pathlist) || testpaths (Seq.skip 1 pathlist)

let main argv = 
    printfn "First %A"  (testpaths (permutations [1; -2; 3; -5] Set.empty))
    printfn "Second %A" (testpaths (permutations [1; -3; 2; -5] Set.empty))
    0 // return an integer exit code


As you can imagine, you just supply a function to testpaths that then gets passed down to isMakingZero, which should be renamed, in order to solve the remaining tasks.

F# 3 and Raven DB

Wow, this was pretty interesting. I am definitely trying this right now. I didn’t realize F# was Raven hostile, and also this unintended benefit of TypeProviders need to be announced off of the roof-tops.


Ok so I have blogged about these to before. Previously, F# didn’t have brilliant support for Linq. F# Expressions couldn’t `easily` be converted to the Linq expression trees that the RavenDB API required. This caused somewhat of a mis-match between the two which made Raven difficult but not impossible to use from F#. My previous blog introduced a library which is available for Raven clients prior to version 2.0, to bridge this gap, and tried to make Raven more natural to use from F#. However as of Raven 2.0 this library has been removed. The reasons are explained here. I don’t disagree with the reasons ayende cut the support
I wouldn’t want to support something I had little knowledge of either. However things have changed…. 🙂

The advent F# 3 and query expressions

So we are now in the era of F# 3.0 and things have changed somewhat. F#…

View original post 524 more words