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
Really? That's why there's a new book called Real World Haskell. 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 databasehas 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.
You also need to be able to interface.
Which is exactly why I find Scala to be interesting. Note: I haven't had time to learn or use it yet, but the design concept there is very 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.
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.
And why not OCaml ? Nicely separated into both functional and imperative parts.
Has a lot of lazy evaluation stuff in libraries.
Has modifiable syntax/grammar.
Very efficient - number 2 after "C".
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" introduction to the language if you're not familiar with Javascript's functional aspect.
Javascript + Nintendo DSi = DSiCade
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.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
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 ;).
I've seen quite a few Haskell jobs advertised recently actually, I even got one of them :).
This is only true for specific implementations. The Haskell 98 report only specifies library support for textual input/output, and is completely useless for portably handling Binary IO. That everyone just uses GHC anyway, which has great support for Binary IO, doesn't negate the point that Haskell itself sucks when it comes to IO.
Other serious shortcomings would have to include lack of proper locale/encoding support (characters are read in as Unicode values; but what is the original encoding assumed to be, then? Current implementations do byte-for-byte, which also isn't great), and lack of serious exception-handling (though that is probably mitigated considerably by the Maybe monad in combination with "do").
Haskell is a gorgeous language, but it does have some serious shortcomings, at least when it comes to the official specification as opposed to popular implementations. GHC has done much in making it a truly useful language, and so most people mean GHC when they say "Haskell". Which is plenty portable enough, I guess, considering that it is capable of using GCC as the compiler backend.
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...
Bow-ties are cool.
If you don't know of it already, you might also wanna take a look at Clojure, a Lisp dialect that can either be interpreted or precompiled to .class files.
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?
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.
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.
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?
So, if you can show me that you can't have mutable variables in Javascript, we can call it functional.
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.
Javascript + Nintendo DSi = DSiCade
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.