How do I explain what's good about F#?

Question

Many people ask me to explain to them why is F# (or other functional languages) better (or different) than other languages they know (like Java, C#, C++).

Until today, I either tried showing few examples or using longs scary words or lending Tomas Petricek's book, but I find those ways either time consuming or unclear.

Is there a simple(r) way to explain functional programming to imperative programmers?

Answer 1

I would use the example of Red-Black trees, show how a two-line type definition defines the shape of all trees without having to write any constructors or access methods, and go on to show how useful pattern-matching can be when writing sophisticated symbolic manipulation functions such as the re-balancing one.

I would try to emphasize that it's a good language to write these kinds of computations in, making them concise and clear, but that the advantages may be less obvious for other categories of programs. Getting to the point where functional programmers can be considered as rational people who deliberately chose the best tool for the job they had to do would be an improvement with respect to the current situation, where they are mostly considered as lunatics by the rest of the programming community.

If that's not already clear, I wouldn't push too hard for the adoption of F# (or any other functional language). We've tried that, it doesn't work, it's time to move on. Let interested programmers come, but do not preach.

EDIT: Example taken from this nice page with a lot more detail:

type color = R | B    
type 'a tree = E | T of color * 'a * 'a tree * 'a tree

let balance = function                     
    | B, T(R, T(R, a, x, b), y, c), z, d        
    | B, T(R, a, x, T(R, b, y, c)), z, d       
    | B, a, x, T(R, T(R, b, y, c), z, d)         
    | B, a, x, T(R, b, y, T(R, c, z, d))         
        -> T(R, T(B, a, x, b), y, T(B, c, z, d))
    | c, l, x, r 
        -> T(c, l, x, r)

In function balance, the lines that start with | are patterns. Inside a pattern, uppercase letters (or generally names that start with an uppercase letter) are constructors. For instance B is one of the constructors of type color. Lowercase letter are variables. Variables always match and can be used on the right-hand-side of -> to represent the value that was matched on the left-hand-side.

When the shape of the function's four arguments is of one of the first four patterns, T(R, T(B, a, x, b), y, T(B, c, z, d)) is returned. Otherwise, the fifth pattern is tried, and since it contains only variables, it always matches. In this case T(c, l, x, r) is returned.

Answer 2

I've given dozens of introductory talks on F# and seen dozens more. The mistake people usually make is starting with syntax or functional programming concepts. If you want to sell F# to traditional imperative/object-oriented programmers you need to explain the context in which you would use F#, because it is not a 100% replacement for any current programming language.

There are domains where imperative programming sucks

Think about writing a compiler or a physical simulation engine in C#. Certainly you could represent mathematical equations and interactions using classes and interfaces, but note that those aren't in the domain. In F# you deal with functions and data transformation, so there is less of a mismatch between how you conceptualize your ideas and the code that you write.

See other answers about how concisely you can write advanced algorithms or data structures in F#. This is because F# excels in those specific domains. F# would be a poor choice for writing forms-over-data applications, but it is a great language for writing a search engine.

There are ways in which imperative programming sucks

Have you ever heard someone say that debugging multi-threaded applications is easy? You haven't because it isn't. Imperative programs focus on telling the computer explicitly what to do. This approach is fine in most situations, but fails miserably when you get into parallel and asynchronous programming because as soon as you have two threads modifying the same data you open up a whole slew of new problems.

F# doesn't 'solve' parallel programming, but it does make it easier to integrate into your applications. Functional programming focuses on immutable data, so there is less reliance on global, mutable state. Quote "You cannot screw up what you don't change."

There are many other more subtle ways in which F# is a great language as well. There is the existing .NET stack, Visual Studio integration, the REPL, and so on. But if you want to focus on convincing standard imperative programmers, you need to focus on how F#/functional programming reframes how you think about programming.

Answer 3

Here's something that I run into a lot in C# where I know it's easier in F#:

class MyClass
{
    private readonly string param1;
    private readonly int param2;
    private readonly MyService param3;

    public MyClass(string param1, int param2, MyService param3)
    {
        this.param1 = param1;
        this.param2 = param2;
        this.param3 = param3;
    }

    public string Result
    {
        get
        {
            return param3.Calculate(param1, param2);
        }
    }
}

In F#:

type MyClass(param1:string, param2:int, param3:MyService) =
    member x.Result with get() = param3.Calculate(param1, param2)

Excuse me if my F# is incorrect, but I believe this is valid syntax, and would do the same thing.

Answer 4

C# and F# follow two different programming paradigms.

C# is primarily an object oriented program. Lately, functional programming concepts have been added to C#, namely lambda expressions. But if your programming relies heavily on functional programming, F# definitely is more streamlined.

F# is primarily a functional programming language. You can do object oriented programming, but if your programming relies heavily on object oriented programming, then C# is more streamlined (IMHO)

The object oriented programming paradigm is highly suitable for implementing your software based on a domain model, and is therefore a very effective programming paradigm for writing line of business applications.

The functional programming paradigm is highly suitable for manipulating data, math, multi-threaded programming.

So if you want to explain what is good about F#, then you should point out that there are areas of programming where F# is more flexible.

One thing that I have noticed is the amount of re-usability that you can place into F# programs. In object oriented programs, the smallest reusable unit is a class. In functional programming programs, the smallest reusable unit is a function.

Answer 5

SERadio had an episode on F# which I was actually listening too on my way in to work today. Very interesting stuff.

Answer 6

1. Show them, how Excel is the most popular functional programming language
2. Ask them whether they would prefer to replace their Excel spreadsheets with C++/C# program
3. Assuming they say no, they will understand the benefits of powerful functional programming languages
4. Show them that F# is a powerful functional programming language

Answer 7

1. F# Has Better Performance in Math
2. F# is really good for complex algorithmic programming, financial and scientific applications
3. F# logically is really good for the parallel execution (it is easier to make F# code execute on parallel cores)
4. You could use F# projects in the same solution with C# (and call from one to another)

there are a few cases where F# might not be the best choice:

1. Interop: There are plenty of libraries that just aren't going to be too comfortable from F#.
2. Design tools. F# doesn't have any. Does not mean it couldn't have any, but just right now you can't whip up a WinForms app with F# codebehind.

Answer 8

Show them this excellent video with Luca Bolognese: http://channel9.msdn.com/blogs/pdc2008/tl11

But I must add I don't believe F# has a bright future: it is too complicated for most corporate application programmers, and too high-level for most system programmers.

Answer 9

Do you really have to convince people a language is better than Java or C++? C# on the other hand has a lot of good things going for it so you might have a tougher sell there since the latest version of C# has a lot of functional features. One of the cool things about F# is that it has a REPL so once you get the fundamentals down growing an application by jumping back and forth between an editor and the REPL is a really enjoyable workflow. Plus, type inference is a really hard thing to give up once you get used to it but of course Java programmers don't know that because they have to type String s = "hahahah"; and they have no idea how painful that really is.