At this Saturday’s Code Camp I’ll be giving a brand new presentation on using F#.  The goal of this presentation is to have those attending leave with an idea of what F# can help them achieve today as well as instill a desire to know more.  This post contains my presentation materials as well as links to additional information on the topics covered.

(Slide and code links will be updated soon.)

 

Presentation Details

F# for Testing and Analytics will be held in the TBC (Technical Briefing Center) at 10:30am.

New England Code Camp 11 Information
Download Presentation Slides
Download Real World Example Code Sample

I’ve been thinking quite a lot lately on the best way to get developers excited about F#.  By focusing less on the language’s details and more on what the language can help achieve I hope to impress upon those attending why F# is worth the effort.  The preliminary structure of the talk is as follows::

• Introduction
  • Announcing the New England F# User Group 
• Why F#?
  • Time Savings
  • Readability
  • Code Exploration
  • Robust Software
  • Visual Analytics
• F# Testing Toolbox
  • xUnit.NET
  • TestDriven.NET and NCover
  • NaturalSpec
  • FsCheck
  • FsStory
• A Real World Example
  • Exploring the Problem Space
  • Collect, Analyze, Report
  • Visualizing Data

Presentation Influences
John Hughes’s Paper: Why Functional Programming Matters
John Hughes’s Talk: FP – A Secret Weapon for Software Testing
Matthew Podwysocki’s 7 Part Series: Functional Programming Unit Testing

 

Announcing the New England F# User Group 

I’m proud to announce that we will be holding our first New England F# User Group meeting on Monday April 6th, from 6:30pm to 8:30pm.  It will be held at the aptly named Microsoft NERD center.  I hope to see you there.

Visit the F# User Group Homepage for more information.

 

xUnit.NET

“About a year ago it became clear to myself and Brad Wilson that there were some very clear patterns of success (and failure) with the tools we were using for writing tests. Rather than repeating guidance about "do X" or "don't do Y", it seemed like it was the right time to reconsider the framework itself and see if we could codify some of those rules.”

xUnit.NET Homepage

Learn More about xUnit.NET
Matthew Podwysocki’s The Unit Testing Story in F# Revisited
Jim Burger’s Unit testing in F# with xUnit.NET
Harry Pierson’s Practical F# Parsing: Unit Testing

 

TestDriven.NET and NCover

“TestDriven.NET is a zero friction unit testing add-in for Microsoft Visual Studio .NET. The current release of TestDriven.NET supports multiple unit testing frameworks including NUnit, MbUnit and MS Team System and is fully compatible with all versions of the .NET Framework.”

TestDriven.NET Homepage (Includes a free version of NCover)
NCover Homepage

Learn More about TestDriven.NET and NCover
Matthew Podwysocki’s F# + TestDriven.NET + xUnit = Win 
Matthew Podwysocki’s FP Unit Testing Part 4 – Code Coverage

 

NaturalSpec

“The idea of NaturalSpec is to give domain experts the possibility to express their scenarios directly in compilable Unit Test scenarios by using a Domain-specific language (DSL) for Unit Tests. NaturalSpec is completely written in F# – but you don’t have to learn F# to use it. You don’t even have to learn programming at all.”

NaturalSpec Homepage

Learn More about NaturalSpec
Steffen Forkmann’s “Getting Started” with NaturalSpec
Steffen Forkmann’s Testing QuickSort with NaturalSpec
Steffen Forkmann’s Using NaturalSpec to create a spec for C# projects

 

FsCheck

“FsCheck is a tool for testing .NET programs automatically. The programmer provides a specification of the program, in the form of properties which functions, methods or objects should satisfy, and FsCheck then tests that the properties hold in a large number of randomly generated cases.”

FsCheck Homepage

Learn More about FsCheck
Claudio Cherubino’s Random testing in F# with FsCheck
Matthew Podwysocki’s FP Unit Testing Part 2 – QuickCheck and FsCheck
Kurt Schelfthout’s FsChecking dnAnalytics Part 1, Part 2 and Part 3

 

FsStory

“FsStory is a library for writing executable user stories in F#. FsStory enables the developer to write user story scenarios (in Given/When/Then form) in F# code.”

FsStory Homepage

Learn More about FsStory
Gustaf Nilsson Kotte’s Fluent language in FsStory
Gustaf Nilsson Kotte’s FsStory, executable stories in F#

The beauty of clean syntax and deep abstraction is an often overlooked feature of functional programming.  As they say, people come to functional programming for the concurrency but stay for the beautiful code (actually, I just made that up).  Also included: POPL 2009, S#arp and functional unit testing.

 

Blog - Matthew Podwysocki’s Series on Functional Unit Testing

In this eight part series Matthew covers unit testing in Haskell from the basics setting up HUnit to the details of writing purely functional tests.

This series is the only place where I’ve seen functional programming unit testing talked about with any significant depth.  While in writing this series Matthew used Haskell, it and F# share much in common and it’s obvious that he worked hard to make his posts apply to both.  I consider it a must read for anyone thinking about taking functional software engineering seriously. 

Although he has finished the series, I hope that in the future he takes some time to focus on unit testing in F# specifically.  I’ve yet to see topics such as mocking or ensuring referential transparency by test covered.

 

Transcription - POPL 2009 Grand Challenges Panel Summary 

This panel was lead by such research giants as Simon Peyton Jones, Xaveir Leroy, Kathryn McKinley, Greg Morrisett and Arvind.  In it they discuss where programming language development is heading and the factors driving us there.  Well worth the read for anyone interested in programming language evolution.

 

Blog - Mark Needham’s F# vs C# vs Java: Collection Parameters

In this post Mark compares list operations in F#, C# and Java.  It’s striking to see how far we have come in terms of clean, concise syntax.  Actually, it seems kind of reminiscent of evolution of man posters.

 

Blog - Jafar Husain’s F#: Real Sharp

When working in F# over a long period it’s easy to forget that one of the best things about it is how it’s concise syntax and deep abstractions make your code so much easier to understand and beautiful to look at.  In his post Jafar reminds us of this by contrasting C# with F# samples.

 

Software – S#arp Architecture Beta 1.0 Available

S#arp Architecture promises to make building web applications much easier by making much of the glue we currently use in ASP.NET web applications obsolete. 

I am a big fan of inversion of control and it is something that comes very natural in functional programming languages.  I hope to see some examples with S#arp Architecture and F# internals at some point in the near future.

The beauty of clean syntax and deep abstraction is an often overlooked feature of functional programming.  As they say, people come to functional programming for the concurrency but stay for the beautiful code (actually, I just made that up).  Also included: POPL 2009, S#arp and functional unit testing.

 

Blog - Matthew Podwysocki’s Series on Functional Unit Testing

In this eight part series Matthew covers unit testing in Haskell from the basics setting up HUnit to the details of writing purely functional tests.

This series is the only place where I’ve seen functional programming unit testing talked about with any significant depth.  While in writing this series Matthew used Haskell, it and F# share much in common and it’s obvious that he worked hard to make his posts apply to both.  I consider it a must read for anyone thinking about taking functional software engineering seriously. 

Although he has finished the series, I hope that in the future he takes some time to focus on unit testing in F# specifically.  I’ve yet to see topics such as mocking or ensuring referential transparency by test covered.

 

Transcription - POPL 2009 Grand Challenges Panel Summary 

This panel was lead by such research giants as Simon Peyton Jones, Xaveir Leroy, Kathryn McKinley, Greg Morrisett and Arvind.  In it they discuss where programming language development is heading and the factors driving us there.  Well worth the read for anyone interested in programming language evolution.

 

Blog - Mark Needham’s F# vs C# vs Java: Collection Parameters

In this post Mark compares list operations in F#, C# and Java.  It’s striking to see how far we have come in terms of clean, concise syntax.  Actually, it seems kind of reminiscent of evolution of man posters.

 

Blog - Jafar Husain’s F#: Real Sharp

When working in F# over a long period it’s easy to forget that one of the best things about it is how it’s concise syntax and deep abstractions make your code so much easier to understand and beautiful to look at.  In his post Jafar reminds us of this by contrasting C# with F# samples.

 

Software – S#arp Architecture Beta 1.0 Available

S#arp Architecture promises to make building web applications much easier by making much of the glue we currently use in ASP.NET web applications obsolete. 

I am a big fan of inversion of control and it is something that comes very natural in functional programming languages.  I hope to see some examples with S#arp Architecture and F# internals at some point in the near future.

Some interesting gems this week.  Revit, Closures and MathTools won the day.  However, I do hope you'll take a look at the IL post as well.

 

Blog – Jeremy Tammik’s Use F# Directly in Revit

In Jeremy’s post he discusses what is initially necessary to get F# and Revit working together.  He also provides a sample of a Revit addin written in F#. 

Revit is Autodesk’s architecture and design studio.  It allows physical engineers to coordinate and play with, design and visualize data while integrating directly with AutoCad.  It also provides a .NET 2.0 API.  Given F#’s support for units as well as it’s concise and mathy style, it makes sense that it would be an ideal language for engineers.

 

Site - WikiBooks FSharp Programming

Before I stumbled upon this site, I had never head of of WikiBooks.  That’s why I was incredibly surprised to find that it has the best online general F# reference around.  It has extensive sections on functional, immutable and imperative programming with rich examples and references to the math behind the ideas presented.  It’s a great site to have at hand for both those learning about the language and those experienced but still needing to occasionally look something small up.

 

StackOverflow -  A practical example of a closure in F#

Learning how to program functionally is much more than just learning some  new ideas and a new syntax.  It comes along with a ton of new jargon, some of which can be quite foreign sounding.  I find that it often turns out that the jargon actually represents a very simple idea and that becomes immediately obvious when discussed with a simple example.

 

Software – FSharp.MathTools

As you might have suspected by its name, MathTools is an extensive set of mathematics libraries for F#.  It provides, among other things, statistical functions, fast fourier transforms, optimization algorithms, Matlab compatibility and extended mathematical notation.  With a little development this combined with VSLab could provide a viable alternative to tools like Matlab while still allowing for collaboration with colleagues.

 

Article – Introduction to IL Assembly Language

It’s the responsibility of any serious programmer to know how how his or her tools work all the way down the chain.  In this relatively short article (given the topic) everything you would need to write a .NET compiler is distilled.  It’s the best reference of it’s kind I’ve seen.

Some interesting gems this week.  Revit, Closures and MathTools won the day.  However, I do hope you'll take a look at the IL post as well.

 

Blog – Jeremy Tammik’s Use F# Directly in Revit

In Jeremy’s post he discusses what is initially necessary to get F# and Revit working together.  He also provides a sample of a Revit addin written in F#. 

Revit is Autodesk’s architecture and design studio.  It allows physical engineers to coordinate and play with, design and visualize data while integrating directly with AutoCad.  It also provides a .NET 2.0 API.  Given F#’s support for units as well as it’s concise and mathy style, it makes sense that it would be an ideal language for engineers.

 

Site - WikiBooks FSharp Programming

Before I stumbled upon this site, I had never head of of WikiBooks.  That’s why I was incredibly surprised to find that it has the best online general F# reference around.  It has extensive sections on functional, immutable and imperative programming with rich examples and references to the math behind the ideas presented.  It’s a great site to have at hand for both those learning about the language and those experienced but still needing to occasionally look something small up.

 

StackOverflow -  A practical example of a closure in F#

Learning how to program functionally is much more than just learning some  new ideas and a new syntax.  It comes along with a ton of new jargon, some of which can be quite foreign sounding.  I find that it often turns out that the jargon actually represents a very simple idea and that becomes immediately obvious when discussed with a simple example.

 

Software – FSharp.MathTools

As you might have suspected by its name, MathTools is an extensive set of mathematics libraries for F#.  It provides, among other things, statistical functions, fast fourier transforms, optimization algorithms, Matlab compatibility and extended mathematical notation.  With a little development this combined with VSLab could provide a viable alternative to tools like Matlab while still allowing for collaboration with colleagues.

 

Article – Introduction to IL Assembly Language

It’s the responsibility of any serious programmer to know how how his or her tools work all the way down the chain.  In this relatively short article (given the topic) everything you would need to write a .NET compiler is distilled.  It’s the best reference of it’s kind I’ve seen.

In the image processing world, like most computational problems, we often think our work is composed of only two basic ideas: representation and transformation.  Of course, one may have many layers of both representations of transformations and transformations of representations which can make things appear quite complex at times.

However,  the problem is much more simple than it appears.  This is because a representation can be considered as a transformation from a zero or identity state.  Thus, in writing a symbolic language for image processing, we are left with only a single idea to consider:  transformations.  By composting layers of transformations we can apply image processing techniques in way which is not only bidirectional and platform agnostic but also comes along with a host of other benefits.

 

Let us consider a simplified example of processing an image:

1) We read in a file (representation) and use a codec (transformation) to convert it into a format understood by our API (representation).

2) We then perform some type of algorithm on that data (transformation) which results in some type of output (representation).

3) Finally, via another codec (transformation), another file is saved to disk (representation).

 

In most cases there are a great number of intermediate representations.  Each is a full copy of the previous iteration with whatever changes have been so far applied.  Essentially, the same information is copied over and over again in memory.  We do allow for some kinds of in-place processing, however, this is bad as when the operation has been completed, the previous representation has been destroyed.

 

Instead, what if we batched up sets of transformations?  This could have many benefits:

1) The most obvious benefit is that of parallelization.  Even at the simplest level of functional composition, these transformations could be handed off to a cluster for asynchronous processing or saved for a later batch processing job.

2) With an intermediate symbolic transformation language, processing algorithms could potentially be combined and reduced to produce a single transformation out of many.  This would significantly reduce the processing overhead as well as the number of intermediate memory representations.

3) An intermediate symbolic language which encompassed both codec and processing may make it possible to push the processing transformation through the codec transformation and in so doing no longer need to have any intermediate memory representation.  This could provide significant memory and processing speed time benefit. 

4) The intermediate symbolic language could be saved into the files themselves thus removing the need for the codec to be present on the end machine.  Admittedly, the user would also need the image language interpreter.

5) Instead of applying simple image processing algorithms to an image, the symbolic representation could be appended to the end of the file.  This would be quite similar to layers in practice.  In this way it would be possible to view the image at all stages of transformation.

6) For large or proprietary transformations, the representation could be kept on the internet and either be downloaded or, in the case where the owner did not want to expose their algorithm, a flattened representation could be sent out and a processing delta could be sent back.

 

Conclusion

Of course, when I speak of data I don’t only mean the image itself.  This technique could also be applied to many classes of data or algorithm.  Most notably for us, image metadata.

My initial goal is to build a basic codec representation along with some simple transformations.  Currently, I am researching bidirectional, reversible and declarative languages as examples.  With F# as a base language I believe it will be possible to build something portable to other ML variants.

With the start of our F# User’s Group this next Monday and New England Code Camp 11 last weekend, things have been extremely busy this past week.  Meanwhile, the F# sociocosm is growing at a rapid pace.  This week we have a talk by Don Syme, a look at F# quotations, and finally, some discussion on Seq.unfold.

 

Chris Bowen’s Post, Announcing F# User Group in Cambridge - April 6

A shameless plug here for our new user group.  A big thanks to Chris for helping us find the resources we needed to start out.  Without him this might never have come together.

 

Don Syme’s Talk, F# and functional programming in .NET

As Don Syme is the father of F#, when he speaks the community listens.  In this talk Don focuses on the pleasure and speed inherent in using FP and F#.  He does this by describing the functional methodology and constructs which provide a simpler and more elegant model for building programs.

 

Alex P’s Post, F# quotations at their simplest

A simple example on the surface for sure.  However, if you haven’t seen the power of F#’s language oriented programming features this is sure to be of interest.

For a deeper look at the power of quotations check out Tomáš Petříček’s F# quotations visualizer.  If his past projects are any indication Tom’s upcoming book is a must have for any F# enthusiast.  I preordered a copy just today.

 

Martin Peck’s Post, Solving Problems in C# and F# - Part 2 
(and update)

One of the most fantastic things F# has to offer is the rich functional programming heritage of sequence operations.  To demonstrate how elegant they can make your code, I would like to offer the following alternative F# solution:

let fibs = 
  Seq.unfold (fun (a, b) -> Some( a, (b, a+b) )) (0I, 1I)

Seq.find (fun n -> n >= 10I ** 999I ) fibs

I’m going to take this opportunity to point out the obvious: we have here two lines of F# which does almost exactly the same thing as thirty six of C#.   Now that’s what I call power and elegance.  The unfold function pretty much does exactly what yield was doing before, but implicitly in terms of the unfold function.  The idea of unfold can be confounding at first and so here is a breakdown of how it works:

let fibs =
  Seq.unfold 
    (fun (a, b) -> //generator function, 
                   //(a, b) is the previous state
      Some //Option monad, needed for unfold
        (a, (b, a + b))) //returned tuple: (value, state)
                         //or (first, (second, third))
      (0I, 1I) //Initial function state (first, second)

Note that in this version the state of the next two values in the sequence are always pre-calculated.  However, it is easy to avoid this if you instead consider the state in terms of the previous two values: 

let fibs = 
  Seq.unfold (fun (l, l2) -> 
    let n = l + l2 in Some( n, ( n, l ) ))
    (0I, 1I) //(previous, second previous)

If you want to learn more about unfold I recommend checking out:

 

Dustin Campell’s Post, Apples and Oranges

This is the best description of how unfold works I’ve seen to date. 

At this Saturday’s Code Camp I’ll be giving a brand new presentation on using F#.  The goal of this presentation is to have those attending leave with an idea of what F# can help them achieve today as well as instill a desire to know more.  This post contains my presentation materials as well as links to additional information on the topics covered.

 

Presentation Details

F# for Testing and Analytics will be held in the TBC (Technical Briefing Center) at 10:30am.

New England Code Camp 11 Information

I’ve been thinking quite a lot lately on the best way to get developers excited about F#.  By focusing less on the language’s details and more on what the language can help achieve I hope to impress upon those attending why F# is worth the effort.  The preliminary structure of the talk is as follows::

• Introduction
  • Announcing the New England F# User Group 
• Why F#?
  • Time Savings
  • Readability
  • Code Exploration
  • Robust Software
  • Power
• F# Testing Toolbox
  • xUnit.NET
  • TestDriven.NET and NCover
  • NaturalSpec
  • FsCheck
• A Real World Example
  • Exploring the Problem Space
  • Collect, Analyze, Report
  • Visualizing Data

Presentation Influences
John Hughes’s Paper: Why Functional Programming Matters
John Hughes’s Talk: FP – A Secret Weapon for Software Testing
Matthew Podwysocki’s 7 Part Series: Functional Programming Unit Testing

 

Announcing the New England F# User Group 

I’m proud to announce that we will be holding our first New England F# User Group meeting on Monday April 6th, from 6:30pm to 8:30pm.  It will be held at the aptly named Microsoft NERD center.  I hope to see you there.

Visit the F# User Group Homepage for more information.

 

xUnit.NET

“About a year ago it became clear to myself and Brad Wilson that there were some very clear patterns of success (and failure) with the tools we were using for writing tests. Rather than repeating guidance about "do X" or "don't do Y", it seemed like it was the right time to reconsider the framework itself and see if we could codify some of those rules.”

xUnit.NET Homepage

Learn More about xUnit.NET
Matthew Podwysocki’s The Unit Testing Story in F# Revisited
Jim Burger’s Unit testing in F# with xUnit.NET
Harry Pierson’s Practical F# Parsing: Unit Testing

 

TestDriven.NET and NCover

“TestDriven.NET is a zero friction unit testing add-in for Microsoft Visual Studio .NET. The current release of TestDriven.NET supports multiple unit testing frameworks including NUnit, MbUnit and MS Team System and is fully compatible with all versions of the .NET Framework.”

TestDriven.NET Homepage (Includes a free version of NCover)
NCover Homepage

Learn More about TestDriven.NET and NCover
Matthew Podwysocki’s F# + TestDriven.NET + xUnit = Win 
Matthew Podwysocki’s FP Unit Testing Part 4 – Code Coverage

 

NaturalSpec

“The idea of NaturalSpec is to give domain experts the possibility to express their scenarios directly in compilable Unit Test scenarios by using a Domain-specific language (DSL) for Unit Tests. NaturalSpec is completely written in F# – but you don’t have to learn F# to use it. You don’t even have to learn programming at all.”

NaturalSpec Homepage

Learn More about NaturalSpec
Steffen Forkmann’s “Getting Started” with NaturalSpec
Steffen Forkmann’s Testing QuickSort with NaturalSpec
Steffen Forkmann’s Using NaturalSpec to create a spec for C# projects

 

FsCheck

“FsCheck is a tool for testing .NET programs automatically. The programmer provides a specification of the program, in the form of properties which functions, methods or objects should satisfy, and FsCheck then tests that the properties hold in a large number of randomly generated cases.”

FsCheck Homepage

Learn More about FsCheck
Claudio Cherubino’s Random testing in F# with FsCheck
Matthew Podwysocki’s FP Unit Testing Part 2 – QuickCheck and FsCheck
Kurt Schelfthout’s FsChecking dnAnalytics Part 1, Part 2 and Part 3

 

FsStory

“FsStory is a library for writing executable user stories in F#. FsStory enables the developer to write user story scenarios (in Given/When/Then form) in F# code.”

FsStory Homepage

Learn More about FsStory
Gustaf Nilsson Kotte’s Fluent language in FsStory
Gustaf Nilsson Kotte’s FsStory, executable stories in F#

Over the last six months I’ve given variations on the same F# presentation on six separate occasions.  Each time I’ve gotten a similar response: enthusiasm from a small percentage of the audience and glazed-over stares from the majority.  In retrospect it seems obvious that I’ve been missing one of the major tenets of making great presentations, know thy audience.  It’s time for a new approach.

 

Information Overload

When thinking about how to get people excited about F# I immediately jumped to the learning format that I found the most exciting.  There was no time in my life when I was as overwhelmed by information like I was working on my Computer Science degree at UMass Amherst and I loved every minute of it.  When I started out, it seemed that using a university lecture as a model was the best possible format for sharing this kind of information.

I’ve since come to realize that this style of soaking the audience with “a fire hose of information” is a poor format for Code Camps.  While using this technique, I could see people turning off one by one as they became overloaded with information.  This is not in the spirit of code camp which aims to be a much more laid back kind of experience. 

 

As a FP Ambassador

Let’s invert perspectives and think about what an audience member would want.  When a person comes to a Code Camp presentation, it’s likely to be one of their first times being exposed to the topic being presented.  They don’t want to be taught as if they were in a classroom.  Instead, they want to be exposed to new and exciting information.  If their interest is piqued, they will seek details later.

So, instead of focusing on the details of F#, this new presentation will be built around the goal of instilling five key ideas to the audience:

• F# will save you time
• F# will help you become a better programmer
• F# is beautiful
• Immutability is next to godliness
• You can start using F# right now

It must be understood that almost every Code Camp attendee will have had little or no exposure to functional programming.  To many attendees, to be presenting on F# is to be an ambassador from the strange and nebulous functional programming world.  Instead of building walls of information, the goal should be to instead focus on connecting with the audience on the benefits of functional programming.

 

Planned Talk Structure

• Depending on an Audience Poll, Broad Concepts
• Testing with F#
• nUnit Examples (as a baseline)
• xUnit Examples
• FsStory Examples
• Analysis with F# (A Real Example From Atalasoft)
• Using The F# Interactive Window To Build Tests
• Data Collection
• Visualizing Data
• Conclusion
• Why F#?

More details will follow soon.

This week we have ActionScript byte code manipulation, COM interop in F#, a quick look at the option type, and finally, a very elegant cross product implementation.

Blog – Luis Diego Fallas’s Manipulating AVM2 byte code with F#

This article focuses on using AbcExplorationLib to parse AVM2 ActionScript byte code.   AbcExplorationLib is still rather new and does not yet have complete support for all AVM2 instructions.  However, it may eventually be useful for static analysis or, in the best possible case, flash generation from within .NET languages. 

 

Article – Richard Marsden’s Functional Programming with MapPoint and F# (Part One)

In this post Richard initially walks through the steps involved in getting COM Interop in F# via both early and late binding.  He then goes on to programmatically load up a new MapPoint instance and instantiate a pushpin on it.  Once the painful COM stuff is out of the way it seems F# could make a rather nice scripting language for Microsoft apps such as this.

We’ve been told that C# 4.0 will offer COM interoperability that is significant less painful due to it’s new named arguments, dynamic typing and language binding layers.  After reading this article, I can’t help but wonder how much of this (if any) will be available in F#.  In the CTP release both early and late binding are rather painful.

Stack Overflow – How does the option type work in F#?

It’s a rather simple question, but I do like how the community came out to help answer it.  Although, I do think it’s very debatable whether null or -1 make for a better answer to the question “how long is this null string?”.

Generally, I’m opposed to hiding information inside of a type meant to hold something else, especially if it’s a scalar value.  Were it not for the overhead involved, in C# I would think the best solution would be to throw an exception.  Inside F#, at least with option types you know you are handling an exceptional case and not just an empty variable.  Yet another great benefit of immutability.

 

Stack Overflow – F# – Cross Product of Two Lists

I wanted to include this as Tomas Petricek’s solution was extremely elegant.