Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell Is Exceptionally Unsafe (2012)

existentialtype.wordpress.com

Post reply on HN
Print view View original

71–80 of 125 posts

Re: Haskell Is Exceptionally Unsafe (2012)

#71

Post by tel »

jonsterling wrote: post #68
bronxbomber92 wrote: post #16

Earlier quoted context omitted.

Could you expand on why you think the next "great thing" will be more like ML than like Haskell?

1. Call-by-value gives us both the ability reason by induction. It also typically results in the presence of non-pointed types, whereas Haskell only has pointed types. 2. Call-by-value gives us the ability to safely interleave effects. Now, I know you all think we should not be doing that at all, but I would say that this is only true in some cases. The point of reifying an effect in a monad is not because "effects a…

I would love to see a "practical" CBPV language.

Re: Haskell Is Exceptionally Unsafe (2012)

#72

Post by wyager »

rspeer wrote: post #20
wyager wrote: post #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 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 down…

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?

Re: Haskell Is Exceptionally Unsafe (2012)

#73

Post by wyager »

mercurial wrote: post #26
wyager wrote: post #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 w…

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

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

Re: Haskell Is Exceptionally Unsafe (2012)

#74

Post by Dewie »

millstone wrote: post #37
imanaccount247 wrote: post #23

Earlier quoted context omitted.

>I want to question the importance of soundness in type systems Why? The most common and popular opinion is already that it is not important. >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. That doesn't make sense. Tha…

Suppose we insisted in math that all proofs be computer-checkable. There would be no erroneous proofs, but there would also be many correct proofs that could not be accepted or even formulated. Mathematics would suffer overall. Compiler enforced static typing rejects many correct programs, which is a disadvantage.

> Compiler enforced static typing rejects many correct programs,

Do you have any examples of programs that would be actually useful? I don't necessarily doubt that they exist, but it's not an interesting point if the argument is basically "they exist, but I don't know of anyone in particular".

Re: Haskell Is Exceptionally Unsafe (2012)

#75

Post by jonsterling »

tel wrote: post #70
jonsterling wrote: post #68

Earlier quoted context omitted.

1. Call-by-value gives us both the ability reason by induction. It also typically results in the presence of non-pointed types, whereas Haskell only has pointed types. 2. Call-by-value gives us the ability to safely interleave effects. Now, I know you all think we should not be doing that at all, but I would say that this is only true in some cases. The point of reifying an effect in a monad is not because "effects a…

Could you expand on effects which preserve extensionality some more? I'm fairly sure I understand it, but I've never quite follows what Harper's "benign effects" meant in detail and I'd like to see how it all connects.

The most benign effect of them all is laziness. Haskell uses this in lieu of all other effects, basically.

So memoizing data structures, or a higher order function for memoizing, utilizes a "benign effect".

Re: Haskell Is Exceptionally Unsafe (2012)

#76

Post by dragonwriter »

millstone wrote: post #37
imanaccount247 wrote: post #23

Earlier quoted context omitted.

>I want to question the importance of soundness in type systems Why? The most common and popular opinion is already that it is not important. >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. That doesn't make sense. Tha…

Suppose we insisted in math that all proofs be computer-checkable. There would be no erroneous proofs, but there would also be many correct proofs that could not be accepted or even formulated. Mathematics would suffer overall. Compiler enforced static typing rejects many correct programs, which is a disadvantage.

> Suppose we insisted in math that all proofs be computer-checkable. There would be no erroneous proofs, but there would also be many correct proofs that could not be accepted or even formulated.

Is that true? Is there a difference between the things which can be proven true in the sense used in mathematics and the set of things which are computable? The limits of proof (e.g., Goedel's incompleteness theorems) and computability (e.g., the halting problem) are at least deeply related, and I'm not at all convinced that your premise here is true.

Re: Haskell Is Exceptionally Unsafe (2012)

#77

Post by ufo »

lumpypua wrote: post #25
coolsunglasses wrote: post #15

Earlier quoted context omitted.

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.

Sick, thank you for the reply and pointer to uniplate and associated tools!

IIRC, the thing about Uniplate is that the API makes it easy to build traversal functions like "get a list of all X nodes in this tree" while SYB provides some folding operators that are a bit harder to work with.

Re: Haskell Is Exceptionally Unsafe (2012)

#78

Post by thirsteh »

tel wrote: post #52
thirsteh wrote: post #5

Earlier quoted context omitted.

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.

Perhaps there are some sour grapes, but I think more than that he's just hoping for more. Harper clearly has an executes on a grand vision for what PLs should be—he regularly states that there is only one PL and we're just working to slowly uncover it. Haskell fits it in some ways, and now those ways aren't worth talking about any further, and misses it in others. Harper, I believe, writes to galvanize people to move…

That makes sense. I wish he'd stop writing obviously linkbait titles like "Haskell is Exceptionally Unsafe" when what he means is that there are some really obscure safety implications for typeable exceptions. I completely agree with bjterry that it has probably caused more people to not look at Haskell to begin with, than people to look at ML.

Re: Haskell Is Exceptionally Unsafe (2012)

#79

Post by slashnull »

berdario wrote: post #39
jonsterling wrote: post #11

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 wi…

Since there aren't a lot of full time Haskell developers, I'm curious to know what do you use to setup your projects and handle dependencies: hsenv, cabal-dev, cabal sandboxes, nix, stackage ... or do you include everything in your repository (any tool to automate that)?

After a year or so of near constant dependency hell problems with Haskell, I stabilized all my setups on GHC7.8.3 and the associated Stackage inclusive, and it all... just... works...

I can finally go and write some relevant code now.

Re: Haskell Is Exceptionally Unsafe (2012)

#80

Post by ufo »

Dewie wrote: post #74
millstone wrote: post #37

Earlier quoted context omitted.

Suppose we insisted in math that all proofs be computer-checkable. There would be no erroneous proofs, but there would also be many correct proofs that could not be accepted or even formulated. Mathematics would suffer overall. Compiler enforced static typing rejects many correct programs, which is a disadvantage.

> Compiler enforced static typing rejects many correct programs, Do you have any examples of programs that would be actually useful? I don't necessarily doubt that they exist, but it's not an interesting point if the argument is basically "they exist, but I don't know of anyone in particular".

I think millstone is exaggerating a bit as most programs people write normally can be rewritten without too much pain in a static language with a rich type system. That said, there are some examples of times where your program asks for clever type system features (that are not always enabled by default or add to the learning curve) or where different type system features don't play nice together (so its hard to have both features in a single static language, but in a dynamic language you can use one style of programming at a time and never notice the problem).

In the first category, one example is programs requiring higher-rank polymorphism. They are always allowed in untyped languages but in Haskell this feature is hidden behind a language pragma to keep type inference simpler by default.

On the second category, an example I like is parametric polymorphism vs subtyping. The type system gets really tricky if you try to use both at the same time so most static languages either limit the polymorphism or don't allow subtyping. ON the other hand, in a dynamic language you can use both styles if you want, although you have to do so at your own risk.

Post reply on HN