What do you think of the F# language? [closed]

Question

What do you think of the F# language? I would like to learn it's positive and negative points.

What is your experience with this language? When should or shouldn't someone use F#?

See also: F# at Microsoft Research

Answer 1

I have mixed feelings about F#. I have a strong functional programming background and many years of C# experience, so I can see it from both sides and I think that F# makes too many compromises to satisfy people from either group.

It's worth pointing out as well that .net is fundamentally an object-oriented imperative execution environment. It's not terribly well suited to a language like F#, so there are compromises to be made everywhere. At the end of the day, all F# programs need to be turned into a pile of CLI types and methods which, largely, have C#-like semantics.

There is a lot to like about F#, but I'm going to focus on the negative here, since the good things are more obvious and well documented.

• F# is very awkward as an imperative language, and a lot of the more imperative .net APIs end up feeling very clumsy (XmlTextReader I'm looking at you). An attempt to address the use cases that break/continue/return satisfy in C# (without involving computation expressions) would go a long way here.

• F# is somewhat compatible with a vaguely-defined subset of ocaml. This leads to cruft, lots of deprecated syntax and weirdness. Even worse, it seems to have no tangible benefit--it's not like F# programmers are reusing ocaml libraries. I understand why one might have done this in a research setting, but this should have been cleaned out of the language long ago.

• F# should have left out the "module system" if they didn't intend to do it right. An SML style module system (structures, signatures, functors) would conceptually work very well in F#. F# signatures are really just an alternative way to enforce visibility and don't actually serve to provide polymorphism like SML's signatures do. F# has generic types, but lacks generic modules. Lame lame lame. That said, a generalized higher-order module system like SML's would be very hard to represent directly in terms of the CLI. This would require a lot of effort to do right, and would probably cost considerably in compile time + code size.

• The anonymous function syntax is too verbose. It's downright depressing that C#'s lambda expression is cleaner.

• Calling into the .net api feels a little bit like doing interop--it's awkward to invoke methods with tuple'd arguments and you constantly end up converting data types (especially list -> array). This is probably difficult to fix--there are a lot of trade-offs involved in fitting an ml family language into the .net environment.

• F#'s type inference is closely related to ML's, but F# has to cope with overloaded CLI methods. I would have been happier if they had used a type inference scheme that supported deferral, since this would significantly reduce the number of required type annotations when interfacing with .net libraries.

• The compiler is unacceptably slow, especially on mono. We're talking hundreds of lines per second slow. I have a 4kloc F# program that takes 16 seconds to compile on a core 2 duo macbook pro. That is ridiculous.

Answer 2

What do you think of the F# language?

I love it!

I would like to learn it's positive and negative points.

Pros:

• Productive. F# captured the essence of ML that makes it such a hugely productive programming language.

• Efficient. F# captured the simple mode of compilation that makes the performance of ML code so predictable and .NET 4 makes it predictably fast.

• Interoperable. F# solves my single biggest gripe with previous-generation languages by providing safe high-level interoperability with the rest of the .NET platform. Scala and Clojure do the equivalent for the JVM.

• Exciting. The F# community are buzzing with enthusiasm and continue to amaze me with their incredible work, solving real problems and helping people. Our customers are using my work to do everything from building robotic trains to futuristic stethoscopes. I love being a part of that.

• Commerce friendly. Most of the F# community value my hard work and are willing to recompense me fairly for it. Clojure is another upcoming language built by an industrialist for industry and I have great respect for that.

Cons:

• Compiler is slow enough that you really start to feel it after ~50kLOC.

• Indentation-sensitive syntax means no autoindenting.

• F# doesn't have every academic language feature under the sun for me to tinker with when I should be solving real problems.

What is your experience with this language?

I've been building products and providing services around F# for 4 years.

When should or shouldn't someone use F#?

Impossible to say without more specifics. Find little projects and give it a try. I'm sure you'll be amazed. :-)

Cheers,
Jon.

Answer 3

Here are a few reasons F# is a great language to learn:

1. Immutable by default
2. Can be mutable (Just in case...)
3. Pattern matching
4. Monads
5. It is object oriented so interoperability with C# is not a problem.

Check out this little piece of my parser that uses partial active patterns to match productions in the ECMAScript language.

let (|KeyWord|_|) element =
    match element with
    | IdentifierName token ->
        let isMatch = keyWordSet.Contains token.value
        if isMatch then Some (element, token) else None
    | _ -> None

let (|FutureReservedWord|_|) element =
    match element with
    | IdentifierName token ->
        let isMatch = futureReservedWordSet.Contains token.value
        if isMatch then Some (element, token) else None
    | _ -> None

let (|BooleanLiteral|_|) element =
    match element with
    | IdentifierName token ->
        match token.value with
        | "true" | "false" -> Some (element, token)
        | _ -> None
    | _ -> None

let (|NullLiteral|_|) element =
    match element with
    | IdentifierName token ->
        match token.value with
        | "null" -> Some (element, token)
        | _ -> None
    | _ -> None

let (|Literal|_|) element =
    match element with
    | NullLiteral (element, token)
    | BooleanLiteral (element, token) -> Some (element, token)
    | NumericLiteral token
    | StringLiteral token
    | RegularExpressionLiteral token -> Some (element, token)
    | _ -> None

let (|ReservedWord|_|) element =
    match element with
    | KeyWord (element, token)
    | FutureReservedWord (element, token) -> Some (element, token)
    | _ -> None

let (|Identifier|_|) element =
    match element with
    | ReservedWord (element, token) -> None
    | IdentifierName token -> Some (element, token)
    | _ -> None

Explanation

When you specify an active pattern like (|...|_|) you are telling the compiler that a match won't always be made for this pattern.

This production in the ECMAScript language:

Identifier :: 
    IdentifierName but not ReservedWord 

is matched with the following code

let (|Identifier|_|) element =
    match element with
    | ReservedWord (element, token) -> None
    | IdentifierName token -> Some (element, token)
    | _ -> None

Another way you can write an active pattern is like this:

let (|Even|Odd|) number =
    if number % 2 = 0 then Even else Odd

Notice that every number passed in will return a match.

let doSomething number =
    match number with
    | Even -> printfn "%i is an even number!" number 
    | Odd -> printfn "%i is an odd number!" number 

Answer 4

• Pattern matching -- The biggest dream feature
• Active Patterns -- One plus
• Higher-order functions
• Imperative programming -- No need to think TOO functionally like Haskell.
• Computational expressions -- This is more powerful than monads, type-wise.
• Indentation syntax

The problems are:

• Compiler is too slow
• .NET pollutes the functional part and introduces weird syntaxes
• Curried function argument order problem (function subject object or function object subject or function acti)
• Curried vs. Uncurried problem
• F# functions vs. delegates problem

Answer 5

As a C# programmer who has recently been exploring F# by reading The F# Survival Guide, I can't help thinking that if I'd been exposed to it back when we were still using C# 2.0, I would have thought it was awesome. Now, however, that C# 3.0 has added LINQ and type inference and anonymous types and lambda expressions and all the fun with IEnumerables, I feel like all the things would have been better expressed in F# can now be expressed pretty damn well in C# too.

Also, as a stylistic judgement, my gut feeling that there was way too much going on with punctuation. Too many pipes and underscores and multi-symbol constructs like [| and -> and (| and (_). Reminded me of Perl. I just find that too much meaning attached to punctuation makes for completely unreadable code.

Answer 6

Well, I wanted to write a simple application to connect to a MySQL database and do mathematical functions on the data. Running functions on data seems to be a natural fit to a functional language.

That didn't work well (you can find remnants of the project as questions on StackOverflow). My take-away from that project was that the MS database libraries are ridiculously duplicated and hard to use. Further, the imperative paradigm is hard to directly map to F#.

Also, the syntax is 'relatively' easy to read, but very hard to understand well enough to write in a non-trvial fashion. I found at the time (2008) a terrible gap between the "hello world" tutorials and the advanced technique discussion. Today, a problem is that the language has evolved so that the early material on it breaks when compiled today.

I have a generalized gripe about whitespace delimiting in general, and F# unfortunately falls in that bucket.

So I didn't have a good experience with it. But, I think if you have a full-time project with it, in a domain that maps well, F# is going to be a right solution (Along with Haskell, OCaml, and Lisp).

Answer 7

I didnt like how classes require me to name the this pointer instead of allowing me to access member variables implicitly. That was the #1 reason for me not to continue learning it. I felt if i cant access member vars easily that many other things will not be easy as well.

I also wasnt impress with the go programming language. However i do like boo even tho i never programmed with it.