views:

373

answers:

4

What's the advantage, for someone who is not a theoretical computer scientist, of learning a purely functional language like Haskell or Erlang instead of an "impure" language with a strong functional component, like Python or version 2 of the D programming language? My arguments are as follows:

  1. No paradigm is perfect. Languages that are single-paradigm, regardless of what paradigm that is, are very restrictive.
  2. Python or D will ease you into functional programming while you get real work done. Haskell or Erlang will force you to learn functional style all at once before you can actually do anything of interest in them.

Edit: By "impure" functional languages, what I really mean is strongly multiparadigm languages w/ a functional flavor, not strongly functional languages with some non-functional abilities.

+6  A: 

It all depends on what are trying to achieve. If your goal to write production code in a functional language - a 'pure' functional language can make it more difficult.

But if you are trying to learn new concepts, 'pure' language gives you the benefit of guarding where you are sliding off the mark of functional concepts. Once you have clear understanding of differences you can go to a mixed environments - like F#, but before that it is all too easy to slip to the OOP way of doing things and because of this miss the advantages of functional approach.

In some other thread I offered an opinion that a better way of learning F# is to start with let us say Haskell (and was voted down for this), but if you learn F# to do OOP than what's the point - stay with C#

mfeingold
I think this is a good point. I started looking into F# but my OOP training was getting in the way. Now I think I will look at Haskel first.
Jason
+1  A: 

Is Erlang purely functional? I honestly thought it wasn't.

I'm not an expert on this, so take my words with a grain of salt.

Side-effects prevent (or make more complicated) lots of optimizations, including parallelism. So, in theory, going pure functional should mean better optimization for faster code, although I'm not sure this is true in practice. Even if it does not, it might someday be... it will be fun if a purely functional language comes along which makes using up all the cores easy peasy.

Additionally, in a way, programming without side-effects makes for easier to understand programs.

alex
Erlang's whole raison d'etre is parallel processing. It really is easy to use as many cores as you've got. Data Parallel Haskell is still new, but it's pretty impressive as well. Supero Haskell is another example of the kind of crazy optimizations Haskell's strongly typed, pure-functional nature makes possible.
Chuck
When it comes to reasoning about programs, what's wrong w/ writing the body of a function procedurally if that's easier, but disallowing side effects visible outside a function body?
dsimcha
@Chuck Erlang's whole raison d'etre is disributed programming, not parallel processing with multiple cores. Last time I checked Erlang didn't support multiple cores (if you didn't start a vm for each core). Might have changed since 2007 though.
Daniel W
+5  A: 

You learn very little if your "new" language is just a slight permutation of what you already know. It's like asking, "Why learn Chinese when I can just get a dialect coach to teach me to speak with a Scottish brogue?" I guess it's fine if you enjoy speaking with a brogue, but you're not really expanding your expertise very much.

Learning a functional language teaches you a new way of looking at things. Impure or mixed-paradigm languages like OCaml are good as well, but it can be tempting to use the impure elements as a crutch to avoid having to look at the problem in a new way. No, functional languages are not a magic bullet, but they do have a lot of interesting benefits, and you're robbing yourself of those benefits if you learn a language that has a "functional components" but doesn't really work like a real functional language.

For example, in a pure functional language like Haskell, state is very carefully isolated from the rest of your program. This makes all sorts of optimizations trivial that are very hard in other languages. For example, state is the enemy of parallel processing. In Haskell, you can just look at a function's type and be 100% confident that it won't create any side effects.

This way of thinking in functions that work with immutable data structures something that a pure functional language can teach you. I'm not saying pure functional languages are "the best," but they have their benefits. It's another tool in your belt. And you won't get that tool by sticking with what's familiar.

Chuck
+3  A: 
Norman Ramsey