Are functional programming languages good for practical tasks? [closed]

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?

Lyublin

You looked at Erlang and couldn't see a practical use for it? Really? Despite Erlang having been invented specifically for practical use? And having been put to practical use in telephony for a long time already? How closely did you really look at it?! – Giovanna

It sounds like you were looking at Haskell as a language primarily suited to finding analytical solutions. Lazy evaluation has zero impact on this (all it does is increase the class of programs that terminate without encountering an error, and give you somewhat unintuitive performance characteristics). And I'm not sure why you say Haskell's IO capabilities are limited. – Spout

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'.

Valora

In the case of F#, which targets the CLR, you can have the best of both worlds: program your stuff that'll benifit from a functional language in F#, then either use F# for the rest, or switch to C#, or VB.NET, or... – Altair

Or you just use Nemerle for all of it... – Led

This doesn't mention the vast set of .NET tools that are immediately available to F#. Not to mention that you can use it in the same projects built in C#. I guess this is the same for Java and Scala, though. – Kirwan

Answer 2

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.

Madrid

Well, AFAIK F# isn't the purest of functional programming languages. It can work in a very imperative way if you want it. – Gallnut

Yes: F# is in the same category as all of the popular functional programming languages as far as purity is concerned (e.g. OCaml, Scala, Clojure, Common Lisp, Scheme, Standard ML, Erlang, Mathematica). All of the purely functional languages are extinct except Haskell and that is barely used outside academia precisely because it is not great at performing practical tasks (due to purity). – Madrid

+1 For a good ol' honest real world example. – Visitant

Answer 3

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.

Overcoat

GUIs will be dealt with Reactive Programming, multithreading just works wonderfully (see Scala/Akka Futures and Actors), IO is fine using the IO monad, and lately Iteratees. Still, if you do not wish to incorporate all these concepts into your program, a functional core with confined imperative parts will improve maintainability and stability of the software in my experience. – Pennyworth

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.

Secretion

plt-scheme is pretty 'rich' with a lot of libraries and a very active mailing list. – Taryntaryne

-1: None of XMonad, Leksah and Pugs are "real world" and GHC is barely so (it was once common only in the finance sector but even they are now dropping it in favour of F#). F# is in Halo 3 and Bing. Where are comparable real world success stories for Haskell? There are none because it is not "real world" at all. It occupies a tiny niche. – Madrid

+1 to counter a certain anti-Haskell troll's downvote. – Ambulate

Answer 5

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.

Dorado

why did you say LINQ is functional? I don't see the reason – Messinger

Answer 6

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

It also has a DBMS out-of-box.

Ebracteate

Can you clarify about DBMS? How is it integrated in the language? (I've never looked at Erlang) – Granophyre

I think he is talking about Mnesia (erlang.org/doc/apps/mnesia) – Tap

Answer 7

Functional Programming in the Real World

Lowbrow

Answer 8

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.

Giovanna

Answer 9

I'm not sure about 'Practical Tasks' definition and what it refers to. but in other words I think you are talking about solving problems by algorithms that need to be represented by a programming language. if so then the functional language is very useful and practical.Specially when you have limits in time to find the solution and implement it. for me I still use non-functional languages when participating in solving complex algorithmic contests like Google CodeJam . I'm planning to learn a functional language that will be better for me for these kind of tasks or problems.

Astrolabe