Nine reasons to use F#
Posted by Brian on April 1, 2010
(Opening aside: Robin Milner, the father of ML, recently died, and Don’s blog briefly traces the influence of Milner’s work on both .NET generics and F# type inference. As a programming-languages enthusiast, I enjoy learning about the histories of languages and seeing how feature cross-pollination has occurred across languages over time.)
Now that we’ve finished the VS2010 product, I’ve been spending less time writing code and more time giving talks; as mentioned in previous blog entries, I recently presented at TechReady and I will be doing an F# workshop along with Chris Smith for Alt.NET soon. Preparing for talks gives me a chance to step back and think about how F# fits into the big picture, and how various audiences perceive F#. There’s a wide variety of reasons that folks may find F# useful, but most talks/presentations just focus on one or two of these dimensions. I wanted to organize my thoughts on the wider picture, hence this blog post.
The following “Nine reasons to use F#” are presented in no particular order. The list is not necessarily distinct (some elements overlap) or complete (this is just a list I came up with today), and not every reason in the list will resonate with every reader. But they are all ‘real’ reasons, in the sense that they’re representative of individuals or teams out in the world who are already using F# today. I think it’s interesting how much diversity there is in the list.
Without further ado, here are 9 reasons to use F#:
- Units of measure. If you’re working in domains that use numbers to represent physical quantities like kilograms, meters, and seconds (or pixels versus inches, or dollars versus euros, or …) you can use the F# type system to ensure that the dimensional analysis works out. Nearly everyone who uses this feature has a “wow” experience where the compiler finds an unexpected bug (it happened for me when working on the 2008 ICFP programming contest). In certain domains, this kind of static typechecking is a really killer feature. You can learn more about F# units here, here, or here.
- Functional programming with .NET. If you need to author a component that’s especially amenable to functional programming techniques (like game AIs, statistical modeling, symbolic computing, …), and you need to interoperate with SQL, Excel, or XBox, or run in the browser with Silverlight, or run in the cloud with Azure, or do WCF, WPF, or WinForms, or easily talk to your existing C#/VB/C++/COM code, then F# is where it’s at. The .NET platform has great reach and integration with a variety of technologies, and F# extends the platform by providing a way to do first-class functional programming and get seamless integration with all these technologies.
- Explorative programming with the REPL. The F# Interactive tool window makes it easy to execute small bits of code on the fly. When working with large data sets or mathematical models, this makes it easy to explore the data, play “what-if” games, and directly interact with the data/models in a very “live” way. When coupled with libraries for data visualization, this enables some really cool stuff.
- Asynchronous and parallel programming. I’ve blogged recently about F#’s unique programming model for writing non-blocking code for asynchronous I/O. The async programming model also extends to parallelizing CPU intensive work, and F#’s library also makes is straightforward to react to events, use lightweight agents, or run code on the GPU. (There’s actually tons of content on the web on these topics; in the previous sentence, I just sprinkled in some links to Don’s blog.) Multi-core is here, and F#’s language constructs and libraries are very well-suited to parallel programming (not to mention some intrinsic advantages of the functional programming style).
- Embedded domain-specific languages (EDSLs). A variety of F# features (including ability to define new operators, currying and function application syntax, quotations, type inference and overall lightweight syntax) make F# a good language for creating EDSLs. Some examples include FsUnit for unit testing, FAKE for authoring build scripts, FParsec for parsing, and WebSharper for web applications.
- Scripting. Every so often, I need to write a script, but I use perl and batch files infrequently enough that I’m always forgetting the syntax of those. Nowadays I use F# for a number of scripting tasks, both in the sense of “FSI is the new perl” and for tiny tasks (e.g. if I can’t recall the ascii value of character ‘A’, I just type “int ‘A’;;” into the F# Interactive window). I know at least a couple folks using .fsx files where previously they would have used batch files or perl scripts. For me, F# is the first “software engineering” language I know that’s also a good “scripting language”.
- A practical language for academia. Back when I was a college undergrad, the first real programming language I learned in school was Pascal. (Yes, this was back before C#, or even Java; I’m an old man.) In university, it seems there’s been a tension between teaching more ‘pure’ and ‘CS-y’ languages and teaching more pragmatic languages (e.g. that you can likely use for gainful employment when you get out of school). This is still a topic of much debate, but I think we’re in a much better state now, with languages including Java, C#, Scala, Python, and F#, then we were a decade or two ago; there are now a variety of languages that are decent both as “good introductory CS languages” and “useful real-world languages”.
- Expand your mind and career. I think there are a fair number of folks that use C# or VB in their day job, who would like to learn more about functional programming, but find that diving head-first into Haskell is too difficult or time-consuming. F# provides an avenue to go more gently into the waters of functional programming, leveraging one’s existing .NET and Visual Studio familiarity. A lot of folks who are just trying F# as a hobby have reported that they’ve learned new strategies/algorithms that they can apply back in their day job (e.g. using C#), hurray.
- Fun! I’m constantly hearing from people how much they enjoy using F#. Who doesn’t love being able to get a job done and have fun doing it?
In a given blog post, or talk, or video on F#, it’s easy (and indeed often appropriate) to “pigeonhole” the language, focusing on one particular useful aspect. But on occasion it’s useful to step back and see the myriad ways that people perceive and use F#. So this is one attempt at that, a scattered list that suggests various reasons why people are using F# across the roles of hobbyist, academic, and real-world developer. It’s been great giving this language legs and now seeing all the ways people are applying it.
As an aside, one way you know that your Microsoft product is “real” is when they give you a T-shirt with your product logo on it. :) Here’s a photo of the back of a shirt we (the VS managed languages folks) just received at work:
Good ol’ SWAG…
As a final aside, a revised language spec for the RC release is finally online. Thanks to all those who have reported bugs; we continue to refine this document.