Ask HN: Is functional programming really worth it?

And one last thing. Is functional programming really better than imperative programming? All that brain-racking to implement a multi-level loop using recursion in ML? IMO, imperative programming cleanly maps out to the real world. The world is imperative!

"LISP embodied a much greater leap of imagination. Conceptually FORTRAN remained on familiar grounds in the sense that its purpose was to aid the mechanization of computational processes we used to do with pen and paper (and mechanical desk calculators if you could afford them). This was in strong contrast to LISP whose purpose was to enable the execution of processes that no one would dream of performing with pen and paper." - EWD 1284

It's worth it, but it's not a magic bullet. Language wars are for people who like tools better than they like workshops.

my own experience is that learning functional programming gave me more options - that can be useful when solving problems. when writing code for myself i try to combine the best of function, oo and procedural styles, while staying within "good taste" for the language i am using (sometimes i cannot choose the language).

so yes it's worth it, but your question leans too much to extremes: it's not a silver bullet any more than oo was; it's a mental tool that does help in every-day programming.

Regarding "betterness", it's a philosophical shift -- some problems are better suited to one domain or another. My favorite metaphor for functional programming is Unix pipes:

cat file | grep XYZ | sort -r -n | ...

There's no explicit state but you can track the flow... output a file, search for something, sort that result, pipe it somewhere else, etc.

Imperative/state-based programming forces you to give names to all those intermediate results, just so you can pass them along. Sometimes variables are just a place to hold data until you can pass them to the next function; functional programming makes that so easy you don't need the variable. And think about how much easier it is to debug; once you get a part of the pipeline working, you can move to the next part (without worrying about global variables and other hidden interactions that can happen with imperative programming).

Seriously though, if you want to try both perspectives, you have to submerge yourself in a functional viewpoint until you start thinking like that. Because if you grew up thinking functionally, you'd find it easier than imperatively.

From PG's famous essay (even quoted on WikiPedia):

  > ... when our hypothetical Blub programmer looks in the other
  > direction, up the power continuum, he doesn't realize he's
  > looking up.  What he sees are merely weird languages.  He
  > probably considers them about equivalent in power to Blub,
  > but with all this other hairy stuff thrown in as well.
  >
  > Blub is good enough for him, because he thinks in Blub.

But learning, properly learning a functional language gives you more experience, more ways of thinking, more techniques, more options.

But remember:

  "The dedicated real programmer can write
   ForTran programs in ANY language."

Then you can make the choice.

I don't think that this means an imperative language is therefore better than a functional programming language. Many problems would be better solved with more 'mathy' models.

I'm not accusing you of this, but it does drive me a bit bonkers when code becomes anthropomorphized, e.g. "this guy talks to that observer, who sends a message to the account manager." This type of code is frequently not very modular and hard to maintain. A functional programming language makes it hard to think like this, and IMHO that's a good thing.

Better libraries can't give you the compile-time error checking that a good compiler can. In Haskell, I half-seriously joke that "it compiles, it must be correct".

Also, modern functional languages have great library support. For instance, Haskell has a variety of libraries available, and a great FFI to C that lets you talk to any available C library. (I consider an FFI a necessary part of any generally useful language.)

And finally, "implement a multi-level loop using recursion in ML" sounds like a learning exercise, not a useful programming technique. If your code tries to recreate constructs like multi-level loops, you've done something wrong; most of your code shouldn't even need explicit recursion. Don't try to write one language's code in another language, and especially don't try to emulate an imperative language in a functional language. Learn how to do things the right way in the new language. If you try to write Java in Haskell, you'll find that it feels a lot harder than writing Java in Java, shockingly. :)

You've learned to think imperatively. Functional programming requires a different approach. It took me a long time to learn to think in Haskell, but now I feel quite comfortable with it. Having watched and helped non-programmers learn to work with imperative programming, I know that doing so requires some hard leaps as well. ("Wait, x = 5? But x = 4 earlier, so how can x = 5 now?")

Many in the functional world realize that some things are akward (see Peyton-Jones's talk "Wearing the hair shirt" about Haskell).

To answer the question about loops with recursion: you seldom write recursive functions when programming functionally but instead cast things into maps, filters and reduces. Thus it's not such a big problem (and the cool thing about using map & family is that you can replace them with parallel versions quite easily). With that said, some practical functional languages provide sugar to write seemingly imperative loops.

In terms of libraries, at least Scala, Clojure, F#, CAL, Nemerle (amongst others) ingrate well with either the JVM and/or the .Net platform. You can implement Erlang nodes in any JVM language (which I grant is not as good as calling directly into the JVM from an Erlang function).

There are definitely advantages to writing as much of your code as possible to avoid side effects (obviously ignoring the odd print statement to help with debugging), since your code becomes easy to test and easy to reason about. But in real world apps you will need state management - Clojure and Scala both allow this (in different ways) and I'm sure that F# does too (though I've never worked with F#).

I think that these three languages address many (all?) of your concerns. They all have cool user communities, so give one of them a shot.

There is really only one difference between FP and traditional imperative programming (which I'll call IP). In IP you have direct control over where the results of computations are stored and in FP you don't. This is, of course, a two-edged sword. Control gives you both power and the ability to screw things up. Lack of control makes it easier for your compiler to perform certain kinds of optimizations.

The reason learning FP is worthwhile is not so much because FP is some kind of magic bullet, but because understanding the tradeoffs between having this kind of control and not having it is worthwhile in and of itself. If you understand those tradeoffs you will write better code in whatever language you use, even if it's assembler.

- lisps: scheme, CL esp. SBCL, clojure

- F#, scala

- erlang, ocaml, haskell

here's some books, freely available content, including for ocaml and haskell

http://www.freetechbooks.com/functional-programming-f34.html

but missing scala: http://programmingscala.com/

Yes, all true. Also, the world is extremely concurrent, made up of billions of independent actors sending each other messages.

That's why we need to use Erlang, an imperative, stateful, mathematically inelegant language.

Might be true. But in my experience that single line takes as much time to think up as the 20 lines in C. So it doesn't really work as an argument for either.

Some basic things which i didn't knew in the begining :

Fast persistent data structures - Coming from imperative langs, one might be hesitant to write functions which take a million elt vector, modify it and return a new vector. It is important to know that any good implementation of functional data structures will allow you to do this in constant time & speed. (independent of the size of the data structure).

Editor combinators : If you arent aware of this & are modifying a data structure with several levels of nesting, imperative assignment will seem much more convenient, ie dont translate foo.bar[8]=3, into something of this pattern barNew = editVector(foo.bar, 8, 3), fooNew=editMap(foo, "bar", barNew). It gets worse with more levels. Instead, use an editor-combinator library which will allow to you specify the path within the data-structure and a new value just as in the imperative case.

Things to know which are not strictly FP related, but nevertheless very useful - pattern matching simplifies definitions a lot, typeclasses are usually more convenient than class hierarchies.

Someone has already pointed out advice on libraries, (Clojure or any using any popular language in a functional way).

The main thing which motivates all of this - composability. It is hard to combine procedures with side effects into compound procedures because one needs to keep track of whether the component procedures are interfering with each other. FP eliminates this friction in composition.

As someone who has programmed extensively in Arc... you're right. The language is very pretty and very concise, but to get things done, I find myself going back to Python (and to get things done quickly in the execution sense, C++). If only Arc weren't so slow and had more libraries...

Haskell: where the great ideas are coming from, although early implementation decisions have made those a bit painful to use (language extensions). It's probably the most "mind-bending" language out there so I recommend it for growth.

Ocaml: excellent and very simple language, with a kick-ass garbage collector. The worst thing about it is the associated build system, OMake, which is almost as ugly as Make. Most people who are turned off by Ocaml are actually turned off by the build environment or by the Ocaml team's resistance to improvement. (The standard libraries are really terrible; if I recall correctly, List.map isn't even tail-recursive).

Clojure: Great compromise between power of language and library support, because it runs on the Java Virtual Machine. It's a Lisp, so it's dynamically typed. It also has some warts related to its Java roots; for example, 43 and (biginteger 43) count as separate keys in a map. However, these are easy to work around.

* 1918 libraries for Haskell (according to http://hackage.haskell.org)

for comparison, there are 1420 Erlang libraries (according to http://projects.trapexit.org/web/)

Was there something you were looking for that's not on Hackage?

I don't want to weigh in on the general 'are functional languages' better debate (as I don't have enough experience of them), just wanted to share that as a data point.

Save lines of code != get work done quicker. What might appear as a paradox should be obvious: we spend more time debugging, modifying, expanding and organizing than writing.

IMO, imperative programming cleanly maps out to the real world.

More so does CUDA with a random number generator. You can't get more precise than quantum (yet).

Truth is it's so much more easier to think imperative.

That's like saying it's easier for a Chinese to speak Mandarin than for a French.

So, Is functional programming really worth it?

To use, it depends. To learn, yes. One can't learn too much in life.

Could someone that has used both statically and dynamically typed functional languages comment on what they liked and disliked from both experiences? I am interested in exploring a functional language because they seem to have cool ideas in them, but I'm not sure what road to start down.