As my regular reader will know, I love anything shiny and new, and so was intrigued when I came across F#. When I was an undergraduate (some 25 years ago, ulp!), I played around with Prolog, and enjoyed the different approach to programming it offered.
However, as my time in front of the computer is at a premium, my F# learning started off with reading books and blog posts late away from the computer, usually last thing at night, and not actually doing any coding. Like most C# developers who come across F#, my initial reaction (other than â€œHey, thatâ€™s shiny and new, I want to learn it!â€) was â€œWhy?â€ If you search around for terms like â€œwhy f#â€ and â€œc# vs f#â€ youâ€™ll find that this is a very common question.
The problem is that the answers arenâ€™t very good. Well, letâ€™s be blunt, there are a lot of lies out there. Now before anyone starts flaming me in the comments (not that anyone ever reads this blog, much less leaves comments), I should point out that the criticisms that I can feel coming areÂ notÂ aimed at the F# community in general, nor are they aimed at F# itself. Itâ€™s the way people try to sell it that annoys me. Iâ€™ve been brooding over them for months, and have written this blog post in my head many times. I feel less strongly about it than I used to, so this will probably be a watered-down version of the original rant.
As an example, I recently came across the following quote in an F# bookâ€¦ â€œNo other .NET language is as easy to use and as flexible as F#!â€ (the exclamation mark was part of the quote, not my addition). Now this sort of comment really annoys me. Firstly, itâ€™s completely unsubstantiated, and secondly, itâ€™s totally subjective.Â AnyÂ language is easy to use and flexible if you learn it well enough. OK, maybe not any, Lisp is clearly only for weirdos (like my brother who loves it!), but letâ€™s not go down that route. F# is not inherently easier than any other languages, and in some ways is quite a bit harder to learn, as it involves a significant shift in thinking to do it properly. Comments like that make me feel they are trying to cover something up, and have a negative effect â€“ apart from the obvious feelings of antipathy towards the author.
Another idiocy was included a popular book by very well-respected member of the F# community, who attempted to sell F# by showing some pseudo-C# code, claiming that you canâ€™t do this in C#, but you can in F#. Hey, isnâ€™t F# great? My immediate reaction was to shout at the book â€œYouÂ canÂ do that in C# if you bother to write it properly!â€ He had deliberately lied about what you can do in C# to try and show how F# is so much better. Given that the book was aimed at C# developers who wanted to learn F#, I thought this was a pretty dumb thing to do. A lot of the book went like this, and I shouted at it a lot!
The blogs werenâ€™t any better. I read no end of them, telling me all the reasons why F# was better, and remained unconvinced. This was partly because some of the reasons given were simply not F# at all. For example, one of the most common reasons given for why we should all be using F# is F# Interactive. The point they all ignored is that FSI isÂ notÂ F#, itâ€™s a tool that Microsoft happened to have implemented for F#, and hadnâ€™t implemented for C#. As it happens, Visual Studio 2015 now includes a C# Interactive window, so this supposed benefit is no longer valid anyway. I doubt theyâ€™ll stop their bleating though.
Another reason given for F# being the best thing since sliced bread is the type inference. Well, despite having struggled to understand the benefits, Iâ€™m still very doubtful about this one. Yes it makes the code shorter, but it makes it a whole lot harder to read. When I look at a piece of C#, I can see straight way the variable types and the method return types, so I can concentrate my mind on hat the code is doing. I canâ€™t do that in F#. Having said that, when writing F#, the type inference is a joy, as you can concentrate on what the code is doing, and ignore the technicalities. Itâ€™s a two-edged sword, and not an undiluted benefit.
Well, it’s so clean, sir!
The final claim I want to address is that F# code is so much cleaner than C#. Well, there is something in that, but clean isnâ€™t necessarily better. I suspect most people will recognise the following snippet from what is arguably one of the funniest moments in comedy…
Customer (John Cleese): It’s not much of a cheese shop, is it?
Owner (Michael Palin): Finest in the district sir!
C: (annoyed) Explain the logic underlying that conclusion, please.
O: Well, it’s so clean, sir!
C: It’s certainly uncontaminated by cheese.
Being clean can also be a disadvantage.
Apart from the specification of types (see above for why Iâ€™m not convinced that this is a bad thing), the only other part of C# thatâ€™s not clean is the fact that you have brackets knocking around, whereas F# is totally devoid of them. Again, this might make the code slightly shorter, but has its disadvantages. For example, if I have a few lines of C# code, and want to surround them with an â€œifâ€ statement, I can just add the â€œifâ€ statement on the line before the block, and a closing brace on the line after, then reformat the code, and all the indenting is done for me. I know the insertion will be right, as it canâ€™t fail. If I want to do the same in F#, I have to concentrate a lot harder on adding the right amount of extra indentation to the lines I want inside the â€œifâ€ block. Itâ€™s significantly more likely to go wrong.
If the few extra lines added by braces really bother you that much, go buy a bigger monitor! I can see around 70 lines of code on mine, so the few extra lines added by the braces rarely cause me any problems.
To make it even worse, when comparing evil C# code against the pure and sainted F# equivalent, they somehow always manage to stick as much extra code into the C# version as they can. F# snippets would be a method, and nothing else. The equivalent C# snippet would be a whole class, including usings. This is a false comparison.
I |>Â Â F#
By this point, you probably think I hate F#. Well, itâ€™s not true. My point here is not anything against F#, itâ€™s against the lies and exaggerations bandied around by the F# fan boys. I probably would have given up on F# in annoyance at these lies (as I suspect many, many others have done) were it not for the fact that I am fascinated my shiny new things. I decided to carry on anyway.
Thankfully, I discoveredÂ Project Euler. For those who havenâ€™t discovered this wonderful site yet, itâ€™s an ever-growing collection of mathematical and computer programming problems. Apart from my inherent love of such things, this was the perfect opportunity to learn F#.
Now you can use PE by simply solving the problems, entering your answer to check you got it right, and carrying on to the next one. I decided not to do that. I solved the problem, then went back and tried to find ways of improving my code. I posted my samples up forÂ code review, and played around with the suggestions I got. I searched around for other peopleâ€™s solutions (onlyÂ afterÂ I had already solved it myself) to see if I could find better code. When I did, I copied it, played with it and made sure I understood it.
In time (not much actually), an amazing thing happened. I got really excited about F#! When you get into it, itâ€™s a really nice language to use. Iâ€™m still not convinced that there are many major benefits over C# for my line of business (pull data from a database, display it on a window, wait for the user to make changes, save the data back to the database, etc), but for the sort of work that I would love to do, like machine learning, data analysis and so on, it seems wonderful. Sadly, I reckon my use of it will be largely recreational, unless I can find some justification for using it in my day job.
If I get around to it, Iâ€™ll post some of my Project Euler code here, so others can laugh at it, and feel better about their own code.