Nice mention of unit testing, lack of bugs, and units of measure. Can't put down the exploratory nature, either.<p>The only nit I have is the way MS keeps wanting to pitch F#. I know the spin is to use F# for math-y type things, but I really don't know why you just wouldn't use it for everything. I mean, underlying it is the CLR and the OS. It's not like somehow if you know F# somehow you need to also switch to C# to make a window. In fact, if you keep it functional, many times your functions can work their way into what you previously thought of as framework code, simplifying the entire kit and caboodle. I find that every time I switch languages, start declaring mutable values, or framing up reusable classes -- I end up severely limiting my options for refactoring later on. And functional code is nothing if not hugely refactorable.<p>Simply because you can switch languages doesn't mean you have to, or even that it's a good idea to do so.
F#'s type system supports units of measure. It looks really nice: <a href="http://blogs.msdn.com/b/andrewkennedy/archive/2008/08/29/units-of-measure-in-f-part-one-introducing-units.aspx" rel="nofollow">http://blogs.msdn.com/b/andrewkennedy/archive/2008/08/29/uni...</a>
When you solve Project Euler problems you can see previous solutions. The F# solutions are astoundingly concise.<p>I regret I have not yet learned F#, but studying the Project Euler solutions would be a good approach.