I am convinced that functional programming is an excellent choice when it comes to applications that require a lot of computation (data mining, AI, nlp etc).
But is it wise to use functional programming for a typical enterprise application where there are a lot of business rules but not much in terms of computation?
Please disregard the fact that there are very few people using functional programming and that it's kind of tough.
Thanks
What are business rules if not functions? Application of rules can be expressed as applying a function to a set of data. It can also be combined with polymorphism. e.g. through generic functions (multiple dispatch can be handy, too) and inheritance.
Code is data, data is code, and both should be like water.
Functional programming languages like Clojure and Scala are good for pretty much anything. As for Haskell, an experienced Haskell programming would probably be able to substitute Haskell with any language for any problem - Efficient or not. I don't know if there is a functional programming language that could be considered /best/ out of all languages for this specific problem, but rest assured it will work and very well at that.
Also, Clojure and Scala are implemented on the JVM. So technically they /are/ on an enterprise platform.
I assume when you talk about a lot of business rules you are thinking about application development. Application development in the sense that you want to model a real-world workflow. Unlike vanilla programming, application development involves higher levels of responsibility (particularly for requirement capturing and testing). If so, I strongly suggest to see if you could apply domain-driven development. A natural choice for domain-driven development is an object-oriented approach. This and the fact that a lot of programmers are decent at object-orientated programming is one reason for its popularity in application development. However, this does not mean that real-world, big-scale projects are always written this way (read http://www.paulgraham.com/avg.html).
More than a year ago I delved a bit into Haskell and also tried a few things that I would regard as a typical business problem (To put it bluntly, given a number of values, what is the correct response?). Hence, I would say, yes, you should be able to model a number of business problems with functional programming.
Personally I couldn't find the same obviousness in Haskell to which I can push a OO + functional approach like with C# , but this could well be because I haven't done much with Haskell and a lot more with C#.
Then there is the thing how to communicate with a customer. My experience is that many of them think in strictly chronological terms, which kind of favours imperative programming. Even when going into models of state changes etc. you can lose the odd customer. Thinking along function compositions and monads that may represent the chronological operations of the business could probably be beyond many,many customers.
Either way, you can find my business-y example here.
From what I've seen, Scala looks like it handles normal Java just fine. Hence, anything that Java can handle for business, Scala could too.
On the .NET side, F# is another great example of a functional language that works fine for "business" applications. To put it simply, F# can do everything C# can do, and more, easier.
But for both of these languages, the "programming in the large" side tends to borrow from OOP. Not that there's anything wrong with mixing things, but perhaps thats not what you asked. If you want to stick to a more functional approach, and say, not use objects, you could run into a bit more hassle because the tooling support won't be on the same level. With languages that easily integrate with .NET/Java, that's not as big an issue.
As far as "is it wise?": That depends on the project, company, and other environmental factors. It seems that a common "enterprise pattern" is that code has to be extremely dumbed down so that anyone can work on it. In that case, you might get people involved who'd think that using a lambda makes it too difficult for others to understand.
You might want to check out the iTasks system which is a library for the functional language Clean and is designed exactly to express workflow and business processes.
But is it wise to use functional programming for a typical enterprise application where there are a lot of business rules but not much in terms of computation?
Business rules are just computation and you can often express them more succinctly and clearly using functional programming.
A growing number of enterprise apps are written in functional languages. Citrix XenDesktop and XenServer are built upon a tool stack written primarily in OCaml. The MyLife people search engine is written in OCaml. We are a small company but all of our LOB software (e.g. credit-card transactions, accounts, web analytics) are written in F#. Microsoft's ads on Bing use F# code. Perhaps the most obvious example is anyone using recent versions of C# and .NET because they are almost certainly using functional concepts (e.g. delegates).
If you mean more exotic functional languages such as Clojure, Scala and Haskell then I believe some people are using them but I do not have any details myself.