Exactly. Many people do not know how hard it is to improve on the current prelude, even though it's entirely possible. Most decisions and tradeoffs in Haskell weren't just done on a whim, there is an ideology and reasoning behind it (I am not sure if I want a maybe monad as a possible result of my list operations, though). My first thought when I read that headline was "Wow, good luck with that."

I do not know Stephen Diehl but I hope you're right about his capabilities, it would definitely be exciting to see that in Haskell!

To my understanding Haskell prelude is unsafe because Haskell sometime sacrifices usability/friendliness for satisfying certain theorems.

http://stackoverflow.com/questions/6364409/why-does-haskells...

Satisfying theorems is generally for the purpose of friendliness, by ensuring consistency. In this case, they had two options:

(a) be consistent as if the language had type-level literals, which resulted in nicer code in the usual case, but some unsafety on unchecked edge cases, or

(b) give more safety, but force everyone to check for the empty list even when they don't need to.

They went with (a) - it's the type of decision Haskell is (I'd argue incorrectly) criticized for not doing - people complain about having to prove things to their compiler. Of course, in hindsight, and given the language ecosystem now (and that option (b) is instead consistent with all the monad-centric libraries, etc.), (b) seems like a better choice. Which one is better could just as easily change again if empty lists became distinguished at the type-level in Prelude in the future. This is also something that would either crash, or be similarly inconsistent (just return null, causing eventual crashes instead) in any other language. It's notable, though, that the community is making effort to fix these tiny inconsistencies, rather than punting on it for backwards compatibility, as so many other ecosystems do.

Partly. Tsuyoshi Ito's answer on that page is IMO better than the original: `head` mattered at a time when pattern matching didn't exist; but today the only reason to use `head` is to form some sort of pointfree expression operating on lists that you've already filtered to be not-null. That is, you're doing `map (transform . head) . takeWhile (not . null)` or something, or maybe `takeWhile` is replaced with `filter` or so. If you cannot assert that the list is non-null then you have to handle two branches, and this code will generally look clearer if you pull it into a `where` clause and write it with pattern matching rather than with an adjusted `head` followed immediately by an appropriate `maybe` function.

With `[a] -> Maybe a`, it's not so bad if you use `catMaybes` from Data.Maybe.

map transform . catMaybes . map safeHead

Even better with mapMaybe:

    map transform . mapMaybe safeHead

In other words, it's this way because people want to emulate an unfriendly language, used on another domain where terseness is even more important than in Haskell code.

That does not make it a good choice. Just a kind of default, but it's a bad default.

isn't that just saying that 'head' shouldn't return [] on an empty list, because [] has a type which is never the type of what 'head' should return? that's separate from why 'head's type isn't [a] -> Maybe a.

I have found Haskell just has so many of these "paper cuts" that I have just walked away.

I agree, but I've fallen in love with Purescript[0] recently instead, and its made it easier to ease into Haskell. Although to be honest, I prefer Purescript as a language!

[0] http://www.purescript.org/

I could see that. I find that Haskell specifically is very hard to ease into, whereas a lot of similar languages are much easier. For me, I wasn't comfortable with my Haskell skills until I learned Idris, which is arguably a more difficult language -- ironically, I found the Idris documentation to be a lot more user friendly than Haskell's just because it comes from the official team (and I'm sure that Purescript is like this too). For anyone struggling to learn Haskell, I'd probably recommend a different purely functional language first (at least until haskellbook comes out).

That's because PureScript is what Haskell would be if it were written in the last 2-3 years starting from a clean slate. It doesn't have to deal with legacy code.

That's really a sad thing to hear, because for the experienced the benefits brought about by Haskell is so plainly obvious that it's obviously worth the trouble to navigate the mine of the Prelude full of legacy cruft.

My #1 issue was I work at several sites and at home. I don't really use a laptop so I just use git as a single user. The package management was such that I could never have the same environment in multiple of locations. Something would break and I spent more time fixing then doing.

That was a problem commonly called 'cabal hell'. You can alternatively use the stack build tool, https://github.com/commercialhaskell/stack, which works by fixing package versions against stackage snapshots.

Before using stack I was always afraid to come back to a Haskell project after a few months, since using stack that's not a problem. Also, you don't have to worry about different machines, because stack is ensuring that you have the pretty much same build environment (at least the Haskell packages will have the exact same version).

Stack also recently added support for using Nix to solve the problem fixing non-Haskell dependencies for a project.

Well after the love affair I have with Racket wears off I just might try to start back up in Haskell. Thanks! Love the idea of using nix.

This looks so much better than Cabal.

Why have I never heard about it in all the guides and StackOverflow answers I've had to search through when trying to escape Cabal hell?

The project has existed only since last summer.

mcbuilder has already mentioned it, but I really want to emphasize that dependency management in Haskell is an entirely different story now with stack.