Lennart Augustsson

Laziness (or, properly, non-strictness) enables a radically different style of programming, and combined with functional purity, also enables kinds of code transformation that are not valid in strict, effectful languages [1]. Almost any dynamic programming algorithm is trivial in Haskell, c.f. packrat parsing, which is embarrassingly easy to implement using a table of lazy values, and you can also trivially write control structures and infinite data structures [2].

The big problem is that reasoning about non-strict evaluation is quite non-intuitive (although not impossible.) It's quite easy to write code which seems inefficient that runs in no time at all, and equally easy to write code that seems efficient that takes a long time to run. It requires a rough understanding of how your compiler is optimizing your program and what the resulting code is doing, which can be tricky. Laziness also (not surprisingly) interacts with side-effects in a complicated way, so much work has been done to alleviate the problems with lazy IO, e.g. iteratees [3].

So, yes, sometimes it's a great thing, and sometimes it's a problem. The position of the Haskell community is that the exploration of how to properly leverage laziness is worth the tradeoff, but there is indeed a tradeoff.

[1]: http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html

[2]: Infinite data structures (i.e. codata) can be written/created in a strict language, but the ability to write them falls out of…

Haskell is great for DSLs. Some loose thoughts:

- The syntax is clean and extensible. (Function application is `f(x)` in C, `(f x)` in Lisp, and `f x` in Haskell.)

- The core language is small, with a suprising amount of functionality implemented as library functions. (Not surprising to a Lisp programmer, though.)

- You can define your own infix operators, specify their precedence, and their fixity. (Left, like most mathematical operators, or right, like the exponentiation operator).

- Because of Haskell's lazy evaluation, there is no distinction between special and non-special forms, so you don't need macros to build up syntactic sugar for your DSL. (Special forms, such as the C short-circuiting operators `&&` and `||`, only evaluate as much as is necessary, which is what Haskell does across the board.)

- But if you really want macros or quasi-quotation, they're part of the language. (Macros are named Template Haskell.)

- There is also built-in syntactic sugar which can be re-used for your own instances of common program patterns, such as monadic do-notation, monadic comprehensions, and arrows.

There are many examples of Haskell DSLs online. A particularly amusing one is Lennart Augustsson's embedding of BASIC in Haskell, proving beyond all doubt that Haskell is in fact an imperative language, and all this talk about purity is poppycock. [1] [2]

Haskell is also great for performance. GHC 7.8.2 is now ready to use, with the Mio high-performance multicore IO…

This is a great writeup, and I just want to offer a counterpoint regarding the eager vs. lazy trade-offs.

I found this article really helpful for explaining why laziness is important: http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html

In particular, scroll down to the "Reuse" section. Lazy evaluation enables you to compose functions to build new functions with the right performance characteristics (constant factors aside), as in:

any :: (a -> Bool) -> [a] -> Bool
any p = or . map p

In an eager language, predicate `p` would have to be evaluated on every element in the list, even if the predicate is already satisfied after the first element. So instead you'd have to write this function in an ad hoc way with explicit recursion/looping, without being able to reuse the more primitive functions.

Of course, in an impure language, laziness can't be the default because you wouldn't be able to reason about when your side effects occur. But in my mind that's an argument for purity rather than an argument for eagerness.

BTW, comparing "strict" vs. "lazy" is a category error. The proper comparison would be either "strict" vs. "non-strict" or "eager" vs. "lazy". The former is in reference to the denotational semantics, whereas the latter characterizes the operational semantics.

It doesn't seem that meaningful to compare a totally naive C implementation to an optimised Haskell one either. (Well, other than to show how fast C is even without any effort to optimise the code). Saying you have to keep the algorithm the same seems like a rather arbitrary limitation on the comparisons, especially since some algorithms are much less of a natural fit in some languages (see: quicksort in Haskell vs C [1]).

I would suggest it's best to show (at least) 4 versions of the code to compare two language: the naive implementation in both languages, and the really optimised version in both languages (plus intermediate levels of optimisation if you feel dedicated). That gives a picture of how fast the typical code one would write will be, as well as the potential for optimisation if you are experiencing bottlenecks, and how much effort it takes to optimise the code.

[1] http://augustss.blogspot.co.uk/2007/08/quicksort-in-haskell-quicksort-is.html

Facebook is also creating tools with Haskell:

https://github.com/facebook/Haxl

My 2 cents: definitely _also_ learn OCaml down the line. But:

- my pet peeve with OCaml is the lack of a builtin type for Unicode strings (the only other language still commonly used with this shortcoming is PHP), and this could be an issue if you plan to write some web app code that needs to be internationalized

- OCaml is strict, Haskell is one of the very few languages that is non-strict: aside from the didactic purpose of exposing yoursefl to something different, that's a feature that can help reasoning about what your code is doing:

http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-evaluation-in.html

(then again, there're obviously downsides to non-strictness, and you might decide down the line that you prefer to write strict code in production... but it's good to know the alternatives)

This is an interesting question. As much more of a Haskeller than an MLer I don't tend to feel the "need" to structure my programs explicitly modularly, and when I do I sort of instinctively use a combination of typeclasses and polymorphic higher-order functions to do so.

More basically, just think "everywhere I would open a module, instead I can take a parameterized record of functions" (and furthermore, if a datatype uniquely determines that record, I can associate a typeclass to that datatype). There are limitations to this, but in fewer circumstances than you'd think -- mainly about sort of cross-modularity (aka the expression problem).

There was a very nice discussion on lennart's blog about this in 2008, with a problem posed and some partial solutions (read bottom post to top):

http://augustss.blogspot.com/2008_12_01_archive.html