Arguments for Functional Programming [closed]

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.

Testing

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

Performance

• 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.

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.

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.