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?
closed as too broad by gnat, Bart van Ingen Schenau, user40980, Kilian Foth, Robert Harvey Nov 21 '13 at 20:40
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
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
I'm having trouble thinking up of scenarios where I would choose to code in F# rather than in C#. Any ideas?
- 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.
- 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.
- Model as asynchronous message passing between user interface code and application logic code.
- Higher-order functions let you define user interfaces declaratively.
- 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.
inlinefor 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.
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.