Slashdot Log In
Why Lazy Functional Programming Languages Rule
Posted by
ScuttleMonkey
on Fri Sep 19, 2008 10:18 AM
from the laziness-is-the-mother-of-all-invention dept.
from the laziness-is-the-mother-of-all-invention dept.
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.'"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I would have RTFA (Score:5, Funny)
But I was too lazy to click on 13 pageviews.
Mmmm, Kay. (Score:4, Informative)
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. (Score:5, Insightful)
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.
Parent
Re:Mmmm, Kay. (Score:4, Interesting)
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. Here's a function that generates the infinite list of fibbonacci numbers:
fibs x y = x : (fibs y (x + y))
Here's a list that does a complex calculation on every one of the fibbonacci numbers:
map complexCalculation (fibs 1 1)
While we're at it, Haskell programs are very easily parallelisable. Here's the same list, but computed on multiple cores:
(parMap rnf) complexCalculation (fibs 1 1)
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:
(parMap rnf) complexCalculation (fibs 1 1) !! 3000
There's only a small sample of what's so powerful about these languages. If you'd bothered to RTFA, you'd know there are a lot more. But then, I guess this is slashdot.
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
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?
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
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?
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
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.
Parent
Re:Mmmm, Kay. (Score:4, Informative)
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.
Parent
Re:Mmmm, Kay. (Score:5, Interesting)
When the last argument given is "look it up", I suspect there's no counter-argument.
In what way is there an "infinite stream of ethernet frames ariving" on your computer with its finite lifetime?
If you have an explanation, why not give it?
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
Parent
Re:Mmmm, Kay. (Score:5, Informative)
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 [haskell.org] library/tool repository just waiting to help you solve your real world problem. Be it Compiler building [haskell.org], version control [darcs.net], writing interpretters for popular imperrative languages [perlfoundation.org], Writing 3D shooters [haskell.org], or a whole host of other tasks.
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
I call meme misuse.
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
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
Parent
How is X better than Y? (Score:4, Informative)
How is that better than doing (or basically the same in Java/C/perl/ruby/etc.):
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...
Parent
Re:Mmmm, Kay. (Score:4, Insightful)
Functors and generators will do the same thing for you in a more mainstream languages like C++ and Python. And they'll be a hell of a lot more understandable to your average still-wet-behind-the-ears programmer. And you can certainly write code in those languages to do lazy evaluation.
Now, I will grant you that, in general, one can do it more concisely in Haskell than one could in C++ and even Python. But these languages are more well rounded, IMO, than Haskell.
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
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 ?
Parent
Re:Mmmm, Kay. (Score:4, Insightful)
Except you hope that Haskell automatically memoizes the results
Please don't take this the wrong way, but please stop spreading your misinformation. One doesn't hope Haskell memoizes because it doesn't memoize functions. One requires that Haskell implement call-by-need. Overlapping but very different concepts. I'll assume it was an honest mistake but the difference makes the rest of your post nonsense.
Haskell is only being used by people that crunch numbers
Another point of dissagrement. If anything number crunchers (e.g. scientific computing in which I've done a fair bit of work) avoid Haskell (along with anything that is not Fortran, Matlab or C). Haskell finds favor more among "programing language" types who are interesting in writing their own language (Haskell is a phenominal language to wrong another language in) or in "elegant" ways to write compact solutions to traditionally verbose problems (e.g. merge sort in two "statements").
Parent
Re:Mmmm, Kay. (Score:4, Insightful)
paraphrase comment #1: Haskell is too academic to be useful.
paraphrase comment #2: No it isn't, here's how to do something with a fibbonacci sequence.
Uh, you failed at "fibbonacci" to make your point. :)
Parent
Re:Mmmm, Kay. (Score:5, Interesting)
Depends on how you determine "easy to read". The main difference between Haskel and say C is that Haskel is very dense while C is not so much, so one line of Haskel holds a lot more information then C, which of course makes look like its Haskel harder to read, since understanding a line of code requires effort, while its trivial in C. However that line of Haskel might contain the same information as a whole function in C and reading that whole function in C might turn out harder then comprehending that single line of Haskel.
All that said, I don't consider the syntax of Haskel very good, lack of parenthesis around function arguments certainly doesn't help readability and the error messages can be rather obscure as well.
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
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.
Parent
Re:Mmmm, Kay. (Score:5, Interesting)
I've seen quite a few Haskell jobs advertised recently actually, I even got one of them :).
Parent
Re:Mmmm, Kay. (Score:5, Interesting)
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:
I'd be interested to see if you could mirror the functionality in one of the 'popular' languages you mentioned. Perhaps something in Java?
Parent
Re:Mmmm, Kay. (Score:5, Insightful)
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.
Parent
Re:Mmmm, Kay. (Score:4, Insightful)
No. It's not because of a huge lib. It's because code can be so much more generic than in other languages. And that's the biggest point/plus in Haskell. You don't have to write a new for loop for everything. Even the for loop is abstracted (map, fold, zipWith, ...). And this works with everything. I have yet to find something that's not generalizable in Haskell,
Your 4GL claim turns out to either be true for all languages with a compiler or
the Haskell compiler is just an abstraction you do *once* instead of reinventing it every time and using it in a crude and ugly way, like in C or similar languages,
Your real problem with Haskell is that it is more complex per written token, and so you have to think more per token. Most people seem to generate some inner fear for things they don't understand as good as they expect. And that's the base of all your motivation to find reasons why you dislike Haskell.
Of course you could simplify it, and get something like Python. But this is a bad idea on the long run, because then nature will only create bigger idiots. It's better to wise up a bit, because what you get then, is really really nice!
P.S.: I once tried to design the "perfect language". I stopped as soon as I learned Haskell, because it was not only extremely similar to what I had created myself, but even much better.
Parent
Re:Mmmm, Kay. (Score:5, Funny)
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 [haskell.org] written in Haskell already. Where does C fit in to that?
After the 'l' and before the 'o'.
Parent
Too constrained and academic (Score:5, Insightful)
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 (Score:5, Interesting)
A separate, but related problem is that the community doesn't seem interested in practical use of it
Really? That's why there's a new book called Real World Haskell [realworldhaskell.org]. The IRC channel on freenode is one of the largest on the entire network, and full of people doing real world things with haskell.
there aren't lots of bindings to libraries to make easy things easy.
I call FUD. The Hackage database [haskell.org]has literally hundreds of libraries sat there ready for you to use. And if you really need something that isn't there, the FFI is mature, and very easy to use.
Parent
Re:Too constrained and academic (Score:4, Insightful)
Parent
visibility of hackage (Score:4, Insightful)
Hackage is well known to haskell programmers. It is linked to directly from the front page of haskell.org, it is mentioned frequently on the haskell-cafe mailing list, and that's where hundreds of haskell projects [haskell.org] are hosted. If you're an average passer-by and not an active haskell developer, it's not necessarily going to jump out and say "boo!", but it isn't hiding under a rock, either.
Note: hackage is not the standard libraries. Those are documented elsewhere [haskell.org].
Parent
Re:Too constrained and academic (Score:5, Interesting)
You also need to be able to interface.
Which is exactly why I find Scala [scala-lang.org] to be interesting. Note: I haven't had time to learn or use it yet, but the design concept there is very interesting.
Parent
Re:Too constrained and academic (Score:5, Interesting)
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.
Parent
Re: (Score:3, Interesting)
Has a lot of lazy evaluation stuff in libraries.
Has modifiable syntax/grammar.
Very efficient - number 2 after "C".
Re:Too constrained and academic (Score:5, Interesting)
No, I mean it is a true, honest to God, functional language. If you check Wikipedia, for example, you will see it listed as "Multi-paradigm: prototype-based, functional, imperative, scripting".
See, most people look at the C-style syntax and think it means that Javascript is a C-style language. Then they get frustrated when the C-stlye code they write looks like crap. Instead, they should be coding with closures and lambda, much like they would with a LISP program. The result is a far more sophisticated program that performs more work with greater elegance than a C-style equivalent.
I highly recommend Douglas Crockford's "The JavaScript Programming Language" [yahoo.com] introduction to the language if you're not familiar with Javascript's functional aspect.
Parent
Re: (Score:3, Informative)
What would you describe as "Functional" then? i.e. What is the key difference between a Functional language and a language that has "Functional Aspects"? Show me the difference you believe is there and I'll show you the Javascript goods.
Oh, and BTW? Academia agrees with me that Javascript is a functional language.
Re:Too constrained and academic (Score:5, Interesting)
So, if you can show me that you can't have mutable variables in Javascript, we can call it functional.
Parent
Re:Too constrained and academic (Score:4, Interesting)
An excellent post, sir. Much more on target than cylence's attempts.
This is correct. However, I did not claim that Javascript is a *pure* functional language, only that it is a functional language. If we go by the definition of a pure functional language, then we must discount a long list of functional languages as well. That includes the poster-child for functional programming: LISP
Javascript allows for pure functional programming just like any other functional language. However, it does not enforce the purity of functional code. Something that is a very difficult goal to reach. This combined with the C-Style of the language has the negative effect of encouraging imperative programming. With suitably predictable results. (How many times have we heard, "Javascript sucks!")
This is why I often refer to Javascript as a "LISP-style functional language". The two don't line up exactly, but the foundations of Functional List Processing are present in both.
An interesting aspect of the language's real-world use is that the designers of Javascript's web APIs could have created APIs that force imperative thinking. Yet they didn't. Even for traditionally imperative operations (e.g. networking), the designers of Javascript's web APIs have seen fit to ensure its functional nature through the use of an event system. e.g. I do not read values from XMLHttpRequest, I wait for a functional call.
I personally think it's fascinating that the functional underpinnings of the language have been so well preserved despite the lack of general knowledge about the language. The efforts they are putting into the language will pave the way for more mainstream functional languages in the future.
Parent
Re:Too constrained and academic (Score:4, Informative)
There's a more in-depth article on Javascript's functional capabilities here:
http://www.hunlock.com/blogs/Functional_Javascript [hunlock.com]
Other stuff I pulled out of Google for your perusing:
http://dankogai.typepad.com/blog/2006/03/lambda_calculus.html [typepad.com]
http://math.ucr.edu/~mike/lc2js.html [ucr.edu]
http://www.joelonsoftware.com/items/2006/08/01.html [joelonsoftware.com]
http://www.ibm.com/developerworks/java/library/wa-javascript.html [ibm.com]
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.
Parent
Why they don't rule: (Score:5, Funny)
Re:Why they don't rule: (Score:5, Informative)
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 [microsoft.co.il], so I decided to post instead. Anyone else want to mod parent funny?
Parent
Re:Why they don't rule: (Score:5, Funny)
Anyone else want to mod parent funny?
Yes, I will!
Oh crap.
Parent
It's not for dumb people (Score:5, Insightful)
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 :(
Re:It's not for dumb people (Score:5, Funny)
Don't worry.
In a few years you will see c++++ which will be c++ with functional programing tacked on. Of course you will also see Functional Object C but only Apple will use that.
Parent
Re:It's not for dumb people (Score:4, Interesting)
People will get more intelligent just by using functional languages.
Don't be ridiculous. Functional vs procedural isn't a matter of intelligence. It's simply a way of thinking. And the reality is that procedural languages better match the way the human mind works.
IMHO, learning to program in a functional style is like a right-handed person learning to write with their left. Yeah, they can do it, but it requires a ton of work for dubious real-world benefit, and in the end, it's never really natural, simply because that's not the way the brain is wired (except for the odd freakish exception ;).
Parent
one of the best practices (Score:3, Interesting)
We can see this philosophy in C where, except where huge data structures are involved, it is best to make a copy of data rather than work to work on someone else's copy. Likewise functions do one thing, do it well, and, again except for huge data structures, return a copy. Memory is manually allocated, and deallocated, possibly from the functions local heap.
It is interesting to me how it all comes back to just best practices. Make sure you know how much memory you need. Make sure you are only doing what needs to be done right now. Make sure the interfaces are clear. If data is ready, then it should be ok to work on it. To me functional programming is what happens after data models, or objects, are defined. Once the data structure is defined, you can treat it as stateless immutable input. Output is a another structure. Again, the only limitation is if the object is so large that duplicating become a cost performance issue.
Lazy Functional vs Lisp? (Score:3)
What's the difference between a functional language like Lisp and a lazy functional language?
Just asking.
Re: (Score:3, Interesting)
Lazy evaluation means that a value won't be calculated until it is absolutely necessary. So in the example in the above discussion, you can make things like an array of all the Fibonacci numbers. This works because the environment won't actually calculate anything until it is necessary.
Lisp doesn't support this behavior by default. In LISP all function arguments are evaluated left to right. Although using macros, you could probably write your own lazy evaluation mechanism.
Re:Lazy Functional vs Lisp? (Score:4, Interesting)
In a lazy language (more properly called "call-by-need"), every expression has a thunk wrapped around it and thunks are automatically forced. (They have thunks in Lisp/Scheme but they must be explicit rather than implicit.)
Lazy languages allow you to "use" values that haven't been defined yet. For example
a = 1 : b
b = 2 : a
Which would produce two lists of alternating ones and twos (a starts with 1 and b starts with 2; also ":" is infix "cons").
In Scheme (which I know better than Lisp), you could accomplish the same with
(let ( [a (cons 1 #f)]
...)
[b (cons 2 #f)])
(set-cdr! a b)
(set-cdr! b a)
But being lazy (1) frees you from thinking about order of evaluation and (2) allows some constructs to be expressed more easily (e.g. taking the fixed point of a composition of functions (example to complicated to post here)).
At the end of the day, any program written in one style can be written in the other so its all differences of ease and different ways of thinking about the program.
Parent
Oh my god! (Score:4, Funny)
Combinatorial Parsers, etc. (Score:3, Interesting)
One thing in Haskell that always intrigued me was the idea of combinatorial parsers - a parser that accepts a string and yields not a single parse tree, but all possible parse trees based on the language rules... Simple implementations of those can be implemented in Haskell pretty straightforwardly. Combinatorial parsers for individual rules are stuck together - and while rules may generate a bunch of possible parse trees these are culled by successive rules...
I don't know too much about the practical efficiency of these - but in terms of how they're expressed I think they're great...
Re:Why "lazy"? (Score:5, Informative)
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.
Parent