On Hiring Haskell People

This is an interesting read. One part jumped out at me (sorry for the long quote)

The purpose of the technical problem was to assess more directly candidates ability to write Haskell programs that can be used to solve real world problems, where memory usage and performance are important. The problem was all about evaluation order and memory behaviour. We started by asking candidates to look at a short program and say what shape they would expect the heap profile to be. That would then lead on to a discussion of what things are evaluated at what stage and how much memory they are taking in the meantime. For the final step we asked candidates to rewrite the program to run in constant space. We felt overall that the technical problem was quite useful and we allowed it to become a significant factor in our final decision making process.

The choice of problem is based on our belief that a good understanding of evaluation order is very important for writing practical Haskell programs. People learning Haskell often have the idea that evaluation order is not important because it does not affect the calculated result. It is no coincidence that beginners end up floundering around with space leaks that they do not understand.

I've written a lot of C++ and a fair amount of Haskell, and this kind reasoning about the evaluation order and space usage of Haskell a program is no less of a black art than pointer arithmetic or manual memory management in C++. In both cases, it's too steep of a learning curve to just be able to write practical programs, which is why garbage collected languages have displaced C++ in many domains.

It's particularly damning to say that "good understanding of evaluation order is very important for writing practical Haskell programs" because the easiest evaluation order to understand is strict evaluation order. In that sense, lazy evaluation is to strict evaluation as manual memory management is to garbage collection, except that the latter is supposed to be an improvement on the former.

This is why I think it makes sense to have research languages and production languages. The design constraints are totally different.

Anyone know of good resources to read about evaluation order in Haskell (so we can get better at it)?

"The next Haskell will be strict

-Simon Peyton Jones"

True, he does say that but the slides you reference show a more nuanced position than implied by that isolated quote.

Insisting on laziness forced the Haskell designers not to add side effects, eventually resulting in monads (slides 22 and 23), which ended up with Haskell programs having a "thin imperative shell over a fat pure core" internal structure. (slide 32).

SPJ then concludes that (1)purity is more important than laziness, (2)the next ML will be pure with effectful programming only via monads and (3) the next Haskell will be strict, but still pure (slides 39 , 40). (the differences between "the next ML" and the "next Haskell" are worth pondering)

It is through insisting on laziness as default and solving some of the problems encountered (via monads for e.g) that he arrived at the position that "the next Haskell will be strict". He also notes some open problems with adding laziness into a statically typed strict language (slide 40 "Still unclear exactly how to add laziness to a strict language. For example, do we want a type distinction between (say) a lazy Int and a strict Int?").

So yes, you are right that "The latest research fads in CS aren't always beneficial." but in this case it seems to have been (beneficial).

As someone maintaining a 20 k+ line Haskell codebase on my "day job" ("20,000 lines of Haskell is enough to bootstrap SkyNet" - OH on Twitter), I would appreciate a "strict-by-default-Haskell" (with an ML like module system too, while you are at it, thanks in advance!), but really Haskell is certainly more "beneficial" than any other language I've seen to date for certain types of programs .

Not contradicting your position,just qualifying it a bit.

I see one major difference: a Haskell program with optimization mistakes will run slowly and waste memory, its performance will improve as you fix them, and eventually you can stop because it's sufficient. A C++ program with any memory mistakes whatsoever will blow up randomly, and will continue doing so after you give up trying to make it perfect (which is hardly ever feasible) and ship unstable crap like the rest of the industry.