Possible Duplicate:
Which problems domains are more suited to functional programming solutions
I've been reading about functional programming. I've been using mostly C#.net recently, and I would like to know of a good real-world example of where a functional language such as Lisp or F# would be a clearly superior tool for getting a job done.
I find functional languages better because they tend to demand very little ceremony for the functionality they provide. For example....let's take every number in a list of integers add one to the number, and then sum them.
In Clojure:
(reduce + (map inc mylist))
In C# (functional style):
result = mylist.Select(i => i + 1).Sum();
In C# (imperative style):
int sum = 0;
foreach (int i in mylist)
{
sum += (i + 1);
}
Let's look at the imperative style...we have to create a accumulator (sum), a locally scoped variable (i), and we also have to be explicit in how we enumerate our loop. What takes a single line of code, and is extremely readable in a functional language has ballooned into 5 lines of C# and it's not nearly as readable.
So after studying both imperative and functional languages for several years, I've simply come to the conclusion that I would rather use less work to accomplish more. Since switching to Clojure for all my hobby projects I've found that I can suddenly accomplish much more with less code.
So back to your question, I never find myself asking "why would I use a functional language?", but instead, "why wouldn't I use a functional language?". Sometimes it requires thinking about the problem in a different way, but I find that my functional code is more concise, elegant, and readable than the code I'm forced to write in C#.
For context, I code in C# 8+ hours a day at work, and code around 1-2 hours in Clojure every night.
mylist.Sum(i => i + 1); which I dont think anyone can argue is less readable than the given Clojure version :)
int x = 1; is in C. What IS an objective fact though, is that the functional code ONLY describes the algorithm in terms of it's semantic components, there's little or no boilerplate.
Functional programming is commonly used in academics. Some would argue that it is superior in teaching. It also is good for massive concurrent systems.
Most of what you're asking can be answered by several previous questions:
Lisp usages: https://stackoverflow.com/questions/794450/what-is-lisp-used-for-today-and-where-do-you-think-its-going
F# usage: https://stackoverflow.com/questions/36756/f-what-are-you-using-it-for
Haskell usage: https://stackoverflow.com/questions/1604790/what-is-haskell-actually-useful-for
Erlang usage: https://stackoverflow.com/questions/1636455/where-is-erlang-used-and-why
Many of the functional languages were designed for use in high-uptime systems. Erlang, for example, is the language behind the logic of most of our cell phone carrier systems (those built on Ericsson nodes, at least). Those systems are expected to provide very high levels of availability (we're talking Nine Nines, 99.9999999% uptime; that's something like 30 milliseconds per year of allowable downtime) while at the same time remaining modular and highly scalable. You do that with some of the features built into many functional languages, like hot-swappable code (no need to recompile DLLs and restart the system; just put the new package in there and the next call into that package will be with the new code).
Apart from that, many ideas in computing are most easily expressed functionally. Functional programming is inherently recursive and highly parallelizable, so tasks that are best designed in such ways lend themselves well to functional languages. Parallelization in particular is becoming more and more important as the power of a CPU is being increased by adding execution units to the chip instead of increasing clocks. File processing and other ETL tasks are definable functionally and benefit greatly from throwing more threads at the problem.
Functional programming is superior across the board. I have not found a case where a functional programming language, or a more functional style in an imperative language, is a bad solution to a problem.
It’s simply a lot easier to get things done when the language is more expressive. It’s not about terseness—though that is a side effect—but rather about being able to understand and reason about more of your program at once. In a functional language, you don’t always have to write a description of how to compute what you want—you can write a description of what you actually want.
Using a functional programming language encourages you to think about your program in terms of data flow and computation, rather than state and mutation. It’s so much easier to solve problems functionally. And isn’t solving problems exactly what programmers are supposed to do?
