[wyager]

>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.

[rspeer]

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.

[wyager]

The fact that people should use good coding style is "more or less objectively true". I'm surprised that is the part you take issue with.

How is this dismissal overly simplified? What have I failed to take into account?

[mercurial]

> 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.

Good for you, I guess. You'll find plenty of libraries which have no qualms about using exceptions in the real world, though. Not to mention asynchronous exceptions, obviously. Personally, I find both exceptions and type-safe error handling unsatisfactory. The former is unsafe, the latter results usually in a "god error type" which breaks modularity.

[wyager]

>plenty of libraries which have no qualms about using exceptions in the real world

I haven't run into too many (particularly when compared to the popularity of exceptions in other languages).

>the latter results usually in a "god error type" which breaks modularity.

Have you tried using Either with a sum error type and/or an error typeclass?

[mercurial]

> I haven't run into too many (particularly when compared to the popularity of exceptions in other languages).

This doesn't mean much if you take a language like Java where it is the idiomatic way of handling errors. But take something vaguely complex like http-client (formerly http-conduit) and you get exceptions.

> Have you tried using Either with a sum error type and/or an error typeclass?

Well, even with sum types you get "god errors" which encapsulate all kinds of issues that can happen in your exception, because it's the path of least resistance. I haven't tried Either with a typeclass, though, but it sounds vaguely abusive.

[wyager]

>Well, even with sum types you get "god errors" which encapsulate all kinds of issues that can happen in your exception,

What's the alternative? Failing to encapsulate all kinds of issues that can happen?

[mercurial]

Well, what I'd really want is something more flexible, where you can use inheritance (errors are one of the few areas where inheritance is actually useful - this lets you say that "FileNotFoundError" is a kind of "IOError", add "DimensionGateConnectionError" in the same hierarchy without tweaking any code, and test if the the IOError you got is because you didn't manage to open the dimensional gate. And on top of this, I'd also like this to compose without problems, I'm not interested in creating IOOrFormatError because there is a function which may throw IOError or FormatError. It's a problem that sum types really don't tackle well. As for type classes, it's also not ideal. You can't capture all the necessary information in the interface you expose (IOError doesn't need a filePath field, but FileNotFoundError, which is a kind of IOError does).