First impressions of F#

I’ve just read through Foundations of F# and written one or two trivial scripts in F#, so it’s too early to make a proper balanced assessment of it as a language. However, I wanted to record my immediate reactions to it so far while they are still fresh in my mind.

I don’t have a strong background in functional programming, but I’ve dabbled with Common Lisp, Haskell, Clojure and Scala. I’m excited by the new trend of functional languages targetting the JVM and .Net CLR, since this seems to solve the major problem with functional languages of the past in not having library code in sufficient quantity and quality.

Targetting either of the widely available virtual machines seems to be a double-edged sword, however. From what I can tell neither the JVM nor the CLR are well suited to functional languages. Clojure, Scala and F# all seem to have (and I’m being polite here) idiosyncracies forced upon them by the underlying runtime.

My immediate reaction to F# is that it seems to work hard to make it easy to interact with OO languages on the CLR, at the expense of being a great functional language in its own right. Haskell and Clojure both have strong (and different) concepts of lazy evaluation that permeate the language and let you program in a whole new way. If F# has this, it’s not been obvious to me in the first couple of hours using it.

Nor (as far as I can tell) does F# have particularly good support for parallelisation, which is one of the key advantages of functional programming for me. In my opinion Clojure has the strongest claim here, having been built from the ground up to be parallelised safely. Haskell apparently has very strong tool support in the form of ghc. What does F# offer in this direction? It’s not at all clear to me, but with the ability to create mutable fields with a single keyword, and no support for inferring immutability via the type system, it doesn’t fill me with confidence.

Leave a Reply

Your email address will not be published. Required fields are marked *