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?

Zachary K
  • 10,433
  • 2
  • 37
  • 55
System Down
  • 4,743
  • 3
  • 24
  • 35
  • 2
    `F#` is not fully representative of functional programming. Try `Clojure` instead. – Job Feb 21 '11 at 22:14
  • 2
    I don't know F#, but I use Haskell whenever I want my mind blown. Worked every time so far ;) –  Feb 21 '11 at 22:17
  • 1
    http://www.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 05 '13 at 05:45

7 Answers7

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.

Scant Roger
  • 9,038
  • 2
  • 29
  • 47
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.
J D
  • 2,332
  • 24
  • 17
  • 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
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.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • 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 01:16
  • @Chaos: Not that I know of. usually I compose `map` to get the same effect. – Paul Nathan Feb 22 '11 at 02: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.

SK-logic
  • 8,497
  • 4
  • 25
  • 37
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).

vartec
  • 20,760
  • 1
  • 52
  • 98
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.

Zachary K
  • 10,433
  • 2
  • 37
  • 55
1

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

biziclop
  • 3,351
  • 21
  • 22
  • 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 '12 at 20:32