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