Why did Microsoft invest so much in F#?

Note that F# began life as Ocaml on the CLR, not another language from scratch. Then it picked up "light" syntax and then moved to light as the default syntax. Also note that F# has been around for a while now, so yeah C# 4 isn't bad but C# 4 wasn't even on the horizon when F# got started.

IronPython has had working (albeit beta) VS support for nearly half a year now.

ironpython.net and get IronPython toools for Visual Studio.

Don Syme: That's a small part of the sequence. The visional design of the .NET platform was very much expected to be a multilanguage platform from the start. Right back in 1998, just in fact as our research group in programming languages started at Microsoft and I joined the team and then other 10 of us joined the team, we were approached by a guy called James Plamondon, who started the project called Project 7, which was about getting 7 academic and 7 industrial programming languages on each side to target the .NET common language runtime and really check out if it was good enough, to see if design changes could be made early on in the design process of .NET to make sure it was good enough for a range of programming languages.

Some of those design changes were made, like tail calls were, for example, were added in the first version of .NET and that was a very interesting project because they gave a lot of way to our group and researchers at Microsoft to make connections between the academic programming world and .NET. We have seen that there are a lot of people working on .NET over the years, and also let our group work directly on .NET with regard to .NET Generics and other proposed extensions to .NET - we got these researchers engaged with the system.

We sort of knew there were opportunities to do new languages, but to contribute to existing languages like C# and also to do new languages in this kind of context. We talked a lot about doing a systems programming language of some kind, something that would effectively sit between C and C#, that you'd be able control memory usage and maybe get safety properties at the systems programming level.

We ended up not pursuing that, although people are still interested in doing "managed" systems languages, say languages you could drive a whole operating system in or write large portions of Windows in. Then, at the other end, we are interested in doing these expressive functional languages. Haskell .NET was something we looked at closely, we always had in mind to do NML as well, there is a project called SML.NET, which is a very good implementation of standard ML for .NET with a Harley optimizing compiler and the like. We learned a lot from that - a great project!

==== The paragraph below is the most relevant to the Question ====

I took what I learned from .NET Generics and saw that there was a chance to do a ML like language fitted very closely with .NET. During this time we had a go doing Haskell for .NET, we actually got a long way in doing that, but in the end there is quite a lot of dissonance between Haskell and .NET. The purity is one aspect of that so you are writing monadic code whenever you use the .NET libraries, which would be perhaps unusual, would lead you to writing more monadic code than you would like. Also, Haskell didn't have any tradition of adding object oriented extensions to Haskell.

====================================================

There was one project called O'Haskell, which was interesting, but there was something about Camel which had a tradition of taking a call language and then making extensions to it, changing it, experimenting it, but taking a core paradigm that works very well and then making it fit to a context. In a sense, in Haskell there are too many points where the model wasn't going to work in the context of .NET and you get too much dissonance across the interoperability boundary in particular - actually there are some serious challenges in making it run well at all. That was definitely an interesting project and I think a few other people have tried the Haskell .NET, but we didn't continue with the project.

Source: http://www.infoq.com/interviews/F-Sharp-Don-Syme

When I used it no one wanted to learn F#, but if I put a nice OO interface on top of whatever I wrote, packaged it as a DLL the other devs would be happy to use it.

F# isn't just cool, it will make you write better code, faster. The zen of it makes you follow a better path. Think about how many bugs go away when you make all sides of an 'if' 'else' block return the same data type.

Think about how much more sense returning an out parameter as a tuple makes. I'd much rather write

  let value = match dict.TryGetValue("foo") with
              | (true,val) -> val
              | (false,_) -> "default"

  string value;
  if(!dict.TryGetValue("foo", out value)){
      value = "default";
  }

The other thing about F# is that it's FAST, fast like beating C at the burrows-wheeler transform.

Some things about F# are consistent with the pet project theory:

- The language was developed by a team in Microsoft Research, not by a product team. If a product team thought there was a good product strategy for the language, they would have taken it over.

- Some of the reasons given for F# are not a direct customer benefit. Example: show that CLR can support languages other than C#.

- Given the question here on HN, it's not obvious to some people why Microsoft invested so much in the language.

I raising the question about why Microsoft invested in and released the language and not making a statement about the quality of the language itself.

Since pure functional languages are easier to parallelize, Microsoft is interested in languages like F# for their performance on multicore systems.

With regards to your 'from scatch' question I think f# is designed in order to bring useful functional programming techniques to the .net community. This isn't necessarily possible to do with Haskell because of the difference between the way function calls work in lazy and strictly evaluated languages.

Its worth noting the other aspect of the f# story. Ocaml is a huge influence on the f# language design. It was originally pushed during the 1990s as a language that had combined functional programming with pragmatic compromises - for example OOP and the existance of an efficient implementation. Unfortunately the Ocaml implementation suffers from poor performance in multicore environments, particularly constrained by its garbage collection system. This wasn't a huge problem in the mid 90s, but its looking like a problematic design choice with hindsight. Since f# builds on the .net VM it doesn't have this multicore issue.

C# is not even close to F#, feature wise. C# and VB have taken the path of picking the "sweet spot" of features, and adding special compiler magic to implement those exact things. So, on some comparisons, C# looks just great. But actually going off the blessed path means a lot of pain. Here's a quick list of why F# is nicer:

  - Vastly more lightweight syntax
  - Far more advanced type inference
  - Sequence expressions (and list/array comprehensions)
  - Modules
  - Hierarchical code (nest modules in modules, functions in functions)
  - Interactive mode (FSI)
  - Custom dynamic support (it provides an operator, you provide the implementation)
  - Inlining support (handy for type tricks and great for performance)
  - Recursion support (either tailcalls, or the compiler rewrites your functions to loops)
  - Object expressions (create an object implementing an interface on the fly)
  - Workflows (especially for async code)
  - Full quoted code (C#'s Expression<T> is pretty weak - again, it was just made to enable certain translation to SQL scenarios)

Oh, and it still has nearly all of C# imperative/OO features. I can pass addresses, allocate off the stack, use pointers, and so on. On the OO side it has everything except the ability to create new "protected" visibility members.

Basically, even if you know nothing about functional, and just code in an imperative and OO style, F# is better.

> Why not more effort porting an existing language to the CLR?

It didn't work very well. The mismatch between your favorite language and .NET caused 2 problems. First, the procedural/OO style required to interop with .NET bled into the rest of the program. Second, performance sucked for dynamic types, tailcall, small object allocation, etc. The result was you'd write a program in your language that looked similar to C# but ran 2X slower.

Scala and Clojure get around this by being new languages that try to match the JVM platform better. Plus they provide fat libraries so you don't have to see Java objects too often.

> F# is cool, but C# 4.0 does not seem to lack much, feature-wise.

C# doesn't have algebraic data types, pattern matching, currying, active patterns, metaprogramming, asynch workflows and global type inferencing. There's more, but you see my point.

Having been out of Microsoft for quite a while now, I can't answer the question authoritatively.

However, having helped make .NET language-neutral, I can offer these two specualtions: (1) After a decade of making the.NET Runtime and Visual Studio.NET language-neutral, implementing F# required much less investment than you might think (although I'm sure it wasn't "cheap"). (2) When it comes to cloud computing, Microsoft is "all in," and functional languages are ideal for cloud computing (being naturally parallel - see the Church-Rosser property of the lambda calculus). This is the main reason, I suspect.