Live data from Hacker News

Haskell Is Exceptionally Unsafe (2012)

existentialtype.wordpress.com

121–125 of 125 posts

Re: Haskell Is Exceptionally Unsafe (2012)

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

> Trying to do any sort of open-source development without a library sandbox, in any language, is madness.

Really?

Even Java people have been perfectly fine without it. Sandboxing is just a hack around Cabal/GHC not having any workable version support.

Re: Haskell Is Exceptionally Unsafe (2012)

#122

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…

> Modularity is something which Haskell people simply do not take seriously Plus, the build/module/packaging/dependency resolution story, even when doing all the recommended best practices involving sandboxing Cabal and leveraging Nix are just plain embarrassing. There are so many smart Haskell people. I don't understand how any of them could consider this clusterf*ck to be remotely acceptable.

When using python I use virtualenv. When using Haskell I use cabal sandbox. I rarely have any problems, why is it a clusterf*ck?

Re: Haskell Is Exceptionally Unsafe (2012)

#123

Earlier quoted context omitted.

> Modularity is something which Haskell people simply do not take seriously Plus, the build/module/packaging/dependency resolution story, even when doing all the recommended best practices involving sandboxing Cabal and leveraging Nix are just plain embarrassing. There are so many smart Haskell people. I don't understand how any of them could consider this clusterf*ck to be remotely acceptable.

When using python I use virtualenv. When using Haskell I use cabal sandbox. I rarely have any problems, why is it a clusterf*ck?

In Haskell, sandboxes usually force you to rebuild stuff which you have already built over and over.

Anyway, sandboxes are pointless hacks which wouldn't be necessary if things had been done properly from the beginning.

They are like Node.JS ... yes, it enables you to develop with JavaScript on the server, but how the hell did you end up with using JavaScript in the first place?!

Re: Haskell Is Exceptionally Unsafe (2012)

#124

Earlier quoted context omitted.

When using python I use virtualenv. When using Haskell I use cabal sandbox. I rarely have any problems, why is it a clusterf*ck?

In Haskell, sandboxes usually force you to rebuild stuff which you have already built over and over. Anyway, sandboxes are pointless hacks which wouldn't be necessary if things had been done properly from the beginning. They are like Node.JS ... yes, it enables you to develop with JavaScript on the server, but how the hell did you end up with using JavaScript in the first place?!

Sandboxes aren't pointless hacks which shouldn't be necessary. It's a lot more difficult for static languages to get right, and solutions like Maven have had tons of work put into them.

You say "if things had been done properly from the beginning" implying you know some mistakes that were made. What mistakes were made in the beginning?

Do you have any ideas how the problems cabal has could have been avoided? There are very intelligent people working on this problem and it is well known that dependency resolution isn't an easy problem.

Re: Haskell Is Exceptionally Unsafe (2012)

#125

Earlier quoted context omitted.

In Haskell, sandboxes usually force you to rebuild stuff which you have already built over and over. Anyway, sandboxes are pointless hacks which wouldn't be necessary if things had been done properly from the beginning. They are like Node.JS ... yes, it enables you to develop with JavaScript on the server, but how the hell did you end up with using JavaScript in the first place?!

Sandboxes aren't pointless hacks which shouldn't be necessary. It's a lot more difficult for static languages to get right, and solutions like Maven have had tons of work put into them. You say "if things had been done properly from the beginning" implying you know some mistakes that were made. What mistakes were made in the beginning? Do you have any ideas how the problems cabal has could have been avoided? There ar…

> solutions like Maven have had tons of work put into them

Maven required tons of work because it's written in Java, not because the ideas behind it are advanced in any sense.

It's sounds absurd because it's so simple, but the issue is that Cabal/GHC doesn't deal with versioning. Different versions of the same library are not properly treated as different artifacts. That's why everything breaks if you install it into a global namespace.

"Great, let's just multiply our namespaces!" is the obvious knee-jerk reaction, but not a great solution.

> There are very intelligent people working on this problem

That sounds great! Because until now I have mostly seen "very intelligent people" who have been busily in denial that a problem even exists.

Post reply on HN