F# for C# programmer who already incorporates function delegates as parameters

Question

I have a book coming on F#, but at the moment I am pretty uninformed, so I thought I'd ask. From very little I know of F#, I am struggling to see what it gains me over C# bar a possible syntactic neatness. There seems nothing conceptually new, or that isn't do-able in piian C#

I did Forth way back when (20 years ago nearly!) and I already incorporate passing function delegates as parameters into methods (been doing that sort of thing forever, it seems).

Stylistically I am not keen on anonymous methods - is that going to be an issue?

Though I suppose syntactic neatness is not to be sniffed at :-)

Answer 1

(Caveat: This first bit is not really an answer to your question. And I am very biased, as a member of the F# team.) Having been using F# for nearly a year now, I find that whenever I have to write C# code it feels like walking through mud. There are so many curlies and semicolons, and oh-my-gosh-quit-making-me-write-all-the-darn-types! It just feels slow. I work with lots of C# code and so I still read and debug it almost daily, and it's fine for that (even better than F# for debugging; we still need to improve the F# debugger integration a bit), but I have found that writing C# code now feels like a chore; F# is just much more enjoyable to code.

As for actual answers to your questions, a lot of people say 'tuples', but I say 'meh' to that. Type inference, discriminated unions and pattern matching, a functional library, pipelining, and syntactic neatness (syntax matters!) are bigger winners to me. (And if you want to write async code today, F# blows the doors off everyone else.)

Answer 2

I like both F# and C#, but generally I prefer F#:

I would say if you try and to immutable programming in C# you soon run into the problem that you can't return more than one thing from a method/function. F# solves neatly using tuples to allow you to return more than one value.

Another problem with delegates in C# is that they are nominal. You can have two delegates with exactly the same signature, yet they are not compatible just because they have different names. You can use lambdas or anonymous delegates to work round this problem but F# solves in a cleaner way: it just check if the signatures match.

Union types are great and it's hard to see C# ever offering exactly this functionality.

Answer 3

In addition to the other answers: Automatic generalization.

This gives F# a huge step up over C#, Scala, etc. Here's a trivial example, the "snd" function to get the second value from a pair. In F#:

  let snd (a,b) = b

The compiler automatically figures things out and makes it fully generic:

  val snd : 'a * 'b -> 'b

In C#:

static Tb snd<Ta, Tb>(Tuple<Ta, Tb> x) { return x.B; }

1/3 the code, 100% less noise. Now, extend that to more complex function types, say, something taking a tuple, and returning a dictionary of some enum to a function. Ouch.

And these are simple scenarios. Add in some generic constraints, relationships between type parameters, and well, it gets really difficult in C#. A few times with C#, I've had to really stop, think, and calculate which generic parameters I need, even if it's not a difficult application. In F#, I can code out the idea, and generally speaking things get generalized as much as possible with no further work from me. Lovely.