RSS 2.0 | Atom 1.0

Sign In


# Tuesday, September 16, 2008
Why NOT F#?
This is actually an open request for comments. I'm honestly interested in hearing why F# is not always the better candidate versus C#. What can C# do well that F# cannot? In nearly everything, F# seems to come out on top, as far as I can see.

Let's get these out of the way:

   - Personal preference. Enough said.
   - In beta. Enough said.
   - Legacy code. Sure, if you have a project in C#, it may not make too much sense to switch mid-way.
   - Management. Enough said.
   - No benefit. This is simply lack of education and needs to be addressed separately.
   - F#'s too hard/it's hard to hire F# devs. This is a non-issue that is a separate topic. In summary, anyone worth hiring for C# work should be able to handle F#. [Exception being a very small deadline with an existing team...]

The only code reason I've seen is heavy native interop/pointer work. F# seems to be slightly more verbose than C# in this case. It's not much more, but I could see if you're doing just pointer code then it could get annoying. (Interestingly enough, F# COM interop is much nicer than C# because it supports named and optional parameters (http://blogs.msdn.com/dsyme/archive/2008/05/02/full-release-notes-for-f-1-9-4.aspx, search for "chart")...)

What other reasons are there for C# over F#?

Edit: Good point in the comments about C# being a standard with open source implementations. That could be a big issue for some. Another good point is the current lack of tool support (like ClickOnce, ASPX and WPF designers, etc.). I don't see any intrinsic reason F# wouldn't have those, except for limited resources.

Code | FSharp
Tuesday, September 16, 2008 5:06:28 AM UTC  #    Comments [18]  |  Trackback

Tuesday, September 16, 2008 6:44:50 AM UTC
The simple answer is - F# is proprietary language with no open source implementation and C# is an ECMA/ISO Standard with at least one open source implementation. So as long as one cares about vendor lock in, one would go with C# or even better with Java. And you can take the fact that I take the time to write this comment as an indicator that I would rather like to use F#.
Tuesday, September 16, 2008 7:34:31 AM UTC
I think it is just a matter of time before F# gets it's real position. We are at the declining phase of new things. As in F# we can do DSL in a more convenient and clear way, even for UI it is more proper in above average complicated scenarios.
F# is at the position; where C++ and perl were at their upcoming time.
C# will be there and F# is just adding to the menu. So I think it is not a matter of F# vs C#. It is about the potentials in the environment and stuff that every team has at hand.
Personally I prefer F# to C#; because there is enough situations that my intentions can be expressed faster and cleaner in F# (even doing things like reflection and duck-typing).
Yet C# will be there for the same reason that Java will be.
Tuesday, September 16, 2008 7:55:56 AM UTC
Can you deploy F# programs just like c# programs?
With ClickOnce and all?
Tuesday, September 16, 2008 8:44:40 AM UTC

I don't see why not. You would be deploying the compiled assemblies, not the source code, so it should make absolutely no difference.
Tuesday, September 16, 2008 7:10:03 PM UTC
Some additional areas where C# is preferable, mainly because F# offers no tool support - yet:

- Visual GUI development
- VSTO and Office integration
- Simplified WCF development

I'm currently developing a Smart Document app with lots of connected and disconnected ADO & XML stuff and toyed with using F# for "business logic", but quickly found it was way more convenient just to stick with C#. The addition of WCF to the mix clinched it.
Fred Woolsey
Tuesday, September 16, 2008 7:42:55 PM UTC
Fred: What do you mean by simplified WCF? F# seems to work just as well as C# when it comes to WCF...
Tuesday, September 16, 2008 8:08:58 PM UTC
How do you write or work around:

{ ClassB: afield }

{ ClassA: owner }

Ie, declare a class with a field thats of a type not yet declared.
Tuesday, September 16, 2008 8:15:13 PM UTC
@Eric, like this:
type ClassA =
val afield : ClassB
and ClassB =
val owner : ClassA
Wednesday, September 17, 2008 12:01:58 AM UTC
I've spent a small amount of time playing with F# and feel that it suffers the same problems that I had moving from C to C++. C++ added a bunch of new weird things that many developers didn't understand. For example in F# you have <@ @>, <@@ @@>, <@| |@>, <@@| |@@>. This is similar to C++'s ->, ::, etc.

Don't get me wrong. I really want to love F#, but have been turned off by the unnecessary terseness of the language. For example Seq.iter. I think it would be better to spell it out like Enumerable.Range. (You can argue over which words are more correct. I'm arguing that we should use words.)

The biggest problem I see is that most computer programmers don't know or care about anything that F# offers. They mostly cut, paste and tweak until they get something to work. That's about it. They would never use the word immutable. They wouldn't understand why a function should be pure. These people don't read blogs and don't think about computers or programming when they are not at work.

In any case, I've been reading a lot about F# and I have been using this in my C# work. My problem is that I'm not sure how many "functional programming" concepts I can adopt in my C# code and still have my co-workers understand the code. I've already confused them with my use of => so I'm not sure how much farther I can go. So if my co-workers can't get => then I have no hope of getting F# into the picture.
Wednesday, September 17, 2008 1:46:30 PM UTC
I'm reading through 'Expert F#' now and finding a lot to like about this language. Its not a syntax that I'm exactly comfortable with (yet), but I realize that once I grok some of the finer points, I'll be able to pick up some techniques from functional programming that will inform my outlook as a programming professional. I don't see anything that C# can do that F# can't, and I can imagine using F# as a primary development language in the future.

That said, I have never personally met a programmer like me. As Jeff LeBert pointed out in an earlier post, most programmers do not challenge themselves to work outside their comfort zones. They will not adopt F# because it is so dissimilar to the type of programming that they are used to. When most programmers think that being able to juggle VB.Net and C# is an impressive feat, I hold out little hope that they'll even take a second glance at F#.

I wish more programmers actually understood the importance of knowing their craft, and not just slinging code together. The number of valuable techniques that I've picked up from languages such as Eiffel, Smalltalk, Python, etc. have shaped the depth and breadth of my skills, and F# will only add to that.

But again, I have never met (in 18 years of professional programming) another programmer like me.
Wednesday, September 17, 2008 9:24:43 PM UTC
Honestly? It's just way too terse for my liking. I'm a big fan of C# forcing a level of explicitness and verbosity; I don't believe in more expressive code being too verbose. Aside from that, I'm sure it's a fine language--just not *my* language. Different strokes for different folks, all that.
Wednesday, September 17, 2008 10:07:59 PM UTC
I don't understand what's too terse. You're at complete liberty to annotate all the types and turn off #light syntax. Could you provide some examples?

"Different strokes" works when the capabilities and expressiveness are equivalent. F# offers so much more, that small syntax issues seem to be... well, minor issues.
Wednesday, October 01, 2008 7:30:10 PM UTC
@Michael: I don't know what they mean by terse, but I think I could guess.
I think they are talking about all the <@ @>, <@@ @@>, [], [| |], {}, (|x|_|), ->, <-, >>, :>, :?>, |> plus names like .hd, .tl, etc.

I think im guessing right because I'm new to F# as well. I'm considering F# for some of my projects.
Wednesday, October 01, 2008 7:38:36 PM UTC
Half of those are similar to C# (casting in F# is actually more verbose). <@/<@@ is even more verbose as C# has no annotation to say "this code is quoted". The other operators (like >>, |>) are defined right in the language anyways...

But yea, it scares some people. As Ed wrote: "I'm a big fan of C# forcing a level of explicitness and verbosity"
Wednesday, October 01, 2008 7:47:59 PM UTC
I wasn't condemning verbosity, actually it was a little bit in the opposite direction.
Like Jeff mentioned, some people prefer Enumerable.Range over Seq.iter and expressions like 'obj is Class' over | :?
The formers are more verbose, but they are immediately obvious.
But don't get me wrong, I like F# as I said in my previous post.
But the main reason is that I like functional programming per se, not so much F#'s syntax.
Sunday, March 07, 2010 4:08:29 AM UTC
I was delighted to learn about F#. I'm one of those programmers who doesn't mind learning something new if it offers useful advantages. That's why I've been a fan of OCaml of late, because I *do* like the (optional) terseness and the clarity (IMHO) and the terrific execution speed.

F# takes what's nice about writing OCaml and overloads several operators (to the detriment of clarity but greatly simplifying authoring). Several other nice features as well. On the other hand, it loses the execution speed advantage running at the common speed of .NET

What I would most like to see is an open source version of this language (or something very similar) that still has the execution advantage of OCaml or other ML languages without the dependance on .NET

...maybe an OCaml++ ??
Tuesday, May 11, 2010 7:02:18 PM UTC
Concurent Clean is the best functional language in terms of sytax, speed and features.

It generates native exe that is small and fast!

Unfortunately it is not in the main stream and hardly any support tools exisits.

But as a language it is very capable.
Thursday, November 18, 2010 2:15:39 AM UTC
I thing the answer to the question "Why not F#" is very obvious so far: learning a new language is a quite investment in terms of time. There is still not a good comparison between the two languages (F# and C#) to prove that F# is better.
Please login with either your OpenID above, or your details below.
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):

Live Comment Preview