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.

Microsoft Research has been working in Cambridge for 17 years to advance the state of the art in Computer Science and to feed the best of technology into Microsoft’s products.  Today around 200 staff work at our centrally positioned lab, in the heart of Cambridge’s new CB1 business district by the railway station.

We work on innovative, cool technologies that you’ve heard of, such as Microsoft Kinect, F#, .NET Generics, Haskell, Azure ML and Xbox Trueskill, to name but a few.

We are looking for world class engineers to work in a number of our research groups.  These software development roles are to work in close partnership with our Researchers and Engineers in Cambridge, and with our hosted product groups, on some of the most innovative technologies in Computer Science.

Our Research Themes

Human Experience and Design

Machine Learning and Perception

Programming Principles and Tools

Computational ScienceSystems and Networking

Required Experience/Expertise

Superb software development skills, for example in C#, F# and/or C++.

Demonstrable experience shipping commercial software products or services.

Excellent oral and written communication skills.

Strong problem solving ability.

Degree in computer science, engineering or equivalent. 

Microsoft Research is an exciting place to work.  You get your own office, an Aeron chair, sit-stand desk, multiple screens, and 24-7 free coffee and soft drinks.  We have an excellent “Food Lab” cafeteria, an onsite gym, a pool table, table tennis and Xbox, free car parking, and one of the best views of Cambridge and the surrounding countryside from our 5th floor roof terrace.

We offer a competitive base salary with bonus and an excellent package of company shares and benefits.

For more information or to apply, visit https://careers.microsoft.com/jobdetails.aspx?jid=166206.

Some latest developments in this area have been:

• There were two talks on F#/GPU/Finance at the NVIDIA GTC Conference covering both how F#/GPU programming is really used in real, large-scale financial applications, and how F# enables the design of a language-integrated compiler targeting LLVM:
   
• GPU Applications for Modern Large Scale Asset Management   (Daniel Egloff)
   
• How to Design a Language Integrated Compiler with LLVM (Xiang Zhang, Aaron Brewbaker) 
   
   
• Alea.cuBase 1.2.680 has been released – congratulations to the team from QuantAlea!  Alea.cuBase is available on NuGet.
   
• QuantAlea have released a first version of CUDALab, demonstrating live documentation for CUDA kernels written using F# scripts and Alea.cuBase.
   
• Vulpes is a Deep Belief Net written in F#, and using Alea.cuBase to access the GPU. The source for Vulpes is now available on GitHub.
   
• FSCL (the F# to OpenCL compiler) has matured considerably.  FSCL increases the abstraction over OpenCL programming on heterogenous parallel platforms. It includes an F# to OpenCL compiler and a kernel execution runtime that, together, simplify developing OpenCL kernels and exploiting all the different, heterogenous parallel computing devices that populate most of the today platforms.
    
• Nessos Technologies have released GpuLinq on GitHub. This is implemented in F# but can be applied to C# LINQ expression trees as well. To quote, GpuLinq's main mission is to democratize GPGPU programming through LINQ. The main idea is that we represent the query as an Expression tree and after various transformations-optimizations we compile it into fast OpenCL kernel code. In addition we provide a very easy to work API without the need of messing with the details of the OpenCL API
  

 Together these point to how F#'s unique language features truly enable a new level in General Purpose GPU programming.

TL;DR:

F# and Xamarin triumphed. I can’t imagine writing such a complex mobile app in another language. Instead of 6K, equivalent Java code would be in the 50K LOC range and of untenable complexity. I think F# is a great language for mobile computing. It is surprising how much you can do on these devices today.

 Full version here

Applicants must currently be pursuing a Masters or PhD in Computer Science. More details on applying can be found here:research.microsoft.com/en-us/jobs/intern/about_uk.aspx

This year, I personally am particularly interested in sponsoring internship applications in one or more of the following areas

• Applying experimental type systems and type-provider mechanisms to evolving schemas in scalable data sources such as massive entity graphs (Freebase, the Google Knowledge Graph, Microsoft Satori).
• This work would focus on the temproal evolution of schemas in a range of type-provider integrated information sources. It could emphasize either theory or implementation, depending on your interests.

• Developing production-quality type providers for Hadoop and/or other scalable data processing systems, based on prototypes we already have.
• This work would focus on implementation, testing, quality and delivery, plus some design of language-integrated programming and query models for Hadoop or other scalable data systems

.

• Visual Studio tooling for F#.
• This work would be implementation-oriented and focus on community-focused design and implementation of additional Visual Studio tooling for F#. 

All candidates are expected to be highly self-motivated and able to pursue a line of investigation or implementation through to delivery.

Please have your applications submitted by Sunday, 21 February, 2014.

Thanks

Don

We’re starting to collect formal applications, and to schedule interviews for researcher and postdoc positions at Microsoft Research, in Cambridge.

The applications are assessed by the Programming Principles and Tools group and senior management at MSR Cambridge. I am personally interested in arguing in favour of:

• Stellar applied researchers who have radical-but-practical ideas for simplifying XYZ programming systems [ where XYZ = scalable, cloud, data, systems, GPU, FPGA, probabilistic, dependent, reactive, runtime systems, ...]; or

• PhD-or-similar-experience people who have a passion for F# language, applications, tooling and community and are willing to come and work as F# contributors in the context of a strong applied research agenda in one or more XYZ areas above; or

• You Fill It In Here But Make It Interesting, Compelling and Fun :)

If you fit the bill and think Cambridge UK is the place for your next life and career step, then please go ahead and submit a formal application in the system, also email me.

research.microsoft.com/en-us/jobs/fulltime/apply_researcher.aspx

The first round of scheduling has already started, so it would be great if you could lodge an application on the system.  Please allow some time for us to gather reference letters from your referees. If you have a profile in Google Scholar and Microsoft Academic Search, that's useful to have. But equally a great record at hacking out and delivering influential and innnovative research systems is very appealing, even better if that is in the context of industry-relevant topics.

You can also get in touch directly with me at any time.

Many thanks,

Don, also for Andy Gordon and others at Microsoft Research, Cambridge

Some explanation: the talk does not say that functional-first programming is right "everywhere". However the talk does say the functional-first seems to be particularly effective today "for some kinds of tasks, some of the time".  Likewise, the talk does not say that functional-first programming is only useful for these tasks, rather that it is particularly effective for them.

I encourage everyone to keep sharing your stories about succeeding with ANY kind of functional-first programming in industry.

And a Happy Functional-First New Year to everyone!

Don

Yesterday I gave a talk at NDC London 2013 called "Making Magic with F# Type Providers"

Here are my slides : www.slideshare.net/dsyme/making-magic-with-f-type-providers. The raw PPTX is also attached further below.

data-type-providers-fsharp.pptx