As others have said, it's not nearly as bad anymore as It was when Bob wrote that post, but I would say, please do not take that as a reason to not take what he says very seriously. I use haskell because it is a very practical tool, (bona fides: I am an experienced haskell developer and I actually use it full time for my job---not an armchair evangelist) but it has become very clear to me that the next great thing will be more like ML than like Haskell. There are of course many important lessons to be learned from Haskell though!
Haskell Is Exceptionally Unsafe (2012)
11–20 of 125 posts
Re: Haskell Is Exceptionally Unsafe (2012)
#12Harper's an accomplished person in CS and has done great work, but he's not putting a good argument forward here. I've talked to Harper about this post and his opposition to Haskell before. I mentioned that it was leading people to believe they could ignore typed FP, not redirecting to an ML derivative. Harper expressed dismay at this. There are more advanced languages than Haskell, they aren't ML, and PL researchers…
I'm curious what your objections to the value restriction? It's a tradeoff for allowing impurity, which is of debatable use (I like it), but it's not totally off the wall.
Re: Haskell Is Exceptionally Unsafe (2012)
#13Harper's an accomplished person in CS and has done great work, but he's not putting a good argument forward here. I've talked to Harper about this post and his opposition to Haskell before. I mentioned that it was leading people to believe they could ignore typed FP, not redirecting to an ML derivative. Harper expressed dismay at this. There are more advanced languages than Haskell, they aren't ML, and PL researchers…
As an intermediate Haskeller I'm curious, what's the replacement for SYB? I've worked in haskell primarily on compiler-like tree tranformation code and SYB seems to fit the bill perfectly.
There's http://www.haskell.org/haskellwiki/Template_Haskell, for one
Re: Haskell Is Exceptionally Unsafe (2012)
#14>The most blatant violation is the all too necessary, but aptly named, unsafePerformIO
The only time it's necessary is when you're using the FFI or working with language internals, at which point there's really no way for the type checker to work anyway.
One should avoid using exceptions in pure code. This is well established. Instead, use any of the many type-safe exception mechanisms, like Maybe or Either. Having written probably in the high thousands or low tens of thousands of LoC of Haskell, I've never once used a user-defined exception or undefined.
The point of this article seems to be "If your code breaks, it's no longer type safe.". I don't think this is news to anyone.
Re: Haskell Is Exceptionally Unsafe (2012)
#15Harper's an accomplished person in CS and has done great work, but he's not putting a good argument forward here. I've talked to Harper about this post and his opposition to Haskell before. I mentioned that it was leading people to believe they could ignore typed FP, not redirecting to an ML derivative. Harper expressed dismay at this. There are more advanced languages than Haskell, they aren't ML, and PL researchers…
As an intermediate Haskeller I'm curious, what's the replacement for SYB? I've worked in haskell primarily on compiler-like tree tranformation code and SYB seems to fit the bill perfectly.
The direct equivalent and replacement is GHC http://www.haskell.org/haskellwiki/Generics.
Edit: I just wanted to add that if you do compiler-like tree transformation code it behooves you to explore uniplate/multiplate/plated.
Re: Haskell Is Exceptionally Unsafe (2012)
#16As others have said, it's not nearly as bad anymore as It was when Bob wrote that post, but I would say, please do not take that as a reason to not take what he says very seriously. I use haskell because it is a very practical tool, (bona fides: I am an experienced haskell developer and I actually use it full time for my job---not an armchair evangelist) but it has become very clear to me that the next great thing wi…
Could you expand on why you think the next "great thing" will be more like ML than like Haskell?
Re: Haskell Is Exceptionally Unsafe (2012)
#17Harper's an accomplished person in CS and has done great work, but he's not putting a good argument forward here. I've talked to Harper about this post and his opposition to Haskell before. I mentioned that it was leading people to believe they could ignore typed FP, not redirecting to an ML derivative. Harper expressed dismay at this. There are more advanced languages than Haskell, they aren't ML, and PL researchers…
> Lets consider the rather remarkable backflips Standard ML and OCaml had to perform in order to make FP work with strictness and impurity.
What backflips are these?
Apart from the value restriction (which is a real albeit minor inconvenience; I find it about as annoying in practice as Haskell's monomorphism restriction, and each can be removed in principle, at the cost of making it harder to reason about the semantics/cost of using a variable), I'm honestly not sure what you have in mind.
On a tangent, I'm not sure when statically-enforced purity (as opposed to purity-by-default) and pervasive laziness (as opposed to laziness-as-a-tool) became culturally defining features of FP. The original FP language, Lisp (and even its "this FP stuff is great, let's have some more" cousin Scheme) is impure and strict. I'm grateful to Haskell for trying to answer the question "just how far can we push these purity and laziness ideas", but I don't think that complete purity or laziness are necessary features for FP. They're just tools in its toolbox. But then, I have always been inclined to pluralism.
Re: Haskell Is Exceptionally Unsafe (2012)
#18Harper's an accomplished person in CS and has done great work, but he's not putting a good argument forward here. I've talked to Harper about this post and his opposition to Haskell before. I mentioned that it was leading people to believe they could ignore typed FP, not redirecting to an ML derivative. Harper expressed dismay at this. There are more advanced languages than Haskell, they aren't ML, and PL researchers…
Having read numerous rants by Harper against Haskell, it really just seems like he's upset Haskell turned out to be the "popular" language. He is an accomplished computer scientist and a major contributor to Standard ML (i.e. understandably biased), but his Haskell rants read like (type-safe) schoolyard banter.
Usually Andreas Rossberger has written a good rebuttal in the comments.
Re: Haskell Is Exceptionally Unsafe (2012)
#19I want to question the importance of soundness in type systems. Suppose you could catch 99% of type-based errors instead of 100%, and in addition, use a compiler switch to see all the case statements where a class of a type is missing. The intended benefit of this system is that it accepts all correct programs. Correct meaning, the program runs and returns the correct answer.
Would such a language be viable? Or is it absolutely necessary to catch all possible type errors. In the past, tools like lint have been considered useful, although lint is not at all the kind of type system that I envision, namely a system that is in practice catching all the errors that ML catches -- it just doesn't (and cannot) guarantee it catches them.
The restrictive nature of static type systems today is legendary, but I wonder sometimes whether people realize how restrictive they are. If you can't make your idea work with functors or typeclasses, chances are good there's no way to get it to compile and you have to write functions in longhand.
Re: Haskell Is Exceptionally Unsafe (2012)
#20>The most blatant violation is the all too necessary, but aptly named, unsafePerformIO The only time it's necessary is when you're using the FFI or working with language internals, at which point there's really no way for the type checker to work anyway. One should avoid using exceptions in pure code. This is well established. Instead, use any of the many type-safe exception mechanisms, like Maybe or Either. Having w…
It's the kind of unhelpful, overly simplified dismissal that HN is known for.
You should recognize that your opinions about how people should use your favorite programming language are not "more or less objectively true".
Context: the post I'm replying to used to end with a complaint that people would downvote something that's "more or less objectively true", and a request that people should explain why. I can't downvote, but I can explain.