Assuming pattern-matching is a full-fledged feature in C# 4.0, they could indeed wait. C# 3.0 already has lots of expressive power that is either functional or declarative: LINQ, IEnumerator, delegates & anonymous functions come to mind. Any programming I would do under contract in such a corporate setting I would likely stick to C# for non-linguistic reasons: the tools support is more mature and I would know programmers would be comfortable maintaining it. Coming from an OO C & Java background, I will say that the syntax and style of any of the functional languages are each a significant step for traditionally trained programmers, and I would hesitate to recommend such a switch in a multi-programmer data-centric production environment at this time.

Having said that, I will personally use F# whenever possible, so I am pondering how I would demonstrate what it is about it that makes that the case. I will try to come up with something, but understand that my basic message is to be cautious about whether there would be enough benefit.

What do I like about F#? Pattern-matching most of all. Type-inference, so don't have to always declare types, yet get the benefits of statically-typed code (performance, and compile-time verification avoiding many subtle mistakes). Tuples -- I've wanted tuples (especially multiple return values) in mainstream OO languages forever. In general, a more succinct style. Able to create a little function on the spot whenever need one, inline to a larger function. Can do this in C# with anonymous functions, but its clumsier and less expressive in many cases. Sequence expressions, including the ability to yield multiple results (including none) per loop. Explicit handling of "None". As a logician, the ad-hoc way nulls are dealt with in many languages drives me nuts -- how can anyone really verify anything in such non-mathematical models of computation?! And an overall benefit: the encouraging of a non-mutable logic style, improving reliability (avoiding subtle logic mistakes that leaves software in an unexpected state). If "mutable" is restricted to localized scopes, complex systems are easier to reliably construct.

Once I've completed a little demonstration of writing a Domain Specific Language parser in F#, I'll be able to pull some snippets from that. Here the pitch would be that a company can program against its data in a powerful way, without all the verbiage needed in normal programming. Though as a reality check, would have to contrast that with simply using LINQ. Most corporate data doesn't need to express recursion, which is what got me looking into deeper tree-search approaches. Hmm, the DSL work might give one angle: certain stuff is easier in F#, and since F# is a full .NET citizen, an F# module could be driven by a C# client. The public interface doesn't need to use any fancy F# data types or functional what-nots -- it can just be a normal-looking .NET class.