F# has always been a fascinating .NET language. You can easily mistake Visual Basic for C# nowadays, and even PowerShell’s idiosyncrasies are getting smoothed out, but you can’t mistake F# for any other leading .NET language.

Until its full integration into Visual Studio in late 2005, F# may have seemed to be a specialised language for those esoteric purposes where analytical programming is suitable. But, by combining F# Interactive with Visual Studio, F# users became able to develop fast, accurate code using Visual Studio’s background type-checking and IntelliSense, while exploring a problem space using F# Interactive.

Now that F# 3.0 has introduced the idea of type providers using LINQ, it has grown into a strong candidate for a wide range of data applications. F# 3.0 aims to be able to integrate data from a variety of external information sources, such as web information, web services, data markets and enterprise data, in a way that is extensible and strongly-typed. It is then able to inter-operate with them using the power of Visual Studio.

So, what exactly are type providers, and why does Don Syme reckon they’re so important that C# and VB will soon be using them? Why should we be considering F# for data-rich applications? To find out, we caught up with Don over a cup of coffee, to ask him about the latest developments in F#3.0 and canvas his views on functional programming in general.

RM:

Don, a lot has been happening with F# since we last spoke two years ago. What are the latest big developments in F#?

DS:

The language is certainly developing fast, and we’re very glad with the direction we have. First, the F# community and user base has been growing steadily, and we’re seeing good adoption of F# 2.0 in the areas of analytical programming that we’ve been focusing on. We’ve also been seeing great action from the F# community in expanding out the capabilities of F# in server-side and client-side programming.

Technically, the major announcements we made at the BUILD conference were about F# 3.0, especially about a set of features called F# Information Rich Programming. This technology lets you program directly against rich spaces of data and services such as databases, web services, web data feeds and data brokers.

You can think of F# Information Rich Programming as a kind of LINQ-on-F#-steroids. As part of this work, we’ve integrated LINQ queries into the language, and we’ve added a new, unique feature called type providers.

Importantly, these F# 3.0 data-access features will also be accessible to C# and VB programmers simply by adding an F# project to their solution.

RM:

Can you tell me what the aim of type providers is, what problem will this solve and how will it give tighter integration between the F# programming language and external data sources?

DS:

Type Providers are about replacing our conventional notion of a “library” with a provider model. This allows a type provider to project an external information source into F# and makes it easier to access diverse sources of data. Type providers for several commonly used data sources are included in the F# library, including SQL databases (both LINQ-to-SQL and LINQ-to-Entities), OData feeds and WSDL services.

Importantly, Type Providers integrate very nicely with IntelliSense, auto-complete, scripting and explorative programming. That is, when you program with a database, web-service or other data source in F#, you’re doing strongly-typed programming.

Type providers also scale to enormous external data services such as Azure DataMarket and web ontologies such as Freebase or Dbpedia. These data sources contain literally thousands of types and more are being added and organized every day.

RM:

I remember you saying at PGD that this work is the most important you’ve ever done beyond the implementation of generics into .NET. The obvious question is, why is this important?

DS:

For me, part of the role of F# is about proving that statically-typed languages can play fully in the modern world of connected programming, without losing the simplicity, elegance or tooling that come with strong types. Type providers are an essential part of tackling this, because we can no longer ignore the information-richness of external data sources, and have to change language and compiler architecture to adapt.

RM:

Do you think that the changes in F# have relevance for all typed languages over time? Is this development more Behavior-Driven Development (BDD) than Test Driven Development (TDD)?

DS:

Yes, I do think this has long-term relevance. I’ll go out on a limb and say that I expect most major, forward-looking typed languages to have type-provider-like architectures in the coming years.

That said, F# Information Rich Programming combines particularly well with the highly type-inferred nature of F#, with F# scripting and with the visual tooling of F# such as auto-complete.

RM:

F# adds huge value to the .NET platform and enables the platform to reach out to some new classes of developers, and appeal to some domains where .NET is not heavily used. Is F# going to be central to Microsoft’s enterprise strategy in the future?

DS:

The modern enterprise has a range of software needs that don’t fit the traditional “business apps” IT model of WinForms and WPF. For example, file processing, server-side programming, technical computing, data analysis, parallel programming and cloud programming all require very different skills to those associated with the OO languages of the 1990s.

In the F# team we call these problems “analytical programming”, in other communities people might say “code behind”, or “business logic” or the like. Analytical programmers are always on a search for tools which improve productivity, performance and robustness.

For these problem domains, F# is a central part of the tools we provide in Visual Studio to allow people to solve their real-world, practical problems.

RM:

How will the advances in C++ affect the future of F#?

DS:

It’s great to see C++ developing as a language, and of course it is an essential tool for purposes like systems and games development. However, I see very few people moving back to C++ once they have embraced languages like F#, unless they need it for a specific purpose.

The special thing about F# is that we manage to get most of the benefits of dynamic language, like rapid development, data-richness and succinctness, while also still retaining the benefits of strongly-typed languages such as robustness, performance and visual tooling. Further, F# programming is renowned for having low bug rates. And all in the context of a highly interoperable platform.

RM:

One of the key things about F#, of course, is that it spans the spectrum from interactive, explorative scripting to component and large-scale software development. Was this always a key part of the development of F#, or has it simply morphed into a language with these added to it?

DS:

When I look back, I only think that F# really found its first cohesion as an overall concept in around 2006-2007. At this time, we started to describe how “it’s the combination that counts” – the combination of succinctness, efficiency, libraries, strong-typing and so on. We didn’t have all of these in place from day one, but when they came together, we knew we had a real contribution to make to programming languages.

RM:

Functional programming is gaining in popularity and not just among the research community, but there are still people who see functional programming as being driven by ideas that, while excellent, can be very mathematical and divorced from day-to-day programming. Is that a fair characterisation?

DS:

There are certainly people who think like that, and I think there always will be.

Equally, functional programming is now so much a part of C# and Javascript (e.g. JQuery) that there are many people doing at least some functional programming all day long, and often barely even realizing it.

That said, there are plenty of ideas floating around amongst both object-oriented and functional programming researchers which are way too “out-there” for immediate adoption by the industry. I don’t mind if people take their time to adopt and learn these things – and I do think that functional programming needs to be used only when appropriate, and requires good training, knowledge and experience.

RM:

The culture of the programming language community tends to be ‘prove that your type system is sound and complete’. Do you think in practice functional programs make people more productive? For example, are you more productive writing a functional program or an object-oriented program to do the same thing?

DS:

In F#, it is the synthesis of functional programming and OO programming that makes people more productive. Here, functional programming means type inference, mutable-state-minimization, closures and simple-orthogonal language features where possible. I am convinced these make people more productive. We’re seeing many examples of that in practice.

For most tasks, I am less productive in a language that supports functional programming alone, just as I am less productive in a language that only supports OO programming.

RM:

I remember Simon Peyton Jones once telling me that at Microsoft in Redmond, systematic attempts are made to watch programmers who have been given a new API talk through what they are trying to do, with the people who designed the API sitting behind a glass screen watching them. The idea is that the API is changed if necessary. Have you used this particular method with F# and/or is programming language research weak on that score regardless of who designed the language?

DS:

We’ve used this technique as part of the F# product team, and it’s simple and great.

I don’t think it is at all normal to use this technique in any programming language research. Some researchers do try to do some empirical studies of language features, but very few do in-situ informal usability studies. Traditionally, programming language researchers have largely ignored or avoided these “human” aspects of their work – mostly because it is extremely difficult to do convincing controlled experiments in this space. All users come with background and “baggage” which makes them see a new language or API in a particular way.

RM:

What advice do you have for up-and-coming programmers?

DS:

My advice would be to learn F#, Python, Prolog, Haskell, C# and Erlang!