
Ask HN: Is functional programming really worth it? - winter_blue
Do you think a better language makes you more productive than a language with great libraries?<p>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")<p>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?<p>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 &#38; correctness. Truth is it's so much more easier to think imperative.<p>So, Is functional programming really worth it?
======
kalid
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).

~~~
pkulak
How is that not just:

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

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

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

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

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

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

 _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

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

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

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

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

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

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

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

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

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

~~~
gtani
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.sauria.com/blog/2009/10/05/the-cambrian-period-of-
concurrency/)

[http://www.scribd.com/doc/28336206/Multicore-programming-
in-...](http://www.scribd.com/doc/28336206/Multicore-programming-in-Haskell)

[http://groups.google.com/group/clojure/browse_thread/thread/...](http://groups.google.com/group/clojure/browse_thread/thread/5c7a962cc72c1fe7?hl=en)

[http://blogs.azulsystems.com/cliff/2008/09/jvm-language-
su.h...](http://blogs.azulsystems.com/cliff/2008/09/jvm-language-su.html)

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

~~~
gtani
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...](http://blogs.tedneward.com/2010/02/14/Dont+Fear+The+DynamicVARIANTReaper.aspx)

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

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

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

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

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

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

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

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

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

~~~
leoc
> maps, filters and reduces

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

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

~~~
lallysingh
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?

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

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

------
Shamiq
Expand your mind. It'll pay dividends later.

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

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

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

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

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

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

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

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

~~~
jrockway
_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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
boryas
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 :)

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

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

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

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

