Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

What is the benefit of using functional program for large scale software projects? I have heard it is pretty performance equivalent to regular OOP. I also have heard that it is more "mathematically elegant." Either way what are the benefits of doing large scale applications functionally?

In particular why would the switch from C# to scala make sense in order to take advantage of scala's functional capabilities?

share|improve this question

closed as primarily opinion-based by GlenH7, gbjbaanb, mattnz, Rob Y, gnat Aug 1 '14 at 6:01

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This question is a bit too broad to be reasonably answerable here. Can you make it more specific? Read the Wikipedia article, John Hughes' "Why Functional Programming Matters" paper, and work through this Google Search –  Robert Harvey Jul 31 '14 at 16:15
@RobertHarvey is that more specific? –  inquisitiveIdiot Jul 31 '14 at 16:17
Yes, that's an answerable question. –  Robert Harvey Jul 31 '14 at 16:18
You'd more likely switch from C# to F#, or Java to Scala, in order to stay within the same framework –  AlexFoxGill Jul 31 '14 at 16:19
@Den: C# might have some functional capabilities, but the reason why it's deeply inadequate for use with a functional mindset is obvious to anyone who used an actual functional language before. –  scrwtp Jul 31 '14 at 19:37

4 Answers 4

It would make more sense to switch from Java to Scala. Both languages run on the same platform (the JVM), but Scala (in my opinion) is a much nicer language with many more capabilities, including functional programming.

Switching from C# to Scala would involve completely changing platforms, and C# already has some functional programming capabilities. On the .NET platform, F# is a functional language having object-oriented capabilities.

Why might you want to use functional programming?

Functional programming is declarative programming, rather than imperative programming. For the most part, you tell the computer what you want and it figures out how to do it, rather than you telling the computer how to do it (in minute detail).

In functional programming, you build applications from the bottom up, starting with simple functions and gradually building more elaborate functions. Some programmers like this style of programming better than the top-down approach.

Functional programming benefits from referential transparency (immutability is a big part of that), and therefore programs written in it are more provable and easier to reason about. Multi-threaded programming is much simpler in the functional paradigm.

Functional programming is not an either/or proposition. You can mix functional programming with object-oriented programming or any other programming paradigm. You can write libraries in either C# or F#, and interoperate between them.

Further Reading
Haskell Wiki on Functional Programming
Beating the Averages by Paul Graham

share|improve this answer
+1. Among other things, I find it good that you distinguished between referential transparency and immutability. –  Giorgio Jul 31 '14 at 16:41
"For the most part, you tell the computer what you want and it figures out how to do it, rather than you telling the computer how to do it (in minute detail)" I consider this major misinformation. You still have to tell computer how to do things. You just tell it little differently. –  Euphoric Jul 31 '14 at 18:21
@Euphoric: I welcome suggestions for better wording. Basically, the point of that paragraph is to distinguish declarative from imperative. See the first couple of paragraphs here: –  Robert Harvey Jul 31 '14 at 18:23

If you want to program in a functional way, switching from C# to something else makes lots of sense. C# has some functional capabilities, so if you're obstinate and not afraid of typing out loads of boilerplate, you could roughly do anything 'functional' in it, but it gets very painful very quickly.

I've been using F# for more than a year now, and the rare trip back to C# always feels unpleasant, in a way going back from a pair of 24'' displays to a single 19'', or from Chrome to IE8 is unpleasant. You can still get stuff done, but it's just not something you would think of doing voluntarily.

Some of the good things F# has to offer (and where C# falls short) - I'm not particularly familiar with Scala, but I believe it offers much if not all of this:

  • Immutability by default,
  • Partial function application by default,
  • Algebraic data types with pattern matching/structural comparisons for free,
  • Type inference that actually allows you to drop type annotations most of the time,
  • No nulls as long as you stay on the F# side.

What this means in practice:

  • No obligatory boilerplate around each and every field you have, the default works 99% of the time,
  • Functions are easy to compose and pass around (especially since you also have operators for composition and pipelining),
  • No more deeply nested if's,
  • No more having to mindlessly implement equality and comparisons for every single type,
  • Your code doesn't turn into a soup of types whenever there's a non-trivial generic type around.
  • No null checks, and far less exception throwing than what you'd typically see in C# code.

Note that the stuff I mentioned are some of the most down-to-earth coding exercises. I didn't even mention concurrency or the dreaded "M" word.

As usual in such cases, it's not like there's a single feature that makes the difference. It's more the sum of all the little things and how they make up the overall experience of using the language.

Edit: I got back to this answer after half an hour to add the bit about how the nulls are gone. I simply forgot about them - I believe this is the best testament to how much nicer the F# experience is.

share|improve this answer

In my personal experience, the major benefit of functional programming is that it changes the way you think about code. Instead of writing a for-loop to transform some data as I would have done in the past:

var list = new List<Item>();
foreach (var item in myItems)
    if (item.Foo == 1)

My immediate instinct for data transformations is now to use LINQ:

var list = myItems
    .Where(item => item.Foo == 1)
    .Select(item => item.Bar);

I think this is far easier to read and understand - the declarative paradigm describes how the data is changing, so the reader doesn't need to execute the program mentally in their head.

However, for all the functional features that C# has, there are some notable exceptions. Probably the most important is immutability by default. This is so important in functional programming, but in C# there is an awful lot of boilerplate to achieve it (a private readonly field and a public get-only accessor). This means that most programmers don't bother with it. Compare C#:

public class Person
    private readonly string _firstName;
    private readonly string _lastName;

    public Person(string firstName, string lastName)
        _firstName = firstName;
        _lastName = lastName;

    public string FirstName { get { return _firstName; } }
    public string LastName { get { return _lastName; } }

with F#:

type Person = { firstName : string, lastName : string }

The benefits of immutability are manifold, but the two main ones are:

  • Lack of side-effects: If you call a function twice with the same arguments, you can be sure to get the same result because none of its references can have changed their properties. This drastically reduces the number of bugs in code
  • Concurrency: Immutability means guaranteed read-only access for all threads. It is predicted that computing power is destined to expand in width rather than speed, and you can take advantage of this distributed power by using immutability with a functional pipeline

Languages like F# and Scala promote these benefits as a primary part of the language, whilst simultaneously (at least in the case of F#) offering all of the benefits of C# as well.

One final feature that I can think of that really boosts productivity is pattern-matching. It's not one that is fundamental to FP but it seems to have only caught on on functional languages plus one or two multiparadigm (e.g. Python). Again this is something that greatly reduces the amount of boilerplate code you need to read and write, increasing the signal:noise ratio of your program.

share|improve this answer
It's not that much boilerplate, and if it's really that bothersome, one could always write a T4 template to generate it. The real problem with C# is that (prior to .NET 4.5) there were no genuinely immutable collections. –  Robert Harvey Jul 31 '14 at 16:53
@RobertHarvey see edit. 14 lines vs 1. Still think that's not too much boilerplate? (Not that I disagree with your second point about immutable collections) –  AlexFoxGill Jul 31 '14 at 16:59
Solved: public string FirstName { get; private set; } –  Den Jul 31 '14 at 19:08
Other syntax sugar is coming:… –  Den Jul 31 '14 at 19:09
@RobertHarvey I don't know, people always go for the path of least resistance. I think having to type just 2 times as much will have an effect on how inclined you'll be to declare a new type. This analysis suggests that C# code tends to have a lower number of types compared to F# code, with a lot of variance. For F# code the correlation was pretty linear. At any rate I think the real boilerplate pain starts when you want an algebraic data type. –  Doval Aug 1 '14 at 12:43

I like the other answers, which I would summarize as functional programming being more expressive. In other words, functional programs tend to express the solution closer to the way I conceive of a solution, with less code that isn't directly related to the problem domain.

The other thing I like about functional programming for large scale programs is that bad designs tend to fail fast. With great expressivity comes great responsibility, and functional programming does give you a lot of rope to hang yourself. However, in my experience, it's a lot easier to recognize bad designs earlier in functional programs, and correct them before you get too far down the road. OOP tends to be somewhat more forgiving of poor design in the early stages, but it gets bad later on when it's more difficult to change your entire design.

For example, if you have 20 vaguely-related mutable fields in an OOP class, it might take a while for that to be visibly problematic. If you have the same 20 immutable fields you are passing around all over the place as function arguments, you're going to figure out really quickly how to improve the cohesion, which makes it easier to maintain long term and on a larger scale, at the expense of a little more work up front.

The other nice thing about functional programming is it's easy to add unit tests at any point, and they're generally easier to write, due to minimal side effects and the aforementioned preference for highly-cohesive functions. OOP programs pretty much have to be designed from the start (or redesigned) with unit testability in mind.

share|improve this answer

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