[ The opinions here are entirely my own etc etc. ]
Dear World,
With regard to this InfoQ article…
I’ve said this like a thousand times, but please use the terminology “Visual F#” or “The Visual F# Tools” 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, multi-vendor, cross-platform and open source: it’s existence as a language and ecosystem does not fundamentally depend on Microsoft. The days of existential dependence are long gone and the world needs to wake up and realize it. 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 – is Visual F# and The Visual F# Tools. Microsoft Research also contribute to the language design, but so do others.
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. But other independent contributors look after Android, iOS, Mac, Linux, FreeBSD and a large range of editing tools. (There are of course some things that only Microsoft can 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, 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 “Visual F# Tools”. 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 Visual F# Tools 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, that 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. Independence empowers strong community dynamics that ultimately benefits all users.
Thanks :)
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 Visual F#, the F# packaging from Microsoft.
Plans about what’s next for Visual F# 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 Visual F# 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 Visual F# on par with C# in Visual Studio. 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 Visual 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 Visual F# 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 Visual 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 F# team, and for the F# ecosystem more broadly. Contributions to the F# code and feedback are welcome.
Image may be NSFW.
Clik here to view.