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

41–50 of 125 posts

Re: Haskell Is Exceptionally Unsafe (2012)

#41

Post by progman »

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

I would love to use Haskell as a practical tool (I honestly tried that) but the very fact that the Haskell community was not yet able to implement a simple practical thing like a convenient working package manager reveals that Haskell is not so practical after all. We need sandboxes, nix oder even a new OS (NixOS) just for the purpose of developing Haskell software? Come on!

Re: Haskell Is Exceptionally Unsafe (2012)

#42

Post by densh »

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?

I think the main problem here is that it's not just you, but also your transitive dependencies.

Re: Haskell Is Exceptionally Unsafe (2012)

#43

Post by pfh »

pjmlp wrote: post #22
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…

Haskell belongs to the ML language family.

and there is no such thing as a fish.

Re: Haskell Is Exceptionally Unsafe (2012)

#44

Post by marcosdumay »

progman wrote: post #41
berdario wrote: post #39

Earlier quoted context omitted.

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

I would love to use Haskell as a practical tool (I honestly tried that) but the very fact that the Haskell community was not yet able to implement a simple practical thing like a convenient working package manager reveals that Haskell is not so practical after all. We need sandboxes, nix oder even a new OS (NixOS) just for the purpose of developing Haskell software? Come on!

You got very misinformed.

Haskell is actually late to the sandbox party - up to recently you couldn't use them at all, and currently they are completely optional. But now that you can, it would be stupid to start a big project without them, like in any other language.

Haskell package manager is called Cabal. Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment.

Re: Haskell Is Exceptionally Unsafe (2012)

#45

Post by the_af »

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, which is a disadvantage.

In practice, however, it is only a theoretical disadvantage. The kind of "correct" programs that get rejected are not very useful.

Re: Haskell Is Exceptionally Unsafe (2012)

#46

Post by progman »

marcosdumay wrote: post #44
progman wrote: post #41

Earlier quoted context omitted.

I would love to use Haskell as a practical tool (I honestly tried that) but the very fact that the Haskell community was not yet able to implement a simple practical thing like a convenient working package manager reveals that Haskell is not so practical after all. We need sandboxes, nix oder even a new OS (NixOS) just for the purpose of developing Haskell software? Come on!

You got very misinformed. Haskell is actually late to the sandbox party - up to recently you couldn't use them at all, and currently they are completely optional. But now that you can, it would be stupid to start a big project without them, like in any other language. Haskell package manager is called Cabal. Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environme…

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 developers don't agree. They prefer nix even over cabal sandboxes. Quote: "Nix helps me avoid Cabal hell" and "Nix is much better than cabal sandbox".

https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-...

Re: Haskell Is Exceptionally Unsafe (2012)

#47

Post by michaelochurch »

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…

Where do you work? What has your experience been using Haskell "in the RealWorld"? I'd love to know more about this. My email address is michael.o.church at Google's email service.

I got seriously into Haskell a few months ago, but I've used ML in algorithmic trading and was a major fan.

I feel like it does us a disservice to complain about Haskell's (admittedly, warty) Exception system or "cabal hell" when what is actually going on is that we're holding the language to a higher standard. I agree that functions like head, fail, and possibly non-strict foldl, are warty; but these issues are downright minuscule when you consider what Haskell (language and community) brings to the table. (Also, every other language has warts.) The fact that our complaints about Haskell are minor annoyances compared to other languages' drawbacks, to me, signifies that the language got the major things right.

Re: Haskell Is Exceptionally Unsafe (2012)

#48

Post by progman »

CmonDev wrote: post #31
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…

"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

Re: Haskell Is Exceptionally Unsafe (2012)

#49

Post by tel »

tailrecursion wrote: post #19

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

This happens absolutely all the time.

For instance, Haskell does it in almost exactly these terms. If you have a type like

    data Drums = Ba | Dum | Tish
and you have a function that consumes drums

    play :: Drums -> String
    play Ba  = "Ba!"
    play Dum = "Dum!"
you've left out the Tish. Possibly because you don't have a cymbal. You know this, but the compiler doesn't. This is considered to be an incomplete pattern match and would raise some eyebrows.

But often it just means there's an invariant which you know and the type system does not. In Haskell -Wall will stop you dead here, but you can relax it to say "ehhhh, I know what I'm doing".

More generally, you can also write

    play :: Drums -> String
    play Ba   = "Ba!"
    play Dum  = "Dum!"
    play Tish = error "Impossible! I have no cymbal"
This 'error' is a misleadingly named function. It's more like 'assert' and indicates that this is a completely impossible program state (much like running into an unbalanced tree deep inside a library function which knows that tree balance is maintained). It's outside of the reach of the programmer to fix. It's not an exception, it's an assurance to the compiler that even though there's something missing in the type safety things will be OK.

Re: Haskell Is Exceptionally Unsafe (2012)

#50

Post by tel »

michaelochurch wrote: post #47
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…

Where do you work? What has your experience been using Haskell "in the RealWorld"? I'd love to know more about this. My email address is michael.o.church at Google's email service. I got seriously into Haskell a few months ago, but I've used ML in algorithmic trading and was a major fan. I feel like it does us a disservice to complain about Haskell's (admittedly, warty) Exception system or "cabal hell" when what is a…

The exception system that Harper was complaining about really was terrifically bad. It's all based on a form of limited reflection, but previously was implemented in a way that let you pretty regularly and possibly accidentally lie to the compiler. Nasty stuff, now gone.
Post reply on HN