The Early History of F# [pdf]

https://fsharp.org/history/hopl-draft-1.pdf

by ingve • 8 years ago

147 53 8 years ago

mamp• 8 years ago

A really interesting and honest write up by Don Syme on the goals and trade-offs required to get a functional language implemented on .Net, in pre-open Microsoft.

I use F# for anything critical and/or complex. It's a parsimonious way to represent domain models and a clear way to express computation.

My main regret with F# is that I didn't get into ML languages earlier in my career.

BTW a recent book, 'Stylish F#', is the best introduction to F# so far (no affiliation, just bought a lot of F# books over the years).

https://www.apress.com/gp/book/9781484239995

noir_lord• 8 years ago

Thank you for the book recommendation, I've been looking at F# as a new language for a while but there are quite a few books and it's sometimes hard to figure the wheat from the chaff.

mlevental• 8 years ago

how does 'stylish' compare with 'get programming with f#' ? i read get programming with haskell and it was good (even if too slow).

kiteason• 8 years ago

Author of 'Stylish F#' checking in. Thanks for the endorsement!

Incidentally 'Stylish F#' is intended to be an intermediate book so it might be worth reading Chris Smith's 'Programming F#' or one of the other intro books first - or some beginner online material. That said if you had C# exposure and were determined, you could probably get away with using 'Stylish F#' as your intro.

Nelkins• 8 years ago

Funny to see early predictions about the .NET ecosystem:

"Perhaps I am wrong, but let me state what I believe about this stuff. ...C# is not really important as it will never reach the 'mass' of VB..."

bunderbunder2• 8 years ago

I think that the early expectation was that, since (non-.NET) Visual Basic was being sunsetted at the same time, VB6 developers would quickly adopt VB.NET, and that would lead to VB quickly becoming the most popular .NET language.

Which, yeah, proved to be hilariously wrong. Here we are in 2019, and I can still name several actively maintained applications that are written in VB6.

Another thing they couldn't have really known at the time was how exactly C# and .NET would evolve over the following decade. Once upon a time, interacting with COM interfaces was much easier in VB.NET than in C#, and that made it relatively more attractive as an enterprise dev language. C# 4 more-or-less closed that gap -- VB.NET's other practical advantages are so minor they don't really even bear mentioning.

davidwihl• 8 years ago

My recollection is that .NET was largely a research project within Microsoft around 1997. It was when ScottGu used .NET to build ASP.NET (circumventing many limitations of Classic ASP that he also helped build) that .NET took off as a viable commercial platform ushering in further development and extended language support including F#.

agumonkey• 8 years ago

really ? Gates promoted heavily his idea of network OS hinting a .Net as the foundation. Maybe I misunderstood or maybe it came later ...

pjmlp4• 8 years ago

.NET percursor, Ext-VOS was supposed to be an improvement on COM, COM Runtime.

Then they pivoted it into a managed runtime.

avinium2• 8 years ago

I've been slowly migrating from C# to F# for our automation assistant (https://lexico.io - not yet usable yet but will be soon), and like the top comment here, my only regret is that I didn't do so sooner.

Functional languages allow logic to be expressed so precisely and concisely. I hazard a guess that every F# module is 2/3 the LOC of its C# equivalent, with the added advantage that everything is incorporated into a single file.

F# certainly has its quirks (as a language, I think Clojure is actually cleaner - but that comes with the downsides of the JVM and .NET interop is a huge advantage).

Part of me doesn't want to spread it around too much, because I feel like I've discovered some hidden edge over my hypothetical competitors.

astine• 8 years ago

I think Clojure is actually cleaner - but that comes with the downsides of the JVM and .NET interop is a huge advantage

There is a dotnet implementation of Clojure if you're interested: https://github.com/clojure/clojure-clr

pjmlp4• 8 years ago

I usually lags behind the official Clojure implementation.

avinium2• 8 years ago

Oh wow - wasn't even aware of this. Will check it out :)

clausok• 8 years ago

I share the same regret. In fact, by far my biggest regret in my career was missing an opportunity in 2008 to switch to F#. The portfolio management team I was with departed a large hedge fund to start our own. I knew I had 8-10 months before we started trading again. It was every programmer's dream: hit the pause button and get a chance to leisurely refactor everything you've never had time for. Even enough time to completely change tool sets. I remember discovering F# during this period and it was as though Don Syme (the F# BDFL) had listened to all my complaints about C# & Matlab and built a language specifically for me. Ultimately, I chickened out. I was afraid Microsoft would eventually Foxpro F#; or I'd hire people who'd tell the CEO of our firm that I was nuts and had built all our systems in an obscure language. By late 2012 the ecosystem had matured tremendously and I finally switched to F#. I really wish I had those four years back. F# would have saved me a ton of while-on-vacation troubleshooting from 2008 to 2012.

melling• 8 years ago

“Since around 2007 strongly-typed functional programming has shifted from relative obscurity to be a central paradigm in programming. C#, Java, C++, Scala, Kotlin, Swift, Rust and TypeScript now all include elements of strongly-typed FP, and Apple executives extolled functional features at the launch of Swift in 2014, including pattern matching, generics, option types, type inference, tuples and closures, something unthinkable in 2005.93 Haskell, F# and OCaml have all grown in use, and newcomers such as Elm and ReasonML are also finding good adoption.”

I feel like we’ve taken the long way to popularize functional programming.

ChrisSD• 8 years ago

Class based OOP had held a tight grip on developer mind share since the 90's at least. Breaking that grip is a slow process.

pjmlp4• 8 years ago

Yes, although the 90's also had other models of OOP, they just failed to gain mindshare.

The most mind blowing variant was BETA, but I guess pattern based OOP was probably a bit too much for the common dev.

gazarullz• 8 years ago

I worked quite a bit with F# and Scala.

I really like F# pipelines and function declaration syntax.

On the other hand I've found Scala's case classes cleaner than F#'s (maybe that's because I am coming from an OOP world).

Additionally F# has a cleaner pattern matching compared to Scala.

Both languages have very good support for actor model concurrency (love akka actors and .net agents)

I think that if F# would have had a rich ecosystem the way Scala has, it could become a real contender.

(my 2 cents on F#)

bad_user• 8 years ago

I think Scala's pattern matching is pretty cool too. I was surprised by how weak Haskell's pattern matching is by comparison (by default, I don't yet know of any GHC extensions that could help).

That said F# and Scala aren't really competitors. The real competitors are the mainstream languages, like JavaScript, Java, C# and Python and that's what their marketing should target.

dwohnitmok• 8 years ago

If you're talking about custom `unapply` and `unapplySeq` functions, the equivalent-ish GHC extension is `ViewPatterns`.

Tarean• 8 years ago

Pattern synonyms are really expressive but the complex version is kinda headache inducing:

http://hackage.haskell.org/package/lens-4.17/docs/src/Contro...

This creates a bidirectional pattern synonym - you can both match and construct values with it:

    foo :: Cons' s Char => s -> s
    foo (a :< b) = 'c' :< b
    foo other = other

Pattern synonyms make completeness checking undecidable so you need to give manual hints to get a nice api. It also wreaks cost models - is foo O(1) or O(n)?

pjmlp4• 8 years ago

As someone that spends most of my work time on .NET, it would be nice if the .NET team would take F# into consideration in some of their design and tooling decisions, instead of looking just into VB.NET and C#.

As it is, F# is like the cousin that doesn't always get the party invitations, while JavaScript, Python and C++ get the them, even if they don't belong to the club originally.

bachmeier• 8 years ago

How is this from 2002 if it talks about events through 2018?

nuclx• 8 years ago

The date tag wasn't there previously. Someone added it by mistake as it seems.

sctb• 8 years ago

Removed!

adgasf7• 8 years ago

We are currently rewriting Buckaroo in F# (https://github.com/LoopPerfect/buckaroo/tree/buckaroo-redux ); previous versions were in modern Java. The productivity gains are tremendous... FParsec, async, asyncSeq, records, match expressions are all a huge leap over what most OOP languages offer. Deployments are also much easier thanks to Core RT.

F# feels like a secret weapon.

dmead• 8 years ago

I want to ask an annoying question.

Why F# and not haskell?

adgasf7• 8 years ago

The main reason was that team had more experience with F#. I think it is also more approachable than Haskell for OOP devs (C# to F# comparisons are quite common on the internet). I'm sure Haskell would also have been an excellent choice though :)

BeetleB• 8 years ago

Not OP, but some reasons usually thrown around:

F# has the power of .NET and its libraries behind it.

Haskell's insistence on purity and laziness does increase the time it takes to design things well. F# makes it easier to violate purity in controlled ways, and is not lazy be default.

People who've used both say it's a lot easier to get lost in abstractions with Haskell, and there doesn't appear to be a clear "stopping" point. A common statement by people who move from Haskell to OCaml/F# is "I spent N years on Haskell but didn't produce much. In 6 months of (OCaml|F#) I've produced more than in those N years with Haskell."

The bottom line: The .NET libraries and slight relaxing of purity/laziness allows for more productivity.

(I'm not an expert on either - just repeating what you normally find in the threads).

nikofeyn• 8 years ago

f# is a multi-paradigm language. it allows you choose what paradigm fits the problem best and allows you to easily mix paradigms, and it does so in a clean way. haskell does not have this flexibility. this is f#'s power.

Kip9000• 8 years ago

C++ package manager written in F#. This should be the tagline :P

adgasf7• 8 years ago

Haha indeed!

My position is this: different programming languages have different strengths and weaknesses. C++ is crazy fast, but it lacks many high-level features (most notably do-notation). Efficiency and performance are its niche. Conversely, F# (or any ML) is very good at expressing complex control flow, but performance is a secondary concern.

Package management is an IO-bound SAT problem, so we are using the best tools for the job.

lmm2• 8 years ago

Why not Scala? That's a very similar language to F#, and JVM interop would let you do a gradual migration.

adgasf7• 8 years ago

We wanted to make significant changes, so a gradual migration would not have been possible regardless of language. Regarding Scala vs F#, I do not know enough Scala to comment. Perhaps someone else can weigh in?

saberience• 8 years ago

The scala toolset is incredibly crap though. Ask the engineers on my team about the huge pains of transitioning to using IntelliJ from Visual Studio, or the joy of trying to make SBT do what we want it to do, then trying to use Maven instead.

Any new engineer we get started with Scala has to spend about a week making their local setup work. It's a total pain in the arse.

Verdex3• 8 years ago

I think the reason why is two fold.

1) The type system is focused on mathematical types as opposed to compiler tags. Mathematical types are about ensuring that a function will not fail. Compiler tags are about ensuring that you generate the correct asm op codes. Mathematical type systems allow you to have an easier time knowing the code works.

2) Algebraic data types provide both an AND component and an OR component. That is, you can do type X = A of int * int * int; AND you can do type X = A of int | B of char;. C# style languages provide you with the AND component (class A { public int B => ...; public int C => ...; }). However, they don't provide the OR component. You can create it by constructing weird type hierarchies, but this isn't idiomatic AND it also isn't closed. With an algebraic data type you can know that all of the cases are handled in a match. This isn't something you can ensure in C# (at least not naturally or easily).

Ultimately, I don't think functional programming provides anything that has to be better than object oriented programming. It's just that there are two facilities that tend to go with functional programming that allows a better way to model the problems that we encounter.

willtim2• 8 years ago

Missing from your list is arguably the most important difference: programming with mathematical (immutable) values. This allows one to build very high-level abstractions and easily reason about correctness. OOP languages simply were not designed for this style of programming.

There are also many other significant differences. I estimate I am about ten times more productive in Haskell than Java.

phillipcarter• 8 years ago

For anyone interested in how some of the modern history is shaping up from a language perspective, check out the Language RFC repo: https://github.com/fsharp/fslang-design/

Timothycquinn• 8 years ago

Excellent article. Kudos to the authors. I look forward to digging into your references.

This would be a great primer for young developers to get a good overview of of programing paradigms and modern OS language evolution over the last 25 years. I will be sending this along to all my peers.

Also, I am impressed with .NET and Microsoft's embrace of OpenSource. I am one of those developers who got stung by Microsoft in their earlier days when they were the true Evilcorp and now they really seem to be less evil with this embrace.

I will actually consider using F# for my future projects, but of course as long as it runs 100% on *Nix platforms.

mlinksva• 8 years ago

Don Syme talks a bit about this paper at the beginning of https://www.youtube.com/watch?v=aw2BAxG3bdM from a recent F# conference.

He also talks about F# history in a 2016 interview https://channel9.msdn.com/Shows/On-NET/Don-Syme-on-F

The Early History of F# [pdf]

Related Stories