Onward and Upward

Blog archive

Q&A With the F# Team

I recently had the pleasure of emailing with Don Syme, creator of F#, and his team of collaborators. I asked the group a number of questions about the language, which I feel is still under-utilized and under-publicized. A number of the responses have come out in different formats, but the full Q&A has yet to be published. It's fascinating, so I wanted you to have it.

Q: Why was F# created? What need does it serve?

A: The modern enterprise has a range of software needs that don't fit the traditional "business apps" IT model. For example, financial modelling involves quantitative finance domain experts ("quants") who need to write and deploy models that analyze the value and risk of market positions. You can think of these people as one example of a domain-oriented programmer. There are many similar examples in modern enterprises and start-ups, including machine-learning, statistical, parallel, scientific and algorithmic experts: these people are often at the core of modern software teams. Domain programmers are always on a search for tools which improve productivity, performance and robustness in balance and often utilize analytical scripting languages as part of their work. Dynamically typed scripting languages are great in many ways, but can lead to real problems. For example, dynamically typed languages can lead to problems as applications grow in size. Often, they do not have good visual tooling (e.g. no IntelliSense), and may not be very performant when fresh code is written in the language. Finally, components don't live in isolation, and ultimately need to be deployed as encapsulated software components in the context of larger .NET systems.

When you look at examples across the industry, the common need is for a simple, succinct, efficient and typed language that allows math-oriented and domain experts to work in their problem domain, rather than get lost in a sea of OO class-oriented code, while still contributing professional software components that interoperate well. That's where F# fits in. Ultimately, this kind of tool makes domain experts happier and more productive members of software teams.

A similar story applies in other domains too - for example, modern server-side programming. Many companies need to write scalable services, and these services are often both asynchronous and parallel, including both I/O intensive and multi-core programming. This code can get very out-of-hand if using traditional OO techniques, leading to late project delivery or poor scalability. F# gives great tools to simplify server-side programming, including a wonderful asynchronous programming model and a functional programming methodology which minimizes the use of state. These allow server-side programmers to concentrate on solving the hard problems and achieving their performance and correctness goals.

The special thing about F# is that we manage to get the benefits of rapid development and succinctness of dynamic languages while also still retaining the benefits of strongly typed languages (robustness, performance and visual tooling), all in the context of a highly interoperable platform.

What are the most common scenarios for use of F#?

F# can be used for just about anything, but it excels at what we call "analytical component development". This includes financial and market analysis engines (including event-driven ones), server-side machine learning components and other data-rich analyses. There are several good examples case studies available on the Microsoft websites. Some interesting examples outside finance are the uses of F# in energy trading, Bing advertising, Project Emporia (a personalized news selection service based on machine learning techniques), and in the AI engine of the Path of Go game. All of these show where F# excels: analytical engines in the context of professional .NET software delivery.

What are the main advantages F# has over C#? C++?

F# differs in many important ways from C#. Technically speaking, some of the things you'll notice are the functional-first methodology and language features (such as tuples, lists and pattern-matching), the strong focus on immutable data, the inclusion of key typing features relevant to scientific and numerical programming (including F# units of measure), the increased use of expressions as a form of software re-use (including language features such as object expressions), the succinct representation of object-oriented programming, the declarative and compositional model of asynchronous programming (appearing in a future version of C#), and the inclusion of a dynamic interactive compiler called F# Interactive for scripting.

F# can be surprisingly intuitive for C and C++ programmers. Perhaps the thing they will notice the most is the immediacy of programming with F# Interactive: some C++ people get really surprised that it is so easy to get your hands on data and play with it in a strongly typed language, while still getting great performance. Software becomes fun and explorative again.

What are some of the best resources for F#, including education and practical use?

The two places to look are www.fsharp.net and www.tryfsharp.org. The first is the MSDN developer centre for F#. The second is something we've done over the last year with Microsoft Research Connections, and is a great site where you can play with and learn some basic F# coding in your browser.

In what scenarios would F# be a bad solution?

F# is designed as a value-add language to augment what is already there in .NET. This means that you shouldn't see it as a wholesale replacement for C#, VB and C++. For example, we don't advocate rewriting components just to move them to F#. Likewise, we don't advocate writing line-of-business apps with F# (except perhaps where you are utilizing F#'s special features in important ways). We also recommend that core matrix-crunching algorithms normally utilize native representations, often via a .NET wrapper for a native math library. Finally, there are some places where managed languages are not the right solution, e.g. C# is yet to be widely used for core operating system components and core components of top-line games. However, this way of thinking can go too far: for example, nearly all modern server-side systems can be developed and delivered in managed languages, leading to important productivity gains.

How do you see F# evolving in the future?

People thirst for simplicity. People need simple solutions to the problems that really matter: data access, code development, deployment, cloud computing, Web programming and parallel programming, to name but a few. One of the exciting things about working in the Visual Studio team is that there are experts in all of these domains working in unison.

The area that's really been interesting the F# team is data access, especially the amazing information-richness that is exploding on the Web and in the enterprise.  Functional programming thrives on data, and what we see is a confluence here. F# can have a role in bringing these together: Information-rich world meets functional programming super-drug. We're putting this vision together in a feature called F# Type Providers, something we've begun talking about at TechEd and PDC. Type Providers are an extensible architecture to give the F# programmer strongly typed access to an ocean of data from the Web and the enterprise, including sources such as SQL, SharePoint, WMI and OData.

What are some of the most requested F# features your team is working on for future versions?

F# tooling in Visual Studio 2010 consists of IntelliSense, quick info, interactive type-checking, projects, debugging and F# Interactive. People often ask for additions and improvements to this tooling. In some cases we will be making the improvements ourselves; for example, in IntelliSense. Realistically, however, F# tooling won't encompass all the features you get in C# and Visual Basic. This is one reason why we did an open-source release of the F# compiler, as it helps enable the community to fill in some parts of the tooling through Visual Studio extensions. We are really happy to work with the F# community to help them to add to Visual Studio and/or the Mono-based tooling.

How active/involved is the F# community?

The F# community is great! One critical thing they've done is the F# online templates (under "New Project", "Online Templates", search for "fsharp" in Visual Studio 2010).

It's one of the real joys of our job to work with community members. We just see countless examples where the F# community members are answering questions and helping people do interesting things with the language. For example, we have one of the highest and most complete response rates on stackoverflow. We're really impressed with the quality of answers and blogging as well.

Posted by Keith Ward on 09/06/2011


comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube