My experience of F# is that I wouldn't prefer it for anything where there is strong tool support for C# - ie. GUI's, database interfaces, Sharepoint,...

The differences in the power of the languages are more than outweighed by the power of the tools (in favour of C#).

On the other hand, if the project was heavily scientific, or involved lots of text processing, then F# starts to shine.

Over the years the standard response to this question has been to recommend the mixed language project.

In addition to the other excellent answers offered, you may also want to look at John Hughes' excellent essay "Why Functional Programming Matters." This is not really addressing the subject of F# vs. C# but it's giving a general flavor of what sorts of benefits functional can offer in general.

Don Syme makes a few comparisons between OO (C#) and functional (F#)

code in his recent web lecture,

[link:channel9.msdn.com]

These comparisons show how you can get more work done with less coding, by using a functional language.

Maybe Don's presentation could be of use to you?

Here are my thoughts (in no particular order)...

The first thing I think you need to consider is that .NET development is NOT an all-or-nothing model when it comes to choosing a language. I routinely build apps where I mix languages. The whole benefit of the .NET platform (or any CLR, for that matter) is that you can use the right (language) tool for a given problem, and interoperate easily between solutions. So, I'd say question one is inaccurate/irrelevant.

Question two has many (somewhat subjective) answers. But my favorite is based on the Sapir-Whorf hypothesis, otherwise known as the linguistic relativity principle ([link:en.wikipedia.org] Put simply, a language's syntax and semantics encourage (or restrict) different patterns of thought. So, the more language's you understand, the more mental models you can leverage to articulate a given solution. For example, LInQ (in C#/VB.NET) would not have been possible if the folks at Microsoft had no understanding of Monadic theory.

As for question three, here's woefully incomplete partial listing:

- type inference at many levels

- true first-class functions (a delegate is NOT a first-class function!)

- implicit currying

- automatic partial application

- easier (better) mutation control

- the ability to model things with structures other than a class

- useful container literals (tuple, record, list, etc.)

- ultra concise ways of handling traditional OO constructs (discriminated unions, object expressions, etc.)

- sequence comprehensions

- pattern matching

- active patterns

- computation expressions (see also: workflows or monads)

- quotations (in other words: we can meta-program our whole language, not just a targeted sub-set)

I am sure I'm forgetting a few things, but this should enough for most nay-sayers.

Question four can not be answered without a better understanding of the problem domain under scrutiny.

The answer to question five is definitely: YES! Just Google for examples; people are using F# with WebForms, MCV, and Silverlight (whether or not they SHOULD be is a separate discussion). Alternately, (for non-Microsoft solutions) you might look at Intellifactory's WebSharper product (www.intellifactory.com), or the Bistro project ([link:bistroframework.org] Neither are really my "cup of tea" (for different reasons), but both definitely deliver an F#-centric web development experience for ASP.NET.

Lastly, if you are going to be recommending F# to clients, you should probably keep the answers to these (and many other typical questions) close at hand. Of course, without fully understanding the language, you may be trying to use it in situations where another language would be a better choice. So, a solid working knowledge of the language is going to be more useful (in the long-term), than a list of bullet points.

I hope this is helpful.

With no details about the client/domain, it's hard to offer any advice. In any case, C# versus F# can be a false dichotomy - it doesn't have to be either-or, you can use both languages together as part of your entire solution. (This helps a lot with adoption barriers; rather than writing a whole app in a new language, you might just write one component in F# to get your feet wet and try out the language; this helps mitigate the risks of doing something completely new.)

Anyway, you might want to start by reading

[link:blogs.msdn.com]

and then consider a plethora of somewhat-similar language-comparison questions like

[link:stackoverflow.com]
[link:stackoverflow.com]
[link:stackoverflow.com]
[link:stackoverflow.com]
[link:stackoverflow.com]
...

Don't just jump on board because something is new & interesting; try out F# to get a sense of its strengths and weaknesses, and then you can give reasonably informed advice on the trade-offs between the costs of investing in something new and the benefits it make have for a (portion of a) particular client's application.