11

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?

4
  • 2
    F# is not fully representative of functional programming. Try Clojure instead.
    – Job
    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
    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
    Nov 25, 2011 at 11:55
  • A dynamic functional language? You can have as many as you want. :P Mar 5, 2013 at 5:45

7 Answers 7

15

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.

0
7

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.
1
  • 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
    Feb 28, 2012 at 11:58
5

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.

3
  • 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. 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
    Feb 22, 2011 at 1:16
  • @Chaos: Not that I know of. usually I compose map to get the same effect. Feb 22, 2011 at 2:25
4

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.

2

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

2

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.

1

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

1
  • 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
    Feb 25, 2012 at 20:32

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