There's more and more attention on languages such as Haskell and F# and although I can see the parallelisation benefits where processing large amounts of data, I cannot see where a functional language would fit into standard LOB development. So for the majority, is there a use for functional languages?
+2
A:
Well, why not?
Functional languages can do anything any other language can, and they force interfaces to be well-defined. They are particularly well suited to tasks that involve transforming data from one format to another, e.g. where XSLT would be used. In fact, XSLT is a functional language.
Marcin
2008-10-05 08:56:40
+2
A:
Multi paradigm languages such as Python give you the choice of most appropriate tool for the job, and features like comprehensions and closures help you write compact and concise production code. Little functions written without using anything but the platform supplied types can be very effective for code reuse, since you don't have to take an entire class hierarchy from a different package to get the specific functionality you are after, and you don't have to worry about side effects if you can see the functions you are calling are pure.
I used to write lots of procedural C and object oriented Python. I now write lots of procedural C (mainly for kernel level code) and otherwise I'll mainly write functional programming style Python. Sometimes object orientation is a great way to solve a problem, and I'll happily mix the paradigms even within a single module.
Choice of libraries and quality of implementation is important when selecting a platform. F# is interesting since .NET is a strong platform these days. Many of the other functional programming languages are research vehicles without the platform maturity to be a sensible choice.
Dickon Reed
2008-10-05 09:03:34
Well, arguably many multi-paradigm languages give you the mediocre-to-poor of all worlds. I would definitely say that goes for python (except in relation to OO, where it is fairly solid, but not the best by any means).
Marcin
2008-11-03 14:27:53
Python sucks at parallelism, sucks at functional programming, sucks at static checking, sucks at brevity... hardly "the choice of most appropriate tool for the job".
Jon Harrop
2009-05-12 20:04:21
@Jon: I won't argue with your claims about parallelism, FP, or static checking, but brevity? Unless you're comparing it with APL, Python does allow fairly brief expressions of most algorithms.
Novelocrat
2009-08-27 19:25:00
+3
A:
Functional (and, in general, declarative) languages are well-suited for various kinds of data transforms, when you have one or more streams of input data, and have to output one or more transformed streams as output. A classic example of that is XSLT, though it's not functional (merely declarative; doesn't have functions as first-class values). Another is any sort of lexer or parser - writing a parser in a functional language such as Haskell is usually more straightforward, and results in more clear and concise code. On .NET specifically, as soon as I have to deal with some non-XML DSL which is more complicated than reasonable regexps can parse, I look at F# and FParsec.
Pavel Minaev
2009-08-27 19:25:57
A:
"Functional languages can do anything any other language can". Well, C "can do anything any other language can", FORTRAN and assembly too.
When it comes to I/O and keeping state, a purely functional language will give you headakes.
.Net and Java have added many functional languages features that can be used to get 80% of what a pure functional language can give you at 20% of the learning curve. Why bother?
Tarik
2010-10-04 09:31:27
i guess when you need to think functionally you use a language that expresses your intent easier. Yeah you'll have to learn f#'s idioms but the payoff may be worth it.
John Nolan
2010-10-04 10:28:47