hubFS: THE place for F#

We need some small code snippets/example that indicates the power/elegance of F#.  I have gone thru the blogs/videos, but haven't found something that would make a super-simple, Powerpoint-friendly intro.

Can someone post their favorite snippets of code to demonstrate the power of F# vs. C# (or VB.NET)? 

The code COULD assume some "background prerequisite" methods already created (in either F# or C#), to make the slide compelling.   The audience would NOT be a programmer exploring fractals, for instance, but more like corporate programmers who manipulate lots of data/trees of data/lists. 

The purpose would be to answer the question: Why should I learn F#...can't I just wait for C# version 4.0?

How about any of the examples on the Wikipedia F# article?

http://en.wikipedia.org/wiki/F_Sharp_%28programming_language%29#Examples

 

---

"It seems that perfection is reached, not when there is nothing left to add, but rather when nothing more can be taken away." -- Antoine de St. Exupéry

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.

I love this one:

let success, value = System.Int32.TryParse("12345")

Out parameters are such crap.

Partial function application is pretty neat too:

let multiply x y = x * y

let numbers = [1; 2; 3; 4; 5;]

let doubled = numbers |> List.map (multiply 2)

Also, you could demonstrate how an immutable list is "copied":

let list1 = [1;2;3;4;5;]
let list2 = 0 :: list1

System.Object.ReferenceEquals(list1, list2.Tail)

I wouldn't just stick these on a slide, though. I'd type them directly into FSI. FSI is a pretty good demo all by itself.