What functional language techniques can be used in imperative languages?

Question

Which techniques or paradigms normally associated with functional languages can productively be used in imperative languages as well?

e.g.:

• Recursion can be problematic in languages without tail-call optimization, limiting its use to a narrow set of cases, so that's of limited usefulness
• Map and filter have found their way into non-functional languages, even though they have a functional sort of feel to them

I happen to really like not having to worry about state in functional languages. If I were particularly stubborn I might write C programs without modifying variables, only encapsulating my state in variables passed to functions and in values returned from functions.

Even though functions aren't first class values, I can wrap one in an object in Java say, and pass that into another method. Like Functional programming, just less fun.

So, for veterans of functional programming, when you program in imperative languages, what ideas from FP have you applied successfully?

Answer 1

Pretty nearly all of them?

If you understand functional languages, you can write imperative programs that are "informed" by a functional style. That will lead you away from side effects, and toward programs in which reading the program text at any particular point is sufficient to let you really know what the meaning of the program is at that point.

Back at the Dawn of Time we used to worry about "coupling" and "cohesion". Learning an FP will lead you to write systems with optimal (minimal) coupling, and high cohesion.

Answer 2

Here are things that get in the way of doing FP in a non-FP language:

• If the language doesn't support lambda/closures, and doesn't have any syntactic sugar to easily mostly hack it, you are dead in the water. You don't call map/filter without closures.
• If the language is statically-typed and doesn't support generics, you are dead in the water. All the good FP stuff uses genericity.
• If the language doesn't support tail-recursion, you are hindered. You can write implementations of e.g. 'map' iteratively; also often your data may not be too large and recursion will be ok.
• If the language does not support algebraic data types and pattern-matching, you will be mildly hindered. It's just annoying not to have them once you've tasted them.
• If the language cannot express type classes, well, oh well... you'll get by, but darn if that's not just the awesomest feature ever, but Haskell is the only remotely popular language with good support.