In what areas does F# make "absolute no sense in using"?

Don Syme in his SPLASH talk says that F# is NOT intended to be a replacement for C# even though it has the general capabilities. He goes on to say that there are areas where F# makes no sense in using, but doesn't expand on the thesis.

1. Can somebody please tell me what areas should be avoided while using F# ?
2. You could also mention areas where C# shine.

Related question:

https://stackoverflow.com/questions/2785029/in-what-areas-might-the-use-of-f-be-more-appropriate-than-c

My take is that replacing a language as rich and mature as C# would be very expensive. So, for example, at the moment, C# is absolutely the best choice for WinForms development if using the Visual Studio WinForms designer can give you an advantage: F# has no WinForms designer.

C# also has better LINQ-to-SQL support at the moment. I'm sure there are many other examples along these lines.

Then there is requiring the entire C# skilled workforce to update their skills to F#, while preserving C# skills for maintaining applications, again expensive.

Finally, C# is an excellent language with a lot of great features, some F# doesn't even have like co/contra variant generics and out of the box support for dynamic programming against the DLR (F# just has an unimplemented operator).

So by not expecting F# to replace C#, F# can evolve in new ways instead of spending all it's time playing catch-up in areas already well-covered.

This is a tricky question, because it isn't very well qualified. Are you talking about the language in general, or are you talking about the language together with current IDE support? Or are you talking about using F# given the libraries available?

• Language in general - I don't think there are areas where using F# would be an absolute nonsense. It would be great for systems programming of fully managed OS (e.g. Singularity) and I think that functional programs would be easier to verify formally (which could be a big deal for OS). For low-level embedded systems, you could use meta-programming and langauge-oriented facilities (e.g. to model signal flow in hardware etc.)

• Language with current IDE - The current F# IDE has some limitations - it doesn't work with WinForms designer (but it works well with Blend and WPF).

• Language given developer education - It is more difficult to hire F# programmers than to hire C# programmers. If you're creating some application that doesn't have any complicated core (e.g usual "interface for a database") then developing it in C# will be cheaper (If you could hire good F# developers they would likely finish it faster and with less bugs, but it may not be worth the cost).

• Language given libraries available - If you want to restrict yourself to using F# with just libraries that work well with it then the domain shrink a bit more. For example, LINQ to SQL and ASP.NET MVC can be used with F#, but it isn't perfect. However, for many projects it would make sense to develop your own libraries and then F# becomes great language for that.

Good question. I'd say that there are zero language reasons and many unfortunate skill-set, aptitude, and attitude reasons on the part of developers, managers, and customers.

You might want to think twice about using it for operating system kernel development or low-level embedded systems :-)

Many of Microsoft's UI technologies such as WPF have excellent support for databinding. Effective databinding uses two-way binding to update the underlying objects when the user interacts with the UI. This implies that effective databinding requires mutable objects.

F#, with its emphasis on immutable types, is a pretty poor match to that type of databinding model. While it's possible to create mutable types in F#, doing so would remove a lot of the benefits from the language. It simply makes better sense to use a language (such as C#) where mutability comes more natural.

If you're willing to give up tools particular to C#, and pay whatever cost of adoption is applicable, there is no particular area where F# would not be at least as capable as C#.

Web Applications where Frameworks e.g. ASP.NET MVC lend themselves better to C#. "Absolutely no sense" is an extreme, I would say "under normal circumstances."

Of course it could be used for libraries that the web application referenced, but not the actual application itself.

Well, at the risk of stating the obvious, F# is first and foremost a functional programming language and OOP programming in F# can be a pain in the neck. So if you're working with a problem that is best expressed with OOP I imagine using C# does make more sense.

Mutually recursive types and explicit implementation of interfaces are the first examples off the top of my head of why OOP in F# can be cumbersome.

An (often cited) example of "problem that is best expressed with OOP" is creating a UI library. You have many widgets, which encapsulate their own state and you want to ask them to do a few things like "draw yourself" polymorphically (is that even a word?)

Until f# is fully supported by Visual Studio (ASP.NET, WebForms, WPF, etc) and third party tools, f# will always be a second class citizen.

Let's face it, language choice usually doesn't make much difference to productivity when compared to a solid library (.NET, available to both c# and f# - no advantage to either here), the IDE (intellisense, syntax coloring, etc), (only partially support available to f# as far as I know... e.g. no Razor support), and third party tools (e.g. resharper).

So with that in mind, I don't think anyone can recommend a complete replacement of c# until all of those tools are in place for f#. A good compromise is to use f# in class libraries and continue to use c# on the front end.