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

I would have RTFA

[Anonymous Coward]

But I was too lazy to click on 13 pageviews.

Too constrained and academic

[m50d]

The problem with Haskell is that it's a superb language for solving the sort of problems its designers foresaw. Unfortunately it makes it almost impossible to do things they didn't expect; you're too trapped in the rigours of the Haskell way of doing things.

A separate, but related problem is that the community doesn't seem interested in practical use of it - there aren't lots of bindings to libraries to make easy things easy. Heck, even doing i/o at all isn't really supported very well. Functional programming is very good for the pure computer science part of programming, but unfortunately that's going to make up less than half of any given program. You also need to be able to interface.

So I think the quote in the summary is right: people won't be adopting Haskell or similar pure-functional languages any time soon. What will happen is the next generation of dynamic languages will adopt the best features from functional programming; we've seen that happen already in python and ruby, and it'll happen again. And people will start using them there.

Re:Too constrained and academic

[Unending]

Very true, I did a large project in Haskell for a CS class once the three of us working on it hated the language after we were done.
Before that we were pretty happy with Haskell, because the programming assignments leading up to the final project were all fitted to the language, but the instant we had to do something that wasn't, we realized what a mess it is.

Why they don't rule:

[Kingrames]

The picture in the linked article is missing a beard.

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:Mmmm, Kay.

[NoNeeeed]

Here's a function that generates the infinite list of fibbonacci numbers: fibs x y = x : (fibs y (x + y))

You have just demonstrated thermian's point.

How often do you actually need to generate infinite sequences? I have never needed to do that outside of a functional programming class.

I'm a big fan of alternative programming languages, I've used some 20 or so since I started 20 years ago. I did a fair amount of commercial Prolog development after I left university, I really like Prolog. It makes certain things really easy and it's a joy to code certain types of solutions in, but I'm never going to write a web-app, or a word-processor in Prolog.

Many of these languages are very clever when it comes to doing certain things, but how often do you actually need to do those things?

The truth is that the vast majority of the software out there does pretty dull, mostly procedural jobs. That's why the main languages in use are just dull variations on the procedural, C/Java/Perl style. No matter how much maths geeks go on about functional programming, procedural systems will always be more suited and easier to use for most of the problems out there.

That isn't to say there is no place for these alternative languages, but it's a smaller one which you probably won't see very often.

Paul

Re:Mmmm, Kay.

[arevos]

The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages.

At University, I studied SML, and came out with a opinion similar to yours concerning functional languages. But when I started to learn Haskell on my own, really learn it, I found that all the concepts in my CompSci courses that seemed so pointlessly complex before, just fell neatly into place.

I'll give you an example of a case where my solution in Haskell to a problem was rather better than any solution I came up with in C#. A while ago I was designing a program to export some hierarchical data held in a database to XML. Because SQL resultsets are 2D grids, I needed a way of converting a 2D grid into a list of fixed-depth tree structures.

In Haskell, the solution is two lines of code, and assuming you know Haskell pretty well, it's fairly clear as well:

listToForest :: Eq a => [[a]] -> Forest a
listToForest = map toBranch . groupBy ((==) `on` head) . filter (/= [])
              where toBranch = Node . (head . head) <*> (listToForest . map tail)

I'd be interested to see if you could mirror the functionality in one of the 'popular' languages you mentioned. Perhaps something in Java?

Re:Mmmm, Kay.

[0xABADC0DA]

Haskell only evaluates what it has to -- this program for example which looks up the 3000th element of the sequence will not compute the complexCalculation on the 2999 fibbonaccis before hand like a traditional program would

And then when you actually do use the other values you program is ridiculously slow because the generator function is recalculating the fibonacci number over and over again.

Except you hope that Haskell automatically memoizes the results, but that destroys your smp performance as the CPUs contend over the result cache. So maybe you have separate caches per thread. Then you program grows larger and all the memoization takes too much memory and the system start dropping out results (3000th fib is what 520? bytes). Then you have to go back and tell it to keep the results longer for that function.

In the end maybe you just make it a list that's precomputed.

But that's really beside the point, because you can do the exact same thing in Smalltalk, Ruby, JavaScript, etc, with most of the same costs and benefits. So really the question is, what makes it better than Smalltalk? It's faster at maths, but that's about it. But it has a harder/alien paradigm, the syntax is foreign, etc. Maybe that's why afaik mainly Haskell is only being used by people that crunch numbers ?

Re:Mmmm, Kay.

[thermian]

That underlying C code is what needs to be written carefully, because you use Haskell itself to write its own compiler.

There's a Haskell compiler written in Haskell already. Where does C fit in to that?

After the 'l' and before the 'o'.