Why would one use a functional language in an otherwise Imperative project?

Question

Why would one use a functional language in an otherwise Imperative project?

Answer 1

Many methods in languages like Java and C++ could be written in a more readable and dense form using FP concepts such as higher-order functions, currying, closures, etc.

See Scala for many interesting examples.

Answer 2

Many tasks are inherently addressed by functional concepts, such as composable calculations. It is feasible that you will encounter these kinds of problems in projects which have otherwise been developed in an object-oriented fashion.

The best tool for a job is independent of that tool's dominant paradigm.

Answer 3

If your project is truly imperative, you probably don't want a purely functional language. But you probably still want a language with functional features; functional style addresses low-level code structure in the same way that object-oriented style addresses high-level structure. Both allow you to package certain common patterns in a language-supported way.

In a primarily imperative project, functional style is useful at the expression and statement level, allowing you to abstract common loops and sequences:

For example, take this common pattern:

newlist = []
for x in oldlist:
    y = dosomething(x)
    newlist.append(y)

That's map:

 newlist = map(dosomething, oldlist)

Or this:

total = 1
for n in numbers:
    total = total * n

Becomes fold (also known as reduce):

total = fold(*, 1, numbers)

Imperative style does not address this low-level duplication all that well--hence the "I wish I had a nickel for every time I typed for(int i = 0; ...)". Even in OO languages without functional features, code inside methods doesn't differ much from similar non-OO languages.

Some IDEs for address this by providing code snippets. This addresses the lack of abstraction power in the wrong way. The way to handle a repeated pattern is not to encourage cut-and-paste with little holes for variable names, but to abstract the pattern into a reusable unit.

Note: I addressed embedding functional code in an imperative project. A top-to-bottom project in functional style will look different. Here are some links taken from similar Stack Overflow questions:

• http://www.25hoursaday.com/weblog/2008/06/16/FunctionalProgrammingInC30HowMapReduceFilterCanRockYourWorld.aspx
• http://www.joelonsoftware.com/items/2006/08/01.html

Answer 4

A common problem faced by application developers is building queries: "I want all customers over the age of 18 who have spent $10K in the past year." The process of defining a query that returns all customers, then filtering it by one criterion, then another, and finally a third, is called composing the query. Composition is a strong suit of a functional approach, meaning the query definition problem and a functional solution are well-matched. To see this in action in a popular object-oriented language, see C# and LINQ

Answer 5

Probably, the most common reason - is to localise and restrict the imperative part (i.e., potentially dangerous and harder to debug, analyse and maintain).