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

81–90 of 125 posts

Re: Haskell Is Exceptionally Unsafe (2012)

#81

Post by tome »

tel wrote: post #71
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…

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

Likewise, mostly because it would probably help me understand what CBPV actually is!

Re: Haskell Is Exceptionally Unsafe (2012)

#82

Post by Lambdanaut »

accessright wrote: post #27

So basically it is "unsafePerformIO" and "error" that is the problem? So if you do not use them (which I never do and it is recommended not to) then the problem is not relevant?

It seems to me that it would also be any function you import that uses these. Unfortunately, there are a lot of very commonly used functions that use `error`.

Re: Haskell Is Exceptionally Unsafe (2012)

#83

Post by zak_mc_kracken »

jmillikin wrote: post #58
progman wrote: post #46

Earlier quoted context omitted.

You have misunderstood me. I know cabal - with and without sandbox. I said am amazed that sandboxes or nix tools are necessary in Haskell _at all_ while every other language which uses a package manager has one that works out of the box without any hassle and without any sandbox tricks. > Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment. Other Haskell de…

> every other language which uses a package manager has > one that works out of the box without any hassle and > without any sandbox tricks. I have programmed professionally with C, C++, Go, Haskell, Java, Javascript, Python, and Ruby. While this is not "every other language", I feel it's a sufficient cross-section to be useful for the purposes of this thread. Trying to do any sort of open-source development without…

> What do you do here?

Pick a language where developers are not so cavalier with backward compatibility?

Java has Maven which allows you to exclude transitive dependencies for such situations, and in more than a decade of developing with the language, I've only had to use this functionality a handful of times.

Developers sometimes mess up and break backward compatibility but this should be an extremely rare event. That or the compiler itself is terribly implemented and creating incompatible binaries just by bumping up versions (looking at you Scala).

Re: Haskell Is Exceptionally Unsafe (2012)

#84

Post by mercurial »

wyager wrote: post #73
mercurial wrote: post #26

Earlier quoted context omitted.

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

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

Re: Haskell Is Exceptionally Unsafe (2012)

#85

Post by mercurial »

tel wrote: post #53
mercurial wrote: post #24

Earlier quoted context omitted.

I wouldn't say full-blown theorem provers (Coq, Agda) are really in the same category as Idris, which is supposed to be more practical.

Why not? I'd say that Agda/Idris/Coq are substantially the same languages with variation arising only in the kind of styles of coding they emphasize.

But isn't this a variant on the old "but it's Turing-complete, therefore you can do anything" fallacy? Sure, their type system may be similar, but the question is, which one will let you write, say, a robust, maintainable HTTP client with the least amount of pain?

Re: Haskell Is Exceptionally Unsafe (2012)

#86

Post by wyager »

mercurial wrote: post #84
wyager wrote: post #73

Earlier quoted context omitted.

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

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

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

Re: Haskell Is Exceptionally Unsafe (2012)

#87

Post by progman »

ZenoArrow wrote: post #66
progman wrote: post #48

Earlier quoted context omitted.

I wonder if Ocaml is actually much more practical than Haskell. Ocaml has been proven to be well usable in industry while Haskell seems to be suitable for research areas like math and language design. http://mirror.ocamlcore.org/wiki.cocan.org/companies.html http://www.infoq.com/presentations/jane-street-caml-ocaml http://queue.acm.org/detail.cfm?id=2038036&ref=fullrss

I'm learning F# right now, it's flipping excellent! From what I understand it's similar to Ocaml, but has some other features that give it the edge (for me at least). I did try to learn Ocaml at one point, but I was put off by the standard library variation (the default one apparently has numerous shortcomings, Batteries project extends it and Core project aims to replace it, but neither one is the clear winner) and…

Thanks a lot for these infos! Unfortunately F# is .NET only. Linux requires Mono for installation which means a lot of dependencies. I prefer small efficient solutions (Nimrod for instance). OCaml works out of the box on my system.

Re: Haskell Is Exceptionally Unsafe (2012)

#88

Post by zmanian »

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…

The best argument for John's thesis is the proliferation of ML derivatives in industry: Swift, Rust and Facebook's Hack. I'm really looking to Facebook's Flow which adds an ML style type system to Javascript.

Re: Haskell Is Exceptionally Unsafe (2012)

#89

Post by imanaccount247 »

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.

The problem is that your supposition is just made up. There's nothing to support it. Saying "suppose some thing that isn't true" does not support an argument about reality.

Re: Haskell Is Exceptionally Unsafe (2012)

#90

Post by imanaccount247 »

progman wrote: post #48
CmonDev wrote: post #31

Earlier quoted context omitted.

"the next great thing will be more like ML" ocaML or even better F#?

I wonder if Ocaml is actually much more practical than Haskell. Ocaml has been proven to be well usable in industry while Haskell seems to be suitable for research areas like math and language design. http://mirror.ocamlcore.org/wiki.cocan.org/companies.html http://www.infoq.com/presentations/jane-street-caml-ocaml http://queue.acm.org/detail.cfm?id=2038036&ref=fullrss

No, that's the weird mythology that gets passed around by people who haven't used both languages. I used ocaml for 4 years and switched to haskell precisely because it is more practical.
Post reply on HN