I've recently been learning F# for fun (I'm a VB.NET/C# dev), and I really like some of what it has to offer. Theoretically that is. But I'm having trouble thinking up of scenarios where I would choose to code in F# rather than in C#. Any ideas?

  • 2
    F# is not fully representative of functional programming. Try Clojure instead.
    – Job
    Commented Feb 21, 2011 at 22:14
  • 2
    I don't know F#, but I use Haskell whenever I want my mind blown. Worked every time so far ;)
    – user7043
    Commented Feb 21, 2011 at 22:17
  • 1
    infoq.com/presentations/Are-We-There-Yet-Rich-Hickey is a great video on this topic (OO vs. Functional)
    – mikera
    Commented Nov 25, 2011 at 11:55
  • A dynamic functional language? You can have as many as you want. :P Commented Mar 5, 2013 at 5:45

7 Answers 7


A few arguments for pure functional programming:

  • It's easier to divide tasks for today's multi-core systems
  • It's easier to prove your program is correct
  • Functional composition can be amazing, terse, and powerful

For a full treatment, see Why Functional Programming Matters and Why Why Functional Programming Matters Matters.


I'm having trouble thinking up of scenarios where I would choose to code in F# rather than in C#. Any ideas?

From here:

Asynchronous servers

  • Asynchronous workflows for the asynchronous IO.
  • Mailbox processor for the thread-safe message passing.
  • Union types for server state and message catalogue.
  • Pattern matching and tail recursion for the state machines.

Metaprogramming (e.g. parsing)

  • Parser generators like fslex and fsyacc.
  • Parser combinators like FParsec.
  • Active patterns for elegant hand-rolled parsers.
  • Algebraic datatypes to represent parse trees.
  • Pattern matching to manipulate trees, e.g. apply optimization stages.
  • Reflection for run-time generation of fast code.

Technical computing

  • Higher-order functions for elegant and fast algorithmic code.
  • Algebraic datatypes and pattern matching for symbolic manipulation.
  • Interoperability for wealth of .NET libraries.
  • Interactivity using F# interactive.
  • Computation expressions for massaging data.
  • Units of measure for improved correctness.

GUI applications

  • Model as asynchronous message passing between user interface code and application logic code.
  • Higher-order functions let you define user interfaces declaratively.

Logic programming

  • Persistent collections for easy backtracking.
  • Tail calls for reliability.
  • Automatic generalization for easy generic programming.


  • Run unit tests interactively.
  • BDD means writing an interpreter.
  • Good scripting language for writing test harnesses and visualizing results.


  • inline for cost-free higher-order abstraction.
  • Tail calls for fast state machines.
  • Purely functional data structures for low latency.
  • Metaprogramming for generation of optimized code.
  • I will admit that I don't know F# or C# but I would suggest spending a few days in F# and seeing what you think. To my mind using the REPL is a major win in any language that supports it
    – Zachary K
    Commented Feb 28, 2012 at 11:58

Here's what use functional style programming for -- on a more-or-less daily basis.

We do lots of statistical and actuarial things with fairly large datasets. The data fetched from the database is -- essentially static, immutable objects. No reason to create a class with methods.

Each stage of the calculation adds some additional details, but doesn't essentially mutate the object. At the "end" of the pipeline we're really doing a fancy reduce to compute sums and counts and other things.

Imagine this.

for data in summarize( enrich( calculate( some_query( criteria() ) ) ) ):
    print data

Each "phase" of the calculation is a functional programming loop that does simple read-calculate-yield and creates a composite object of other things plus results.

(We use Python, hence the functional programming using generator functions.)

It's easier to use stateless, immutable objects.

  • Does Python have an equivalent to this F#? criteria() |> some_query |> calculate |> enrich |> summarize I find the forward pipe operator can lead to clearer code but I digress. Commented Feb 21, 2011 at 23:48
  • @ChaosPandion: First, that syntax confuses me. But some people seem to like it. There a innumerable Python packages. I'm sure that you could search for that on SO and find an answer.
    – S.Lott
    Commented Feb 22, 2011 at 1:16
  • @Chaos: Not that I know of. usually I compose map to get the same effect. Commented Feb 22, 2011 at 2:25

Technically, it is not a unique property of a functional programming, and F# is not a pure functional language. F#, as one of ML descendants, provides an excellent pattern matching and algebraic data types. So, for any task which requires complex data structures F# is much more expressive and easy to use than C#.

Imagine implementing a compiler in C# and F# - representing an abstract syntax tree and transforms over it is much simpler if your language provides ADTs and a pattern matching.


Ideal for map-reduce kind of massive multi-system and massive multi-core parallelism. Pretty cool, considering that nowadays entry level servers come with 48 cores (96 counting HT).


If you want fully functional try Haskell, Erlang also has some very cool stuff about it.

Simon Payton-Jones said about Haskell, he wants to have a program that obviously has no bugs, rather than have no obvious bugs.

(I probably got the quote a bit off, but you get the idea)

By constraining side effects you make it much easier to prove your code is correct.


One definite advantage is that it's much more easily parallelised.

  • 2
    You're talking about purity and one obvious disadvantage is that purity tends to make programs a lot slower. So parallel+pure is not necessarily a good thing.
    – J D
    Commented Feb 25, 2012 at 20:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.