There are legions of developers across the world who would like to shake the hand of the famously sleep-deprived Don Syme. For he, along with his team of Cambridge-based researchers, has been the driving force behind the development of the F# language at Microsoft. Smoothly combining the simplicity and power of its functional programming forebears (ML, Ocaml) with the object-oriented capabilities of the .NET framework, F# provides the much sought-after combination of type safety, performance and scripting. According to many developers, it is the most original new face in computer languages since Bjarne Stroustrup developed C++ in the early 1980’s.

Starting with Microsoft in 1998, Don also created Generics in C# and in the .NET Common Language Runtime. He has been a functional programmer since 1989. Before this he was a PhD at the University of Cambridge, and before that grew up in a small country town in Australia.

RM:

I’m sure it’s a question everyone asks but how did the name F# come about?

DS:

In the F# team we say ‘F is for Fun.’ Programming with F# really does make many routine programming tasks simpler and more enjoyable, and our users have consistently reported that they’ve found using the language enjoyable.

RM:

Were there any particular problems did you have to overcome in the development of the language?

DS:

Combining object-oriented and functional programming poses several challenges, from surface syntax to type inference to design techniques. I’m very proud of how we’ve addressed these problems.

F# also has a feature called ‘computation expressions,’ and we’re particularly happy with the unity we’ve achieved here.

RM:

Good developers will always say that they would have done things differently in developing a language. Is there anything you would have modified?

DS:

In a sense, we’re tackling this now. Some experimental features have been removed as we’re bringing F# up to product quality, and we’ve also made important cleanups to the language and library.

RM:

F# is heavily rooted in OCaml but what elements have you borrowed from other languages?

DS:

The aim of F# from the start has been to ensure that typed functional programming in spirit of OCaml finds a high-quality expression on the .NET framework. These languages excel in tasks such as data transformations and parallel programming as well as general purpose programming.

As it developed, F# borrowed more ideas from other languages: Haskell was influential in many ways, from basic syntax elements such as the ‘light’ syntax, to rich constructs such as sequence expressions and computation expressions, which are ways of generating and composing data structures.  Python was also influential, and of course C# has had a huge impact on F#, since F# includes an object model that is closely aligned to that of C#.

RM:

Did it help that Simon Peyton Jones, one of the key designers of Haskell is just down the corridor from you at Microsoft Research at Cambridge?

DS:

A lot! Simon PJ has been a great help with F#, so I have a lot to thank him for. He gave a lot of feedback on the feature called “asynchronous workflows” in particular, and also on “active patterns”, a form of user-specified pattern matching for F#.

RM:

Has the .NET framework played an important role in bringing the programming camps together?

DS:

Overall the last 5 years has seen a lot of idea sharing in the language community, at conferences such as Lang.NET.   The common vision of ‘many languages, many niches, high level interoperability’ has driven a wave of language research and excitement. Furthermore, .NET has brought language researchers more directly in touch with the “real world” of applied programming, and allowed us to conduct experiments where more variables are controlled – e.g. we can test out new ways of expressing solutions to existing problems without changing the underlying libraries or runtime machinery.

RM:

What attracted you to functional languages in the first place?

DS:

I’ve worked with many languages, from BASIC to assembly code. One of the last checkins I made when implementing generics for .NET, C# and VB had a lot of x86 assembly code. My first job was in Prolog. I think programmers should learn languages at all extremes.

Functional languages attract me because of their simplicity even when solving complex tasks. If you look through the code samples in a book such as F# for Scientists they are breathtaking in their elegance, given what they achieve. A good functional program is like a beautiful poem: you see the pieces of a ‘solution’ come together.

Of course, not all programs end up so beautiful. It’s very important that we tackle “programming in the large as well”. That’s what the object-oriented features of F# are for.

RM:

 Do you think it’s good practice for all programmers to learn languages at all extremes?

DS:

Yes, I do. I think all programmers have a curiosity about different languages, and should be familiar with the basic alternative computational models: functional, procedural, relational.  However it’s inevitable that programmers will concentrate on the tools they need for their immediate work, so what’s more important is an open mind and a willingness and excitement to see problems in a different way when necessary.

RM:

Why did Microsoft decide to develop F# and how does it fit into Microsoft’s overall strategy and philosophy?

DS:

Microsoft’s decision to invest in further F# is very much based on the fact that F# adds huge value to the .NET platform. F# really enables the .NET platform to reach out to some new classes of developers, and appeal to some domains where .NET is not heavily used.  This is especially true in data exploration and technical computing. We’re also exploiting functional techniques in parallel programming.

RM:

What is the best program you’ve seen written in F#?

DS:

That’s a good question! I’ll give several answers. I’ve mentioned the samples from F# for Scientists, which are very compelling. For sheer F# elegance, I like Dustin Campbell’s series of Project Euler solutions. For commercial impact then the uses of F# in the finance industry have been very convincing, but probably nothing beats the uses of F# to implement statistical machine learning algorithms as part of the Bing advertisement delivery machinery.

I’m intrigued by the potential to use F# to script data-oriented tools such as AutoCAD and ArcGIS. These domains are well suited to functional programming, and F# can interoperate with these tools very nicely. You can now use F# with the .NET APIs for these tools, which opens up many possibilities.

We’ve recently really focused on ensuring that programming in F# is simple and intuitive. For example, I greatly enjoyed working with a high-school student, who learned F#. After a few days she was accurately modifying a solar system simulator, despite the fact she’d never programmed before. You really learn a lot by watching a student at that stage.

RM:

Why would a programmer choose to write apps in F# rather than C#? Do you think F# will take over the industry in much the same way as c++ has? Do you think there’s a danger of F# becoming too ‘expert friendly’ in the same way that C++ has?

DS:

Concurrency is increasingly important for many applications, and the shift to many core brings abundant parallelism to the desktop. The web, Silverlight and distributed systems increase the demand for asynchronous solutions. F# is a succinct and expressive typed functional programming language for the .NET platform that makes major contributions to productivity in parallel and asynchronous programming, making these both fun and easy.

Regarding C# and VB.NET, well they are clearly the elder statesmen of.NET languages and it’s hard to imagine a really major .NET project where these languages doesn’t play a significant role.

So the approach we take with F# is that it is definitely complementary to C#. We expect there will be many F# projects that incorporate C# components. For example, the designer tools we use with F# emit C# code, and you then call your F# code from those the event handlers. A working knowledge of C# is thus very useful for the F# programmer.

F# is a really simple language to use, especially if you’re just implementing some data manipulation using an existing set of libraries. Some people see it as a sort of strongly-typed Python, up to syntactic differences.

RM:

How do you think more programmers can write quality code (as opposed to quantity) and still keep their jobs?

DS:

Many programmers choose to explore a problem in F# because it lets them focus more on the problem domain and less on programming itself. That’s a big benefit in some of the data exploration, algorithmic and technical computing domains, and so we’ve seen a lot of interest in using F# here, where C# may not have been an obvious choice.

So to me the question is not just about quality code, but about code that solves appropriate domain tasks and problems. For example quality algorithms, quality visualizations and quality data analysis.

RM:

How do you see the future for procedural programming languages?

DS:

People thirst for simplicity.  People need simple solutions to the problems that really matter: data access, code development, deployment, cloud computing, web programming, parallel programming to name but a few. One of the exciting things about working in the Visual Studio team is that there are world experts in all of these domains working in unison. We won’t cover all of these bases with the first release of F#, but over time we’ll be operating in all these domains.

At the language level, people say that languages are converging in the direction of mixed functional/OO programming. However I expect many important developments from this base. For example, we’re seeing language oriented towards “big, powerful data structures” such as tables and OLAP-like data cubes, perhaps with support for transactions. Merging these techniques into general purpose languages should bring great dividends.

RM:

Have you received much feedback of the language so far? If so, what has this been focused on?

DS:

We’ve received lots of feedback – we’ve been in almost continual engagement with the F# community for the last three years. This has been extraordinary. People have been very helpful, and have come up with many great ideas and suggestions. However, we’re just as glad to get the “this is broken” emails as we are glowing praise – indeed even more glad – we want to know when things don’t add up, or don’t make sense.

Some programmers do have a hard time adjusting their mindset from imperative programming to OO, though most find the transition enjoyable. Learning new paradigms can sometimes be easier for beginners than experienced programmers. However, one of the great things about F# is that you can “change one variable at a time,” e.g. continue to use your OO design patterns, but use functional programming to implement portions of your code.