Are functional programming languages good for practical tasks?

Question

It seems to me from my experimenting with Haskell, Erlang and Scheme that functional programming languages are a fantastic way to answer scientific questions. For example, taking a small set of data and performing some extensive analysis on it to return a significant answer. It's great for working through some tough Project Euler questions or trying out the Google Code Jam in an original way.

At the same time it seems that by their very nature, they are more suited to finding analytical solutions than actually performing practical tasks. I noticed this most strongly in Haskell, where everything is evaluated lazily and your whole program boils down to one giant analytical solution for some given data that you either hard-code into the program or tack on messily through Haskell's limited IO capabilities.

Basically, the tasks I would call 'practical' such as

Aceept a request, find and process requested data,
 and return it formatted as needed

seem to translate much more directly into procedural languages. The most luck I have had finding a functional language that works like this is Factor, which I would liken to a reverse-polish-notation version of Python.

So I am just curious whether I have missed something in these languages or I am just way off the ball in how I ask this question. Does anyone have examples of functional languages that are great at performing practical tasks or practical tasks that are best performed by functional languages?

Answer 1

Regarding languages, I think F# is an example of a languages that's primarily 'functional' but also 'practical'. Scala and Clojure are probably others in this category.

(Going one level deeper, I think the 'formula for success' here is a language that leans strongly towards 'functional', but has access to vast practical libraries (e.g. .Net/JVM/some C FFI) and has good tooling (e.g. IDE support).)

I at least somewhat agree with the implicit premise of the question, namely that there is a tension between 'succinct/beautiful analytical power' and 'pragmatics'.

Answer 2

Erlang is well known for its robustness and features for writing highly-concurrent servers.

It also has a DBMS out-of-box.

Answer 3

Functional Programming in the Real World

Answer 4

IMO, Scheme is too minimalistic to be practical- it is used in several courses for teaching (see Structure and Interpretation of Computer Programs). However, modern Lisp languages like Common Lisp, and especially Clojure are gaining importance. Erlang is used by several large industries for high concurrency applications, and I personally haven't seen it being used by end-user programmers. Haskell on the other hand is quite a real-world language, and has been used to write a lot of wonderful software including:

1. XMonad is an X Window System window manager written purely in Haskell.
2. Leksah, an IDE for Haskell is written in Haskell itself.
3. Pugs, one of the leading implementations of Perl 6 is written in Haskell.
4. Lastly, the Glasgow Haskell Compiler is written in Haskell.

Answer 5

Does anyone have examples of functional languages that are great at performing practical tasks or practical tasks that are best performed by functional languages?

Our business runs on F# code, for everything from on-line credit card transactions to web analytics. These LOB apps are composed of tiny F# scripts that do everything required quickly and simply using .NET's seamless interop and automation of applications like Outlook and Excel.

Our business makes most of its money selling software written in F# that solves practical problems to customers from many sectors from embedded software for medical equipment to maritime internet service providers.

Answer 6

Basically, the tasks I would call 'practical' such as

Aceept a request, find and process requested data, and return it formatted as needed

You experimented with Erlang and couldn't find a practical task for it under this description of practical?

Accept a request.

You mean like receive. Or just being called straight up as a function.

Find and process requested data.

I'm not entirely sure what you mean here, but for finding data there's file I/O, networking I/O, (distributed) inter-process communication, etc. etc. etc. For finding subsets of that data there's regular expressions, pattern matching, etc.

For processing there's a whole bunch of stuff for strings, lists, mathematics, sets, graphs, etc. Is this not enough for processing? What else are you looking for?

Return it formatted as needed.

I can return the resulting data as atoms, lists, binary blobs, formatted strings, numbers, etc. What was missing from Erlang in this regard? I'm really honestly confused here.

Answer 7

Funny, you and I have very different notions of "practical tasks". You say it's:

Aceept a request, find and process requested data, and return it formatted as needed

This is pretty much what a functional language is made for: functions that take data and return new data without preserving any state in-between calls (ie no side effects). This is what you have here and it's also called piping.

Now this isn't what I'd call a practical task. In modern programs you have to deal with GUI's, multithreaded functions and network I/O. All these have state that is required to hold data in-between function calls. Data isn't piped into a function and the result piped out, the functions affect the "global" state too.

And it's this definition of "practical task" where functional programs start to fail. Writing a GUI in a functional program is pretty much impossible if you don't use their imperative extensions for example.

So in conclusion, the answer you're asking for is a heart-felt yes, functional programs are up to the task. The answer you're really looking for however, is that it's a bit more complicated than that.

Answer 8

Have you ever used LINQ?

If so, congratulations. You have used a functional language in a practical context. This is what functional development is about.

And yes, F# is VERY useful.