Slashdot Mirror
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.'"
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.
I am trolling
I haven't really been able to figure out how to do anything significant in Haskell. But I suspect that one day a language more like haskell and less like C will end up being the most popular. Monads and all that kind of confuses me.
I think it helps if you have a strong math background and are comfortable with Lambda calculus. I'm just an old C hacker and haven't used any real math in like 10 years, so I'm not that effective in Haskell :(
“Common sense is not so common.” — Voltaire
I spent a whole term at uni learning Miranda, which is similar to Haskell, I really liked it. I have *never* seen it being used since. To my mind they both belong in the category 'interesting, but pointless'.
Its not just because they're old. If age was what killed languages, C and Lisp would be long dead. There just isn't anything I could do with either that I wouldn't be able to do more easily with another more 'mainstream' language.
A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
I call FUD. There's a lot of things that Lazy functional languages make easy, that mainstream languages don't. Here's just a few examples: Infinite data structures can be handled naturally.
Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?
I agree 100% Haskell is awesome. However, not everyone who is designing rails like sites is going to be working with fibbonacci numbers. We, the doers of awesome, must come up with real world solutions to real world problems that make use of the awesomeness. And then we must document the awesome for all to see and appreciate.
Well.. maybe. Or Maybe not. But Definitely not sort of.
It's only difficult to read if you don't know it.
That is true of almost any language. 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. Elegance cannot beat convenience in the workplace, or in most at any rate.
All that aside, how many Haskell programing jobs have you seen advertised lately? Like it or not, that's what decides which languages people use.
That's why I have to deal with languages I'd prefer to never use, because that's what pays the rent. In my own time I use C.
A learning experience is one of those things that say, 'You know that thing you just did? Don't do that.' - D. Adams
Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?
Might that be because mainstream programming languages don't support infinite data structures?
I call meme misuse.
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
Paul Leader
Might that be because infinite data structures don't often exist in mainstream and/or commercial software applications?
Sure they do. 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.
The thing about functional languages, and strict lazy functional languages like Haskell, is that the underlying principles are quite different from procedural languages like C. In C, you tell the computer to do things. In Haskell, you tell the computer the relationships between things, and it figures out what to do all on its own.
Personally, I suck at Haskell --- I'm too much of a procedural programmer. My mind's stuck in the rails of doing thing procedurally. But I'd very much like to learn it more, *because* it will teach me different ways of thinking about problems. If I can think of an ethernet router as a mapping between an input and output stream of packets rather than as a sequence of discrete events that get processed sequentially, then it may well encourage me to solve the problem in a some better way.
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 ?
I'm not going to take the time to look up the appropriate API calls at the moment, but I believe it's somewhere in the range of 2-3 lines of code to accomplish this feat.
If you're not going to take the time to actually produce any code to back up your point, why bother replying?
The biggest problem with talking about the advantages and disadvantages of programming languages is that people tend to make vague claims without producing any evidence for their case. Can JPA produce lazily produce a hierarchical tree of objects from a single database query? I don't know; it's not an answer you're likely to find in an FAQ or a tutorial. And how much work is it to actually set JPA and XStream up? Does it really only take 2-3 lines of code?
Without providing working code, who knows whether your assertion has any merit or not.