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

Question

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.