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.

Answer 4

Another big advantage is the full type inference system. local functions, lambdas, tuples and lists reduces code very much.

Answer 5

我认为F＃的一大优势是对元组的更好支持。

Answer 6

Yes, at this moment of time the advantages are "just" pattern matching, immutability by default, simpler (but less familiar) syntax, and pretty good type inference.

The two big ones for me (not counting type inference) are a much nicer monadic syntax (computation expressions in F# versus LINQ queries in C#) and quotations (vs. LINQ expressions).

Answer 7

I must say the way they handle Async and parallelism in F# is impressive ... most impressive. Check out this video from PDC .

Answer 8

I find it quite difficult to present the benefits in some simple way. My belief is that the benefits are not in some langauge features (be it immutablity by default, type inferrence or anything else mentioned here). The difference is really in a completely different development style that you can use when working with F#.

You can find some more information:

• In an article I wrote: http://tomasp.net/blog/functional-overview.aspx
• In my other answer on SO here: Is F# really better than C# for math
• ...and in a free chapter of the Real world Functional Programming book here

Hope this helps!

Answer 9

Functional programming is vastly different from object-oriented programming. However, since F# is an object-oriented functional language, and since C# is a functional object-oriented language, these two languages will seem to be pretty close to each other.

Answer 10

There are things like discriminated unions, but I reached the exact same conclusion that you did.

And I'm not a big fan of the tuples - I like named properties, so I don't need to remember everything by position.

Things like immutabiliy is a false lead - since you can do that in C#, and hopefully C# 5 will make it easier too.

Re syntactic neatness... I find C# neater and easier to follow, bugt that might be familiarity.

There is a better switch syntax, but that can be introduced into C# - see here (including replies). Re anon-methods, nobody is forcing you to use them, but lambdas are a very tidy way of expressing intent in many cases.