Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as too broad by gnat, Bart van Ingen Schenau, MichaelT, Kilian Foth, Robert Harvey Nov 21 '13 at 20:40

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
F# is not fully representative of functional programming. Try Clojure instead. –  Job Feb 21 '11 at 22:14
1  
I don't know F#, but I use Haskell whenever I want my mind blown. Worked every time so far ;) –  delnan Feb 21 '11 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 '11 at 11:55
    
A dynamic functional language? You can have as many as you want. :P –  Erik Reppen Mar 5 '13 at 5:45

7 Answers 7

up vote 12 down vote accepted

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.

share|improve this answer
    
Great links. Thanks! –  System Down Feb 22 '11 at 5:00

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.
share|improve this answer
    
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 '12 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.

share|improve this answer
    
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. –  ChaosPandion Feb 21 '11 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 '11 at 1:16
    
@Chaos: Not that I know of. usually I compose map to get the same effect. –  Paul Nathan Feb 22 '11 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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
1  
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. –  Jon Harrop Feb 25 '12 at 20:32

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