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

101–110 of 125 posts

Re: Haskell Is Exceptionally Unsafe (2012)

#101

Post by tome »

dllthomas wrote: post #65
berdario wrote: post #62

Earlier quoted context omitted.

> Trying to do any sort of open-source development without a library sandbox, in any language, is madness. I agree, but there're some interesting differences in how different language tools implement a sandbox. Python and Haskell (with Virtualenv and Cabal-dev/sandbox) have separate local repo/caches in which packages are installed (this is useful if you want packages in a reliable location to install executables) Ru…

I think a big part of the issue is that - because of the way Haskell's cross-module inlining works - you need to generate different artifacts not just for each version you use but for each set of dependencies chosen for each set of flags set for version you use. I think this strips away much of the benefit of the second approach.

This sounds like something Backpack might be able to help with! (I don't actually know. I'm speculating. And hoping ...)

Re: Haskell Is Exceptionally Unsafe (2012)

#102

Post by tome »

jonsterling wrote: post #67
ufo wrote: post #60

Earlier quoted context omitted.

He's probably saying that he things the next big thing will be strict by default and feature a neat module system.

Yes, that's close! I also think that we'll need a better treatment of effects than either ML or Haskell can give us, but I hope to have something that has been carefully thought about, rather than bolted on like Haskell's effects. It sounds like call-by-push-value gives a nice unifying approach to CBN/CBV and also effects. I am hoping that something interesting will come out of that work.

It's been about 15 years since CBPV was proposed. Has there been any work on actually making a practical language along those lines?

Re: Haskell Is Exceptionally Unsafe (2012)

#103

Post by dllthomas »

tome wrote: post #100
tel wrote: post #96

Earlier quoted context omitted.

It's remarkably easy to understand if you're already used to monads. Levy's thesis is a bit opaque from that POV, but not unpleasant to read.

Hmm, really? I just read a couple of papers linked from his website, but I'm still not feeling enlightened.

I would also appreciate a clear introduction.

Re: Haskell Is Exceptionally Unsafe (2012)

#104

Post by ZenoArrow »

progman wrote: post #87
ZenoArrow wrote: post #66

Earlier quoted context omitted.

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.

OCaml is nice too, it's just not for me. If you like OCaml you should definitely check out Mirage OS, it will fit into your small efficient systems ethos nicely... http://www.openmirage.org/

Re: Haskell Is Exceptionally Unsafe (2012)

#105

Post by ZenoArrow »

CmonDev wrote: post #94
progman wrote: post #87

Earlier quoted context omitted.

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.

Rare language has both .Net and JVM support, probably only Clojure now. On the upside you can build iOS and Android apps using F# plus many other gaming platforms.

Clojure is far from the only language that supports both the JVM and CLR. I had a long reply ready, but I lost it. Off the top of my head the languages that have support on both (aside from Clojure) are; Python, Ruby, JavaScript, Java (though J# is being depreciated), Scheme, Common Lisp, PHP, Perl 6, Prolog, Pascal, Ada. I might be missing some.

Re: Haskell Is Exceptionally Unsafe (2012)

#106

Post by platz »

progman wrote: post #63
jmillikin wrote: post #58

Earlier quoted context omitted.

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

Thanks for your detailed answer. I think you are right in recommending a way of less tight version bounds.

If you need it, cabal takes an option --allow-newer which can selectively or globally ignore upper bounds, in case the package owner specified too tight a bound

Re: Haskell Is Exceptionally Unsafe (2012)

#107

Post by coolsunglasses »

tel wrote: post #97
mercurial wrote: post #85

Earlier quoted context omitted.

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?

I suppose that's true. I guess in my eyes DTs are such a meteoric difference that Idris is not sufficiently more interesting than the others yet. But time will tell if they manage to build a better way to manage proofs, for instance, they could really change the game.

That there is no game-plan for doing anything any better than Coq presently does is why I'm a bit skeptical. The trimmings are nicer - nothing else as of yet.

Re: Haskell Is Exceptionally Unsafe (2012)

#108

Post by tel »

tome wrote: post #100
tel wrote: post #96

Earlier quoted context omitted.

It's remarkably easy to understand if you're already used to monads. Levy's thesis is a bit opaque from that POV, but not unpleasant to read.

Hmm, really? I just read a couple of papers linked from his website, but I'm still not feeling enlightened.

I may write a blog post. Hm.

Re: Haskell Is Exceptionally Unsafe (2012)

#109

Post by freyrs3 »

coolsunglasses wrote: post #107
tel wrote: post #97

Earlier quoted context omitted.

I suppose that's true. I guess in my eyes DTs are such a meteoric difference that Idris is not sufficiently more interesting than the others yet. But time will tell if they manage to build a better way to manage proofs, for instance, they could really change the game.

That there is no game-plan for doing anything any better than Coq presently does is why I'm a bit skeptical. The trimmings are nicer - nothing else as of yet.

The elephant in the room in these discussions is that the cost of bringing a function compiler to fruition is so high that too much of the discussion gets muddled in the semantics of these hypothetical Haskell-successor languages while no one is actually working on said language. Academia simply isn't set up to incentivize large engineering projects, and industry would never invest in building such a thing either since there's no profit in language dev sadly.

The blunt truth is that at the end of the day Haskell works today, period, and until someone actually forks or starts writing a new language very little of these criticisms of Haskell actually matter if the answer to "what should I use for my project at work" is "well it doesn't exist yet, but it has modules and extensionality and a magical pony that shits money".

Re: Haskell Is Exceptionally Unsafe (2012)

#110

Post by mercurial »

wyager wrote: post #86
mercurial wrote: post #84

Earlier quoted context omitted.

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

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).
Post reply on HN