An open letter about the terms "F#" and "Visual F#"

[ The opinions here are entirely my own etc etc. ]

Dear World,

With regard to this InfoQ article…  

I’ve said this a few times before, but please use the terminology “Visual F#” or “The F# Tools for Visual Studio” when talking about F# at Microsoft. And somehow make sure people reporting on an event do the same :)  

F# as a language is fully independent, cross-platform, open source and multi-vendor - that is, multiple packagings based on the same shared open implementation. F#'s existence as a language and ecosystem does not fundamentally depend on Microsoft. You can program productively with F# on a fully open stack in numerous fully open editors on fully open operating systems and you will always be able to do that, at least until the day comes in the far distant future when none of us are doing anything recognizably close to what we call programming today! The days of existential dependence are long gone. Among other things, F# has an independent community-driven foundation with a strong membership (see fsharp.org).

What Microsoft make – partly through contributions from the community – are the F# Tools for Visual Studio (also known as Visual F# - though in truth they have always been more focused on coding rather than visual designers). Microsoft Research also contribute to the language design, but so do others. Microsoft also provide quality-assurance of the core F# implementation on Windows, and will do the same on CoreCLR, a fabulous contribution to be sure.

This is important from a number of perspectives. First, Microsoft are not the only people investing in F#, nor do we uniquely define what is/isn’t being done in its ecosystem. Microsoft primarily contribute the F# tooling in Visual Studio, Windows and on CoreCLR. That's great. But other independent contributors look after Android, iOS, Mac, Linux, FreeBSD and a large range of editing tools. See fsharp.org for a guide. (There are of course some things that only Microsoft can currently do - like .NET Native support for F#, but that's somewhat unusual for the industry: for most purposes, anyone is free and welcome to develop and contribute F# support for anything, without asking Microsoft. My favourite recent example is Ionide, giving F# support in Atom).

Second, by scoping areas of activity clearly, we actually empower the community to build and achieve other outcomes for the language according to their own priorities. This is somewhat counter-intuitive but is key to success in open technologies. This approach has led to a nicely booming F# ecosystem over the last three years – essentially independent of Microsoft – with the F# community "owning the message" about F#, spreading it widely, and F# support growing strongly in Xamarin, Emacs, Atom, Mono, Vim, Sublime and more, in addition to huge improvements in Visual Studio tooling from the community. The F# community are investing in cross-platform quality, docker containers, tooling, mobile, web, data and cloud, and everyone in the community reaps the benefits of those investments.

To reiterate, when talking about Microsoft and F#, I'd encourage everyone to use the terms “Visual F#” and “The F# Tools for Visual Studio”. F# as a language is independent, multi-vendor (based on the same open implementation) and cross-platform. Those of us at Microsoft certainly contribute to it a lot – and proudly so – but then Microsoft also does that for many other open technologies. But Visual F# and the F# Tools for Visual Studio are the things Microsoft actually make. This is a simple linguistic change but is consistently clarifying for people. Words matter.

I’d actually encourage everyone in the world to do the same for C#. In my opinion, the C# language also needs a certain sense of cultural independence from Microsoft - certainly, Microsoft contribute to C# and its ecosystem hugely, but so do many, many other people and companies. Systematic application of this kind of thinking is the best thing you can do to help F# and C# develop as open ecosystems with a strong internal dynamic that will sustain them for decades to come. Independence and openness empower strong community dynamics that ultimately benefit all users. The same applies to .NET Core CLR - where, as far as I understand things, the FreeBSD community were the first to work towards an independent packaging of that technology. I'm confident there will be many more such independent packagings in the future, and many contributors too.

Happy programming everyone: whether it be via the Visual F# Tools (much loved and much used to be sure!), other packagings of F#, or in your own favourite programming languages.

Best

Don

p.s. For example, the article could have come out as below :)

On October 17th, F# Gotham gathered experts who presented different aspects of the language and tooling such as asynchronous programming, computation expressions, optimization, FParsec and Xamarin.Forms. The presentation of David Stephens and Jay Schmelzer, respectively program manager for Visual F# and director of program management for Visual Studio, focused less on the technical aspect and more on the bigger picture. They presented the past, present and future of the F# Tools for Visual Studio, the F# packaging from Microsoft.

Plans about what’s next for F# and the Visual Studio team were discussed at length and were the bulk of the presentation. As David Stephens explained, one of the top priorities is to port F# on .NET CoreCLR. This will bring portability and modularity to the language, as it is the end goal of the .NET Core project.

One of the challenges of the development of the F# Tools for Visual Studio is to keep up with the current developments in the .NET ecosystem, which is currently evolving at a fast pace. Furthermore, supporting the already existing technologies such as VS Code, WPF, Windows Forms, ASP.Net and Universal Windows Apps is also to be considered.

As several planned projects for Visual F# are already implemented for C#, David and Jay were asked if the end goal was to put The F# Tools for Visual Studio F# on par with C#. The answer was no, as things are moving fast and new features implemented for other languages such as Visual C# do not necessarily have the same priority for F#. This would also mean each new release would need to support both F# and C#, which would slow down the pace too much in a competitive environment. Instead, projects will be implemented on a priority basis, based on the language usage. Community feedback will also be considered in the prioritization process.

Another question raised was if the F# for Visual Studio will support Roslyn. They started by making a clarification about what is Roslyn. Roslyn is the name of the rewrite project of the C#/VB compiler. As such, it makes no sense per se to support Roslyn. The Roslyn workspaces, however, provide an higher level API and are not tied to a specific language. Therefore, the F# support of Roslyn would actually consist of extending the F# compiler to support the Roslyn Workspace API. David and Jay then explained that this project is in the plans, but a few select ones such .NET CoreCLR have higher priority. There is, however, nothing to stop the community from forging ahead in this area and using the F# Compiler Service to implement the Roslyn Workspace APIs.

Throughout the presentation, importance of open source has been reiterated for Microsoft and the Visual Studio F# team, and for the F# ecosystem more broadly. Contributions to the F# code and feedback are welcome.