Why Lazy Functional Programming Languages Rule

Da Massive writes "Techworld has an in-depth chat with Simon Peyton-Jones about the development of Haskell and his philosophy of do one thing, and do it well. Peyton-Jones describes his interest in lazy functional programming languages, and chats about their increasing relevance in a world with rapidly increasing multi-core CPUs and clusters. 'I think Haskell is increasingly well placed for this multi-core stuff, as I think people are increasingly going to look to languages like Haskell and say 'oh, that's where we can get some good ideas at least', whether or not it's the actual language or concrete syntax that they adopt.'"

Comments

Mmmm, Kay.

[jellomizer]

Hascal, and other functional languages may be good for multi-core development. However not to many programmers program in them... Plus I find they do not scale well for larger application. Its good for true computing problem solving. But today most developopment is for larger application which doesn't necessarly solve problems per-say but create a tool that people can use.

Re:Mmmm, Kay.

[beelsebob]

Absolutely, and this is why there's one of freenode's biggest IRC channels, a pair of mailing lists with thousands of subscribers, and the Hackage library/tool repository just waiting to help you solve your real world problem. Be it Compiler building, version control, writing interpretters for popular imperrative languages, Writing 3D shooters, or a whole host of other tasks.

Re:Mmmm, Kay.

[Dragonslicer]

On my computer, there's an infinite stream of ethernet frames arriving, an infinite stream of video frames leaving, an infinite stream of keyboard events arriving, etc.

You keep on using that word. I do not think it means what you think it means.

Re:Why they don't rule:

[Bob-taro]

The picture in the linked article is missing a beard.

I was going to mod you funny, then I thought maybe a lot of people wouldn't get the beard reference, so I decided to post instead. Anyone else want to mod parent funny?

Re:Why "lazy"?

[tuffy]

They're "lazy" because they don't do any work until necessary. For example, a function can return an infinitely long list, but only the elements you request will actually be calculated. Or, to compare them to Python, it's like having everything function like an iterator.

Re:Too constrained and academic

[AKAImBatman]

There's a more in-depth article on Javascript's functional capabilities here:

http://www.hunlock.com/blogs/Functional_Javascript

Other stuff I pulled out of Google for your perusing:

http://dankogai.typepad.com/blog/2006/03/lambda_calculus.html
http://math.ucr.edu/~mike/lc2js.html
http://www.joelonsoftware.com/items/2006/08/01.html
http://www.ibm.com/developerworks/java/library/wa-javascript.html

What this all means is that Javascript is the most widely deployed functional language in existence! And that's a fact you can take to the bank.

How is X better than Y?

[Tetsujin]

Actually, when you're able to do it naturally in your language, it becomes a very useful thing to do. For example, when you want fresh variables in a compiler

How is that better than doing (or basically the same in Java/C/perl/ruby/etc.):

__compiler_var_num = 0
def next_fresh_variable():
  global __compiler_var_num
  __compiler_var_num += 1
  return "_id_%d" % __compiler_var_num

I hate to say "you're missing the point" because I feel that's unreasonably dismissive - though I kind of feel you are...

IMO the point isn't necessarily that one method is "better" than another - it's that this idea represents an important and useful way of approaching programming problems. If you understand the style you can appropriate it - it becomes a useful concept for expressing problems and their solutions.

So for instance - while you may not use recursion in C for general problem solving (due to the lack of tail-recursion optimizations which turn the thing into a loop) - understanding the recursive expression of a problem is useful for structuring your solutions, understanding what assertions must be made with respect to the state of the data at what points in the code, etc. - even if you structure your solution as a loop rather than a recursion.

And it should be noted that you can implement infinite sequences in C++, etc. - generally the way to do this is with iterators, and the use case would be for feeding those iterators to algorithms that expect iterators... What Haskell brings to the table is that it encourages you to think of problems and solutions in those terms - learn the method and what you can do with it, how it affects the expression of your code - if you find it a useful idea it's easy enough to implement in most object-oriented languages...