Johan Tibell

You can somewhat switch Haskell to being strict-by-default with the new Strict/StrictData pragma[0], which should be in GHC 8.0. There's also a great write-up of it here [1]. As someone else mentioned, Backpack is trying to "fix" the module system in Haskell[2], which should be interesting. That said, I don't have much of a problem with it, but then again I haven't seen the light of the OCaml way yet :) [0] https://ghc.haskell.org/trac/ghc/wiki/StrictPragma [1] http://blog.johantibell.com/2015/11/the-design-of-strict-haskell-pragm… [2] http://plv.mpi-sws.org/backpack/

There was recently a survey on the State of Haskell in 2011 [1]. As many people here seem to be echoing, OCaml was the main possible "replacement language". Also included in the survey are ratings of various aspects of Hackage and also Haskell libraries in general. It was a really interesting read. I made a follow-up post [2] that analyzed the free-form responses to the last question, "What do you think is Haskell's most glaring weakness / blind spot / problem?". Number one by far was libraries (spread across: quality + quantity, library documentation, Hackage, cabal). There are a lot of people working on this though, and progress is being made. The runners up were 'Tools', and 'Barrier To Entry'. I think Haskell, at the very least, is a fantastic way to learn some different ways of thinking and good habits. The (little so far) coding in it I've done has been very enjoyable for me, but I don't expect everyone to feel the same way. It has a very warm community, and a fair bit of momentum. As time goes on I predict (and hope) it will become more viable for a greater number of people to use. [1] - http://blog.johantibell.com/2011/08/results-from-state-of-haskell-2011… [2] - http://nickknowlson.com/blog/2011/09/12/haskell-survey-categorized-wea…

One thing worth noting here is that the article dates from 2009; things have improved a lot since then vis a vis web development in Haskell. New frameworks (Snap, Yesod) have sprung up, and the library and toolchain support have improved immeasurably. To answer some of your questions a little more directly (I hope someone like dons with a more encyclopaedic knowledge can pitch in here): * As a language, Haskell is both very stable and very cutting-edge. This is because GHC (the only Haskell compiler people use seriously for production, at least as far as I'm aware) supports both the Haskell '98 standard, and the more recent Haskell 2010 standard—but it also supports a large number of language extensions [1] such as type families, existential types, GADTs etc. So * In terms of scalability, some of the recent benchmarks for Haskell-based web servers have been very impressive. Whether or not this translates into real-world performance is something we'll see as more people start using them in production. Recent improvements to the GHC I/O manager make the case for Haskell more compelling in this regard than it used to be. * It's pretty easy in Haskell to write wrappers around C libraries, such as OpenSSL. There are also moves to implement more of these core parts of any web stack in pure Haskell, although getting them to feature-completion is a process that will take time. A couple of recent reads spring to mind: a Stack Overflow discussion [1] where Alex Payne asked about…

Currently you can deal with strictness using Bang Patterns. The addition of Strict and StrictData with -XStrict simply lets module writers cut down on that noise and communicates intent. It isn't meant to change or split the language Haskell in two; except for testing, you probably wouldn't go enabling it everywhere just 'cause. More info on strictness and Bang Patterns: https://wiki.haskell.org/Performance/Strictness#Explicit_strictness This was posted to r/haskell today and helps explain things a bit: http://blog.johantibell.com/2015/11/the-design-of-strict-haskell-pragm…

For the record, many haskellers agree with you that the quality of many libraries and their documentation isn't good enough: http://blog.johantibell.com/2011/08/results-from-state-of-haskell-2011… Still, Haskell is largely a volunteer effort. Things won't magically improve just because enough people complain about it.

It's an interesting charge. Here’s my personal experience with the two cited resources, back when I was learning Haskell. YMMV. RWH’s “Here’s how you get the job done” style exposition did a reasonably good job of making me feel comfortable turning on profiling of my Haskell programs, but didn’t give me much sense at all of why the particular examples they chose were particularly representative of space leaks. I went on to do some amount of performance tuning of some data structures http://blog.ezyang.com/2010/03/the-case-of-the-hash-array-mapped-trie/ ... but I still managed to miss some really obvious performance bugs that Tibell caught later when he revamped my benchmarks http://blog.johantibell.com/2011/03/video-of-my-hashing-based-containe… . I just didn’t know where to look! All I had were a bunch of patterns: "watch out for lazy folds", "using bang patterns can be a good thing", without any particular mental model of how to deduce these things from just looking at code. To be honest about the Wikibooks article... I found it hard to read. (Which is terrible, since it's a wiki, and if I don't like it, I should improve the article...) Exactly why is hard to pinpoint. It might be statements like "Haskell values are highly layered"; it might be the fact that none of the examples are in motion (they don’t show before-and-after; the actual operation of the program!); it might be that in many respects, its coverage is incomplete. Obviously, this series isn’t going to…