Ask HN: Is functional programming really worth it? | Hacker News Reader

Ask HN: Is functional programming really worth it?

58 pointswinter_blue82 comments

Do you think a better language makes you more productive than a language with great libraries?

There's Arc. There's OCaml, Haskell and a plethora of so-called next generation languages. These languages are supposed to be far superior to today's measly languages like Java or C++, and in pg's own words: they're supposed to make you more productive, get work done quicker. (Quote from Revenge of the Nerds: "1 line of LISP replaces 20 lines of C")

But is that really true? From experience I can tell you the lack of libraries in these languages kills off almost any code size advantage you get from using them. So I ask you all, be honest to yourself; is using such a language 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! Things have state! We do not live in an imaginary fluffy world of mathematical elegance & correctness. Truth is it's so much more easier to think imperative.

So, Is functional programming really worth it?

View on HN

I think Clojure may be your answer; functional programming with access to Java's enormous libraries.

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

I wanted to write about Clojure and the fact that it has access to all of Java libraries, but you overdid me. So I'll mention F# which is in a similar position in the .NET world.

I second taking a look at Clojure.

Also, your comment of:

The world is imperative! Things have state! We do not live in an imaginary fluffy world of mathematical elegance & correctness.

I would check out article by Rick Hickey on state on the Clojure website:

http://clojure.org/state

It will get you thinking about how often your objects really need to have "state".

How is that not just:

cat(file).grep('XYZ').sort... ?

Your example is way different. You're operating on objects instead of return values. Rewriting what you gave:

  using namespace UnixUtilities;
  sort(grep(cat(filename), 'XYZ'));

No object necessary. No storage necessary. For your example to work the object needs to store the result of each method call in some member variable. Why is that a bad thing? Because it's harder to reason about member variables (that could change) than return values (which will always be the same if there is no state).

Or:

   yourUtility = sort . grep "XYZ" . cat

The OO example works off of return values, and the next .method() is on the return value of the previous call. It's almost totally isomorphic to your example (calling a function with the output of another), and isn't even really very OO in and of itself.

Ah, of course. That's what I get for commenting when I'm tired. The only comment that I would make is that the dot notation is very OO, indicating the method on the right is a member of the class of the object on the left. The 'using namespace' in my code was used to indicate the methods I called were static, thereby decoupling them from a particular object.

You're right, the location the function/method lives is slightly different. When I said it wasn't really OO, it is because there's no data encapsulation going on. Just running methods on the output of another method. The line of code could belong in an OO system, but is not in itself OO.

Good question. I'm not an expert in functional programming but it's changed my mindset.

Imperative / functional languages are equally powerful, but are they equally expressive? There's a reason I wrote the above in a shell script vs. an OO-language (or C): shell scripting captures my intent with minimal overhead, with the right primitives built-in.

OO-languages force you to define classes, methods, type input parameters, etc. up front. So if you know you just want that exact workflow then you can model it.

What if I want to customize the sort routine? Well, I guess I can define a sorting interface and take that as an argument.

And what if I want a more flexible data structure? (With unix it's all text, but why not a hashmap being passed around?). Well, I can define a generic "list" class with an infinite number of members, and all the operations change this list.

But now we've gotten away from OO programming (saying data is of type "List" is not saying much at all).

We're basically trying to recreate functional programming ideas:

* Simple, flexible, built-in data structures (list of lists)

* Pass around functions at runtime, as you please (no interface to define, instantiate an object of that interface, and pass in)

* Composable functions (at runtime, decide that function Z is really F(G(x)))

It's not that the operations aren't possible, but OO languages seem to lead you down a specification-first path, usually customized to a problem domain.

You can "get around" this by using design patterns like Strategy, but again, you're recreating functional ideas in another language. Not that it's impossible, but it's not quite suited for the problem domain (like doing text processing in C vs. using perl... yes, you can find a regex lib, and a better string class, but why not use a language with it built in?).

Hope this helps -- different languages help you think differently. I've used C# a lot and really love the mix of functional and imperative styles in the latest versions (3.5). Joel had a good post (http://www.joelonsoftware.com/items/2006/08/01.html) on this regarding map/reduce: it's not that it's "impossible" in OO languages, but you don't instinctively think about ideas like "passing around a function and apply it to data".

I can't speak with authority on OCaml or Haskell, but Common Lisp isn't lacking in terms of libraries. You just have to know where to look (http://www.cliki.net) and how to manage them.

"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

> You just have to know where to look (http://www.cliki.net) and how to manage them.

I would argue that if one needs to know where to look and how to manage them, then CL _is_ lacking in terms of libraries. One first has to know where to look and find a CL implementation then to know where to look and find batteries for it.

I disagree. The months or years you will spend learning a new language dwarfs the hour or two you may spend learning where the packages are and how to install them. These arguments are more relevant at the entry level (PHP, etc) but someone learning their third or fourth language should have less trivial considerations in mind than how nice its implementation of CPAN is.

Sounds like you don't want Lisp then. Lisp is the battery. It's the ultimate freedom of choice. Use libraries from: your friends, a coder you respect, or write your own.

You don't complain about not knowing where to look to get a Linux distribution do you? Freedom leads to fragmentation, but the fact that there are a million Linux distributions doesn't make Linux any less powerful.

If you want an Ubuntu, don't use Lisp. More power to you. Some people just want to get the job done quickly with at little thinking as possible. I know I feel that way sometimes. But if you want an Arch, where you built the system from the ground up, then you want Lisp. And at the end of the day when something breaks, you just might know how to fix it. ;)

i use python for anything that's not speed-critical. see http://norvig.com/python-lisp.html (norvig being a very famous lisp programmer).

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.

Python lets you use multi-paradigm programming - Functional where that makes sense and OOP for where that is better.

Functional programming is not always the optimal choice. But when it is, it is awesome.

Libraries have been the focus of the Haskell community for the past 2 years, there's now:

* 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?

There may be more haskell libs, but I doubt that they are as tested as the erlang libs.

Yes. But not as worth it as hard-core advocates of FP like to think.

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.

From experience I can tell you the lack of libraries in these languages kills off almost any code size advantage you get from using them. So I ask you all, be honest to yourself; is using such a language worth it?

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.

It's hard to generalize, but I would say there are at least 8 non-obscure FP's that either hook into java and .NET libs, or have some level of stdlib and community libs (I've only used 3, and I hear C# is getting some functional aspects, but I'm not following).

- 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/

I think more-accessible concurrent programming is FP's killer app, things like riak, rabbitMQ,

here's a STM and/or actor/ message-passing vs. lock/monitor/mutex /semaphore reading list:

http://www.tbray.org/ongoing/What/Technology/Concurrency/

http://www.sauria.com/blog/2009/10/05/the-cambrian-period-of...

http://www.scribd.com/doc/28336206/Multicore-programming-in-...

http://groups.google.com/group/clojure/browse_thread/thread/...

http://blogs.azulsystems.com/cliff/2008/09/jvm-language-su.h...

http://wiki.jvmlangsummit.com/pdf/36_Click_fastbcs.pdf

random afterthought:

- haskell, F#, scala are state of the art as far as type inference:

http://blogs.tedneward.com/2010/02/14/Dont+Fear+The+DynamicV...

- scala has become a actor/message passing and STM lab:

http://osl.cs.uiuc.edu/docs/pppj09/paper.pdf

http://www.stanford.edu/class/cs94si/Concurrency.pdf

http://github.com/djspiewak/scala-stm

http://akkasource.org/

"The world is imperative! Things have state! We do not live in an imaginary fluffy world of mathematical elegance & correctness."

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.

YES ! Well explained !!!

Processes map well to functional programming, but then when we look at what is being processed, it often has to have state and have specific behaviors. So choosing the best fit abstraction is critical to clean implementations.

Immutability, reusable and composable functions, side effect free methods are worth to use in every programming language, even in Java (I've been using functional ideas for a long time in my Java works)

The company I work at uses Java as its 'main' language. In the past year my team has been increasingly using Scala for new development. One of the most useful features of Scala is the functional treatment of collections. Most of the programming we do (that everyone does?) is really just manipulation of collections, so being able to map/filter/reduce/group collections in a couple of lines of code, rather than the verbose Java equivalent, is a big win.

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.

Do the lisp lovers ever miss compile-time type-checking? All the programming language theorists at university love OCaml and Haskell because they are really into type systems for preventing errors in code. But lisp/Clojure seems to be more popular outside the university.

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.

You can write functional code in perl 5 from 15 years ago... and you can do an even better job of it in perl today. CPAN has no shortage of libraries. See Higher Order Perl book (it's free too).

The "Higher-Order Perl" book by Mark Jason Dominus can be found here: http://hop.perl.plover.com/book/

Highly recommend to Perl & non-Perl programmers.

I'm a functional convert but my colleagues will tell you just how convoluted some of my code has been due my trying to shoehorn everything into a functional mold.

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.

> maps, filters and reduces

Don't forget unfold! http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.42.1...

"1 line of LISP replaces 20 lines of C"

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.

Good point.

It's impossible for 1 line to contain as many bugs as 20 lines may. Should make debugging time shorter, shouldn't it?

Abstraction and a good evaluation model go a long way towards helping you in thinking quickly. A subset of Common Lisp is to C what jQuery is to vanilla javascript; You can easily see a line of jQuery replacing 20 lines of cruft, and it doesn't take that long to think it up.

That may be, but if you're using good abstractions, it's easy to think of that single line in terms of arguments, side effects and return value. It becomes a good deal simpler to understand later when you're revisiting your code after six months.

80% of that line's lifetime is in maintanence mode. Which option -- maintaining 20 lines of C or 1 line of lisp -- would you prefer to maintain?

That depends on whether or not you're able to comprehend the line of lisp as quickly as the 20 lines of C. Conciseness doesn't equal clarity.

Wrong on both accounts.

would you care to elaborate on that? Needless to say I disagree with you, but I can hardly say why if I don't know about your arguments.

Before you arrive at a judgement of the paradigm itself be sure that you know some of the standard ways to solve problems in the field.

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.

Expand your mind. It'll pay dividends later.

Exactly. Functional programming may or may not be "worth it" to use for one particular problem or another.

However, if we ask ourselves whether functional programming is worth learning (as I suspect the poster is really asking), then the answer is clearly yes, if for no other reason than that's the only way you can make an informed decision as to whether it's worth applying FP to that particular problem of yours.

I agree. It's a myth the functional languages are simply more difficult. Once you learn to think functionally, it's just as natural as writing imperative code and doesn't take any more time. In fact, once you get really comfortable with the abstractions, you can move much more quickly, through complex recursion and all.

One word: Blub.

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.

The other point is that there are pure OO languages, pure functional languages, pure logic languages, pure imperative languages, and rarely is a problem easily and comfortably expressed entirely in one pure paradigm.

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

I've seen ForTran programs written in Haskell, believe it or not. You need to learn not just the language syntax, but the underlying ideas and techniques.

Then you can make the choice.

"I've seen ForTran programs written in Haskell, believe it or not."

I once wrote a toy library that lets you write BASIC in Haskell:

  main = runBASIC $ do
      10 PRINT "BASIC in Haskell"
      18 GOSUB 1000
      20 GOTO 10
      15 PRINT "Out-of-order line"
      1000 PRINT "gosub"
      1010 RETURN

(Yes, line numbers and all.)

Lennart Augustsson extended that to allow things like "10 PRINT 2 + 2" (no parentheses needed), along with most of the rest of BASIC; his approach effectively implemented a full parser and treated everything as a token. He also added LLVM-based code generation. See http://hackage.haskell.org/package/BASIC .

Yea I've heard the blub story told over many times.

I understand functional programming perfectly well. It's just that for most of the time, it's easier to think imperatively. Yes, there are some special problems (Towers of Hanoi, Ackermann's) where functional programming is truly the way to go. But in most cases it isn't.

FYI I use gotos in my C programs when I see it's the easiest & clearest to get something done. I think you should go with what best suits the situation.

What troubles me though is when you go out of your way to do everything functional-style, even when you know there are easier ways of doing it. And the problem is this happens way too often to be ignored. Some functional programmers just push the functional idiom into everything they do, to such a point that understanding their code is like solving a sudoku puzzle.

It's not about how easy something is to do. The greatest value of functional programming is robustness. In 10 years of professional programming, I'd estimate that something around 90% of the nastiest bugs I've discovered would have been preemptively prevented by using a strictly functional style. Sometimes these bugs are just the result of poor thinking, but often they are the subtle result of changes over time that would be almost impossible to anticipate.

Functional programming imposes some constraints that range from mild discipline to mind-bendingly difficult. However in general I can't think of many constraints that provide a better power-to-weight ratio (garbage collection is probably one).

If Haskell was the dominant language and functional programming was how everything was done all the time, then I could buy into the argument that there are easier ways to do things. However as it stands, not enough people really grok functional programming (myself included) to optimally apply those principles towards the creation of robust systems in non-pure languages.

You don't understand it perfectly well, though. You're not "racking your brain" because loops are better fits to most problems than other approaches -- it's because you're still learning.

That's perfectly okay, of course. It just means it's a little early to start making final conclusions.

I think you may have missed the point of the blub story, then.

> What troubles me though is when you go out of your way to do everything functional-style, even when you know there are easier ways of doing it.

The point is that you (to possibly generalize a bit since I don't know you) are 'going out of your way' to write everything in an imperative style because you don't know there are easier ways of doing it.

This is exactly what the blub story is saying. You are looking 'up' at functional languages and saying "in most cases that's just esoteric weirdness that I don't need" because you think in blub.

Here's an alternate version of your last sentence from a hypothetical functional programmers perspective:

> Some imperative programmers just push the idiom into everything they do, to such a point that understanding their code is like untangling spaghetti.

Personally, of all PGs writing (that I've read, and that's definitely not all of it) I like that bit the least.

Maybe that's because I'm a 'Blub' programmer, in spite of some real effort to 'dig' the functional programming method, maybe it is because I think that it exposes a sort of smug attitude towards those that program in 'lesser' languages.

There is a taste of an attitude there that I can't rhyme with the other things that PG wrote.

You don't show the advantages of a language or a technique by making the argument about people, especially not by talking down to them from that high up.

I hear what you say, but there was a time when I thought imperative, non-structured programming was all there was, and anything like structured programming, then later OOP, then later FP, was just more complexity that was unnecessary. As I've grown to become more comfortable with each of those I've realised that they are more than just extra bells and whistles - they are ways of thinking.

As I continue to learn more about them, so I continue to become a better programmer even in languages that don't exactly match the paradigms. Learning structured programming has made my assembly coding better, even when I use all the nasty tricks available. Learning about FP, logic and constraint programming has made my C++ and Python coding better.

I'm sure I don't yet know everything, or even half of everything. I don't (often) use a pure FPL, but knowing, really knowing, about pure FP has made my thinking better.

Who knows what remains to be discovered or invented that will expand our thinking further.

> they are ways of thinking.

I'm on to that, as you know from our email exchanges, but I don't like the idea of presenting the one as 'better' than the other.

Both FP and IP have earned their place in the toolbox, and even though I'm much more familiar and comfortable with the 'IP' portion of it I can see the power of some of the concepts behind FP. But I find it very hard to believe that FP is so much better than IP that it warrants talking down to the people using it.

> As I continue to learn more about them, so I continue to become a better programmer even in languages that don't exactly match the paradigms.

Agreed, and even while I definitely have not 'grokked' functional programming yet to the point where it would make sense for me to write some small utility in an FP language I can see how just learning about FP has influenced my coding style in other languages.

> Who knows what remains to be discovered or invented that will expand our thinking further.

Working on that :)

It's mostly a matter of constraints on this end, I probably took on more than I can handle in terms of work that simply needs doing and I hoped that through FP I would find some shortcut allowing me to become more productive. It has worked in a sense, some of the code I wrote for other projects has become more clean because of reading about and playing with FP, but in a concrete sense where I can substitute a functional language for an imperative one and get more mileage out of my days it hasn't (yet).

But I'm optimistic that one day it will, and as long as I can see it influence my thinking in a positive way I'll continue to study it.

One of the biggest eye openers so far was 'memoization', I'm not even sure that I understand it well enough to paraphrase it, but when looking at the source of hashlife it suddenly clicked: When you work in a functional way and you are guaranteed that there are no side effects stemming from lower layers you can replace the call to a function with a bunch of arguments, no matter how complex with its result. That literally blew my mind, even though in hindsight it is a blindingly obvious thing.

That such a 'small' thing as side effects could have such polluting effects on higher level code that a thing like memoization is impossible gave me a lot of energy to continue my 'quest' :)

> That literally blew my mind, even though in hindsight it is a blindingly obvious thing.

Must have been messy.

I'd like to see a "blub" retrospective. The original "blub" article was written pre-YC. YC has funded lots of blub programmers, and pg's Lisp advocacy seems to have been toned down since then.

I do believe a better language helps as much as great libraries, if not more.

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?")

F# --- functional language with thousands of the most easily available languages anywhere.

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

Language wars are for people who dislike watching other people seriously injure themselves in the workshop. When I advocate a language or technique, it's because I honestly believe that trying it out will make your life measurably better.

This becomes a "war" because the other side can't believe that there is something that they don't already know, and they will defend that illusion to the death. It's quite hilarious... in a sad, sad way...

> the other side

As long as there are sides there are wars. The thing to recognize is that there are no sides, that we're all in the same boat and that we all have something to contribute. Convincing someone of the validity of an argument - especially against the 'unbelievers' - takes time, patience and diplomacy, not a war.

I agree that trying out a new language or technique can make life measurably better, but if you were a FP 'die hard' that has never written a line of imperative code in their whole lives you'd probably stand just as much to gain. This whole FP is 'better' argument is getting a little tired, better means 'always better' and that is not something that I consider proven - for now.

This whole FP is 'better' argument is getting a little tired, better means 'always better' and that is not something that I consider proven - for now.

But keep in mind, you are hearing this from people that don't know anything about FP. The person who posted the Ask HN admits as much -- "I hear FP is awesome, but I don't want to learn it. Will someone please rehash at least eighty-nine reasons why I'm missing out? Because if there are only eighty-eight reasons, I am going to smugly declare that FP is worthless."

Let's face it, there is a such thing as a dumb question, and this is one.

There are some very adept FP programmers right here on HN that do not think that FP is a silver bullet, and there are a few that think it is, including PG.

I'm reserving my own judgment until I've gotten good enough at it that I can rightly say I can make up my mind by myself without external input.

That point is probably a long way off, but any attempt at ramming something down my throat (be it IP or FP is besides the point) is met with resistance.

Arguments, not rhetoric persuade people.

If FP were obviously better and as easy to learn as some claim then these arguments would be superfluous, the fact that it isn't means that the case is not as clear cut as some make it out to be.

Let's take HN as an example.

It's a site built by a man that is considered to be God himself when it comes to functional programming, working in a language that he himself states is going to be a 100 year language.

The site suffers regular outages, has serious limitations with respect to functionality that is present but simply does not work and small changes are apparently so hard to add that it takes months for even the simplest items. The way to deal with load issues is by cutting functionality (see the length of the per user comments list, new pages and so on).

Mr. Blub himself would have fixed these things long ago and would not tolerate such a state of affairs, programming in visual basic .net if that's what it came to.

If that's the 'poster website' for FP then I think that I'm either missing something or FP isn't as good as it is cracked up to be for the environment that most of the people here are working in (web programming).

Possibly a port of HN to a more stable platform (say clojure) would remedy some of these issues, but if PG can't 'hack' it then who am I to even try.

Arc is not really FP; it just happens to be a descriptive DSL for web apps.

news.arc has its limitations, but it's not because of functional programming; it's because pg tried to do as many things "differently" as possible (in-memory data-store, no "objects", etc.). The goal of news.arc, I assume, was to play with ideas, not to build a website. The website is just a side effect.

I won't debate the merits of news.arc's design, but I will note that not everything is about "building a scalable website". There is more to life than the output of ab.

Short answer: yes. If your code is so imperative, then it can probably be abstracted up a bit. That's been my experience so far.

Personally I love Haskell, but I did a bunch of mathematical logic at university so that might explain it :)

For practical work though I think hybrid FP/OO languages like Ruby and Scala (maybe Python and LISP too) are usually a better choice. Pure functional programming requires too much of an appreciation of higher structural aspects of mathematics, logic and theoretical computer science, to be viable for use with mixed-background teams on bigger projects.

I'm also not convinced Monads are the final word as a scalable structure for software engineering with FP. I think (hope?) research will yield something better.

But in environments where a lot of smart math/comp-sci oriented people work on a codebase, I think something pure functional can be a good choice. eg stuff like darcs (which is very algebraic), compilers, comp sci research, people at algorithmic trading firms, projects that want powerful code verification capabilities.

The right tool for the job. Just like object oriented code isn't the be-all-end-all, function programming isn't either. Computers are functional! Everything is data! All actions are operations upon that data! Computers are a real world of mathematical elegance & correctness, it's all zeros and ones. It's so much easier to think functionally...

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.

Right ON !

When you get down to the silicon there's only data and instructions to manipulate that data. Everything else is abstractions poured over the top to suit specific application domains.

It's more about the concepts, IMHO. Google has implemented MapReduce in C++. Which is probably why they're dominating the world while I'm playing with another language I'll never get to write anything in...

First it was in Python, now in C++. The change was for speed reasons, not because they didn't like functional languages. It is simply that functional languages don't quite meet the speed requirement that Google needs. And yes, I know that Haskell can compile some extremely fast code, but it still has not insignificant issues with memory bloat.

I think its like asking if French is better than English. Both will get the job done but some people claim French sounds better and is the "language of love". So the point is there may be tasks for which one language is more suitable. I have used both and learning FP after learning IP was a bitch. But I am an engineer not a programmer, so take that for what its worth. I did find that I got a deeper understanding of mathematics by learning FP so that was definitely a benefit and possibly a clue as to what types of tasks FP is more suitable.

"From experience I can tell you the lack of libraries in these languages kills off almost any code size advantage you get from using them. So I ask you all, be honest to yourself; is using such a language worth it?"

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

I cannot say if this is generally true for functional languages but a good comparison of the efficiency of erlang as compared to java can be found by comparing the code footprint of ejabberd, an erlang xmpp server, and openfire, a java xmpp server. The servers are functionally similar yet the source code footprint of ejabberd is approximately 300 files at 5MB and openfire is approximatley 4000 files at 100MB. The erlang server has more then an order of magnitude less code.

It's certainly worth learning, but I make no secret of my fondness for having local state when programming. It's critically important to consider the breadth and quality of libraries available for your particular task as well as the tools available. With eclipse+maven+continuum+junit+jprofiler I can generate a hell of a lot of java very quickly, even if I didn't have access to my library of code segments.

Lots of comments, so I'm going to remark on one thing in particular: functional programming really makes static typing shine: the types make putting functions together like legos; really obvious when you're very clearly doing it wrong, whereas imperative style is all about saying "do this" and then "do that", which is not something that the type system can help you with.

The world is imperative! Things have state! We do not live in an imaginary fluffy world of mathematical elegance & correctness.

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.

It's not brain brain racking once your brain has adjusted to the slightly different mode of thinking.

Yes, it's worth it.

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.

With regards to List.map: List.rev_map is also in the standard library and is tail-recursive, so you can just do List.rev(List.rev_map l) to tail recursively map. Just had to defend Ocaml a little :)

No functional programming is just something people pretend to like to make themselves feel smarter than others. Notice there are no libraries for functional languages - there is a reason.

Also, pg and his "blub language" argument is lame. All languages that are Turing complete are equivalent. Everything else is syntactic sugar. Pick what you like.

Right, so, any two things that get you from A to B are identical? Unix isn't more powerful than Windows; You can outrun a cop-car in your Prius; Apple pie is apple pie?

There's a lot more that goes into doing a job than just the physical possibility. In the context of programming there's maintainability, developer time spent and a million other factors. The blub argument, specifically the part about 'looking up', is quite literally talking about you.

Look man, all Im saying is what language you should use is matter of personal preference. If you prefer Windows to Unix or vice versa more power to you. Dont make people feel inferior just because you like one tool better than what they use.

The only thing I would make someone feel inferior for is using a tool that's wrong for the job just because of 'personal preference'.

I write Ruby and JavaScript as easily 99% of my work, does that mean I never pick up Erlang or Scala or even C? Of course not, to do that out of stubbornness or some perceived loyalty to my platform would make me a very poor programmer indeed.

Besides, that's not what you're saying. Your comment was pretty well flat out saying functional programming is useless and people only do it to look smart. That, clearly, is a load of crap.

Reply on news.ycombinator.com