Why Lazy Functional Programming Languages Rule 439
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.'"
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.
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: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.
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?
Re:Mmmm, Kay. (Score:5, Insightful)
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.
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?
Re:Mmmm, Kay. (Score:5, Insightful)
I call meme misuse.
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
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.
Re:Too constrained and academic (Score:4, Insightful)
Re:Too constrained and academic (Score:2, Insightful)
That a language has "functional aspects" doesn't make the language itself "functional". By the same reasoning you use, Python is a "functional language" too. Hell, even Perl has closures and lambda. And Python has list comprehensions and such. Pretty much every high-level language has these things; that doesn't make them functional.
Re:Too constrained and academic (Score:1, Insightful)
Can you do anything besides call FUD?!?!?
Seriously, every opinion the differs from yours is not FUD. Give the zealotry a rest, and try to have a conversation or dialogue.
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.
Re:It's not for dumb people (Score:2, Insightful)
Well, that C++0x thing or however its called has lambdas and functions closer to being a first class construct...so thats pretty much exactly whats happening already, give or take :)
Have you looked at the syntax? You're basically just binding functions together in template parameters, then invoking them. Normally, I'd be pleased as punch that it's being included but... DAMN is it ugly syntax.
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 ?
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.
Re:Mmmm, Kay. (Score:2, Insightful)
you lucky bastard.
Re:Why "lazy"? (Score:3, Insightful)
Well Haskell isn't "smart" in the sense that it goes out and arbitrarily caches things it thinks may be helpful (that way leads to madness).
It does cache computations it's made if you store them in a variable or part of a data structure, so if you plan things right, you can get the behaviour you want.
Basically, here's one advanced way of calculating fibs in Haskell:
(From Haskell for C Programmers [haskell.org]).
This takes a bit of thinking to work out, but basically it declares fibs as a list of ints, which is infinitely long, the first two elements are 0 and 1, and each subsequent element is the sum of the previous two.
But there's a catch - unlike C where declaring an infinite data structure would be absurd, Haskell stores it this way:
[0, 1, <some vague concept of the remaining computation>] - a finite data structure of in fact just three elements.
Now you request the 100th fibonacci number, like this: (fibs !! 99). Haskell doesn't know the value of elements 2 through 99, so it unrolls it, performing the computation as much as possible - that's the laziness. Now it stores:
[0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, ... , 218922995834555169026, <some vague concept of the remaining computation>]
And it returns you the value 218922995834555169026 which is the last *known* element of the list. Note however that the computed list so far remains.
Now you request the 200th fibonacci number, like this: (fibs !! 199). And Haskell figures it has to do some more computation, but it already knows the first 100. So it just unrolls the next 100 elements, and gives you the 200th fib. You could subsequently request (fibs !! 37) and it would look it up without recomputing.
Note that this is a bit of a bad example, as Haskell uses linked lists, the lookup itself is linear, which is the same as the computation time. But other more expensive computations could be done using this technique.
Also note that my definition is a lot smaller and closer to the mathematical definition [wikipedia.org] of Fibonacci sequence than your C code. Functional programming is (or at least tries to be) about defining what you want to compute, not how you want to compute it. Having said that, it does often mess with my head and I tend to use imperative languages for this reason ;)
Re:It's not for dumb people (Score:3, Insightful)
And the reality is that procedural languages better match the way the human mind works.
To quote you -- don't be ridiculous. From my personal experience of teaching people functional programming, it's nothing to do with imperative programming matching the brain better. Instead, it's to do with people learning to write imperative programs first, and then having a very steep unlearning curve to deal with at the same time as the learning curve for functional programming.
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.
Re:Mmmm, Kay. (Score:3, Insightful)
Yup, lazy, functionnal, imperative, object : for each problem there is a better solution. However maybe there would be at then end a language where :
1) syntax could be made a little less strange so that people knowing C (like python by example and then adding its own concepts) could make simple things, simply
2) different paradigms should be coexisting peacefully - fast, simple inner loops in C, structured, object in ($dynamic language), algorithms needing such kind of concurrency or metaprogramming, possible also.
3) a pony
Can't help you with #3. I've been thinking about solutions to #2 (Integration between languages is still a real weak point... I hope this will change over time - part of that will be increased cooperation between the tools themselves. Seems like Microsoft has taken a decent stab at this with .NET...)
I don't really agree with #1. I don't believe any language yet (especially not C++) has "the perfect syntax", so when it comes to defining new languages I don't believe emulation (of syntax) is necessarily the right approach. The damage done to the language as a result (syntax not matched to concepts, possible syntax innovation stifled) outweighs the benefits of familiarity. Anyway syntax has to serve the design of the language, not the other way around. Designing a language you choose priorities - what should be convenient, what should be conceptually emphasized, and try to optimize the syntax for that - and the rest winds up an inevitable compromise.
Personally I think Haskell syntax is great. I love the foundation in format math notation, and I think the syntax fits the language. The support for extensible infix is great, and I like how this scales down to the colon operator, which is like the fundamental infix operator version of "cons"... Haskell notions of constructors (particularly them being things that can be applied or pattern-matched and stripped from data) and pattern-matching function arguments in general are a bit alien to C++ anyway, even if you wanted to try to fit Haskell into a C++-ish syntax.
Re:Mmmm, Kay. (Score:3, Insightful)
we don't usually have wires with infinite bandwidth, disks capable of storing infinite frames of video, or users that can press infinite keys.
You completly missed the point. An infinite data structure in a lazy language isn't something that you write down to disk or something you store in memory, its a concept with which you structure your code. For example instead of having a while-loop to poll an event from an event queue like you would do in C, you could have an infinite list of all the events that you system would ever create, but it isn't a list/array in the C sense, its much more like a generator in Python in that the elements are only generated once requested, except that you can handle it like any other list in Haskel. Having a recursive function that walks over an infinite list in a lazy language really isn't much different then having an endless loop in C.
Re:It's not for dumb people (Score:3, Insightful)
I don't think there is any evidence that procedural languages are easier to understand; SQL, which (like functional languages) is declarative rather than procedural seems to be at least as simple as most programming languages for even neophytes to understand.
Procedural programming is probably easier to understand if you started out for years learning procedural languages, or if you come from a hardware-centric background; OTOH, if your first experience with computer programming is spending years exclusively with functional languages, or you come to programming with a background heavy in math and formal logic, functional programming is probably fairly easy.
quantification of productivity (Score:3, Insightful)
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. :)
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").
Re:It's not for dumb people (Score:3, Insightful)
There, fixed for you.
There's nothing natural in the "change-one-byte-at-a-time" von-Neumann bottleneck [stanford.edu] languages, other than they're the ones taught in standard programming courses.
Oh, you mean that the human mind keeps track for changes of state in the environment? Sorry to break the news to you, but that can also be done in functional languages. [wikipedia.org]
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].
Re:Mmmm, Kay. (Score:3, Insightful)
1. Start with a grid of data
2. Filter out empty rows
3. Group rows together that have identical values for the first column.
4. Make a tree branch from each route, using the value of the first column as the head of the branch, and use recursion to find the child branches from the remaining columns (i.e. every column but the first) of the grid.
So:
Becomes:
Re:It's not for dumb people (Score:3, Insightful)
As for an "instance of a normal, everyday situation in which humans use a functional model of computation":
SELECT Name, Age FROM My_country
WHERE Age > 18
GROUP BY Age
You'd be hard pressed to find someone thinking of the age groups in their country using a "for..next" model.