何时使用函数式编程语言？

Functional languages are, in my opinion, good for mainly two things: Game AIs and mathematical computations. It's good in game AIs because of its nice list manipulations (at least in Lisp and Scheme), and for mathematical computations because of its syntax. Scheme, Lisp, and Haskell have a syntax that makes mathematical computations easy to read. The last thing I have to add is that functional languages are really fun languages. My Scheme course was one of the courses I had the most fun with.

Although this is quite the subjective question, I'd just like to add that functional languages are used a lot to parse domain specific languages; the functional nature lends well to parsing grammars.

Functional languages are good in a lot of situations. It depends on the libraries of a particular functional language.

How would you answer the question "When to use an object oriented programming language?"?

A friend of mine quoted one of his college professors as saying something like the following:

Draw a grid with data types across the top and operations on those data types down the left side. If you slice the grid vertically, you're doing OO; if you slice the grid horizontally, you're doing FP.

My answer is that FP is a completely viable approach to programming with as wide a range of application as OO. As with any programming-language-choice discussion, I think the more important questions are:

1. Do you have the time to invest in learning a new notation and a new way of thinking?
2. Which of the languages you're considering have sufficiently rich libraries that you won't get stuck reinventing some wheel?

As to the first question, if you are doing this primarily for the learning value, I'd suggest looking at Haskell, because of the wide range of support materials (books, articles, active community, etc.)

As to the second question, Haskell has a nice range of libraries (although some are more mature than others), but Scala (a hybrid OO-functional language running on the JVM) has the advantages that you can more gradually transition into the functional style, and you have the full range of Java-accessible libraries available to you.

Practically everything you can do in PP can be done in FP, and same thing in reverse. It's just another way to code something—another perspective on the problem and a different way to solve it.

However, because not many people use FP, the problem is more about the lack of good libraries, portability/maintainability (since the maintainer has a better chance to understand something written in C++ than Scheme), and the lack of documentation and community. I know there ARE some docs, however, compare that to C++, C# or Java and you will understand what I mean.

However, if you really want to do FP, you can use this style even in C++ and C#. Of course, it won't be a 100% FP if you use the standard library. Unfortunately, I don't think C# is optimized to be used with functional programming and it will probably create lot of performance issues.

This is more a subjective post, what I think about FP. It is not a rigorous declaration.

From what I've seen, it's more a matter of taste than functionality (no pun intended). There really isn't anything about either style of language that makes it inherently better or worse at specific tasks.

In general, use the language in which it's easiest to express the solution to a problem. For functional programming, this is when the solution to a problem is easily expressed in terms of functions, hence the name. Generally it's good for mathematical operations, AI, pattern matching; in general anything that can be broken down into a set of rules that must be applied to get an answer. You can only really determine the "best" language to use after you've analyzed your problem sufficiently. This is where pseudo-code comes in handy. If you find yourself writing pseudo-code that looks like FP, use FP.

Of course, all complete programming languages are functionally equivalent, so it doesn't matter really which one you choose in terms of what problems you can solve. The main effects will be in terms of coding efficiency and accuracy, and ease of maintenance.

Note also that it's possible to mimic FP within OO languages through cleverly designed APIs. For instance, I've seen numerous Java libraries (JMock is one example) that use method chaining to simulate an FP DSL. Then you'll see constructs such as:

logger.expects(once()).method("error") .with( and(stringContains(action),stringContains(cause)) );

This essentially builds a function that is evaluated to determine whether some calling sequence on a mock object is correct. (example stolen from http://www.jmock.org/yoga.html)

Another FP-like syntax in otherwise OO languages is the use of closures, such as in Ruby.

I've done some research into this myself and thought I might add CONCURRENCY to the list of reasons to use a functional language. See at some point in the near future processor speed will not be able to increase using the same cpu technology. The physics of the architecture won't allow it.

So that is where concurrent processing comes in.

Unfortunately most OOP languages cannot take advantage of multiple processors at once because of the interdependencies between data.

In pure functional programming languages the computer can run two (or many more) functions at once because those functions are not altering outside state information.

Here is an excellent article on functional programming you may enjoy.

I think previous posts are correct here is a short list, functional programming is a perfection solution for the followings:

• stateless processing
• mathematical equations including ML (Machine Learning)
• immutable processes
• when you want scalable concurrency