F# with Ryan Riley

F# is a functional programming language created by Don Syme of Microsoft Research, Cambridge, UK. It's based on OCaml, which is a member of the ML family of functional programming languages. The 'F' is, obviously, for "functional." However, F# is not a pure functional language; it's a multi-paradigm language that allows for object-oriented and language-oriented programming, as well, though the default semantics encourage a stricter functional style. In other words, where C# allows mutability by default, F# uses immutability by default and has keywords to allow mutability.

Functional programming generally means that functions are first-class citizens of the language, just like other types. Think "functions are values." So instead of writing methods on a class to accept types like String, Int32, MyClass, etc., you can also pass around functions. In C#, these would be delegates or the generic Func and Action delegate types. So you can actually do functional programming in C#. More to the point, however, functional programming lets you declare the intent of your program rather than defining all of the how-to. This allows you to write fewer lines of code and repeat yourself a lot less (i.e. looping constructs are generally unnecessary). Your code is generally much more readable as a result. A terrific example from C# is LINQ. Using the query syntax, you can easily read what is the intent of the code without having to read through layers of loops. In fact, if you are using generics or LINQ, you've actually been reaping the rewards of the F# team's work, which started before the release of .NET 2.0. So if you have used either of those, you're already using functional programming!

In addition, functional programming is generally much stricter than C# in terms of mutability. Encouraging immutability allows for two wonderful benefits: mathematical reasoning over your code and easy concurrency. When all your functions are pure and your values cannot mutate, you can very easily test your functions since there are no side effects. Once tested, you don't really need the test anymore. Most functional languages give developers a Read-Eval-Print-Loop, or REPL, to allow them to test their code as soon as they write it. F# is no different and provides fsi.exe for both the console and integration with Visual Studio. (Of course, you can still test with a test framework, but you don't have to do it.) Concurrency is much easier in a functional language, as well. When you don't have mutability in your program, you can run the program asynchronously and in parallel over your multi-core CPU without the additional syntax and complexity involved with using BeginInvoke/EndInvoke, locks, Mutexes, and Semaphores. The result is that normally very complex code becomes much more readable.

There are any number of other techniques and benefits of functional programming, such as pattern matching, closures, currying, composition, tail recursion -- which allows you to create infinite lists without blowing the stack -- and explicit side effects. If you are familiar with Google's "MapReduce" framework that powers Google Maps, it's nothing but a few, simple functions over lists. You'll likely know them as Enumerable.Select and Enumerable.Aggregate from LINQ. F# calls them List.map and List.fold. These are very powerful, declarative constructs that allow you to keep your code neat and tidy.

F# is also statically-typed, even more than C#. It's type inferencing is much more advanced than what you generally find in C#. You will rarely need to define types anywhere in your program unless there exists some ambiguity that the compiler cannot determine. Of course, F# gets this enhanced type inference by forcing you to organize your code in such a way that any function or value used below is defined above. Of course, that's not really a benefit, but it's important to note. :)

The main advantages you'll find with F# are its extremely terse syntax and its ability to make async and parallel programming much easier. There are other terrific advantages, of course, but most developers will find these the most beneficial. Of course, the terse syntax takes a bit of getting used to. The #light syntax is now the default, and if you've ever programmed in Python, you'll be familiar with the importance of white space. You don't need any begin/end tokens or semi-colons. Parentheses may appear optional, but in fact they have significant meaning and can be confusing to people at first. You also don't have to worry over the ceremony of namespaces and class definitions. A simple class can be constructed from a Record type with member definitions or interface implementations. You can create subclasses using discriminated unions, which are a form of pattern matching, that can also be self-referencing. And as Matthew Podwysocki noted, F# is potentially more object-oriented in that you can create anonymous instances directly from interfaces, which could easily come in handy for mocking. In other words, you will write drastically less code.

Writing F# code will teach you new ways of writing C# code, but F# is a terrific language in its own right. In particular, F# is excellent at programming in the small. It's very useful for writing small parts of your application, especially calculations, test data, or asynchronous processing engines (e.g. for web requests, file access, etc.). Of course, if that was all it was good for, would we really be talking about it? I actually like it for programming in the large, as well. For anything application that is focused on state transitions as opposed to state mutation, F# could be a fantastic option. So processing XML transforms, writing a RESTful web server, querying data, and state machines are all perfect applications for F#. GUI applications can be difficult to grasp at first, but F# can even be a very powerful option for these applications as well.

Finally, domain specific languages (DSLs) have become a very popular topic lately. For the language-oriented paradigm, F# comes with FsYacc and FsLex for language parsing and processing, and others have created additional libraries such as FParsec and cashel. These libraries work very similarly to MGrammar from Oslo with the additional benefit of being able to execute your grammar. However, writing external DSL's aren't the only possibility. F# allows you to define simple, descriptive functions that can be composed together to create nice, internal DSL's, as well. Fake and FsUnit are excellent examples and are very similar to Ruby's Rake and RSpec.

Yes. F# modules appear as static classes, and the public functions appear as static methods. In addition, using attributes, you can enable F# extension methods as C# extension methods, and you can even define different names. The most challenging part of F# interop is related to passing Action and Func delegates from C# to F# functions. You'll need to use ToFastFunc from the F# .dll to convert your C# delegates into the appropriate F# function. Because F# is functional, it makes sense to write additional LINQ-like extension methods. You may also want to interact with libraries written by others, such as the Excel Financial Functions library from Luca Bolognese, which gives you the same functions as Excel without Office interop.

I've been reading several books and following several bloggers:

Books:

Bloggers:

Community for F# at http://communityforfsharp.net starting in January. We're moving the Houston F# User Group online.