Being unsafe never stopped Ruby or PHP, while Ada is still nowhere.
Haskell Is Exceptionally Unsafe (2012)
51–60 of 125 posts
Re: Haskell Is Exceptionally Unsafe (2012)
#52Harper's an accomplished person in CS and has done great work, but he's not putting a good argument forward here. I've talked to Harper about this post and his opposition to Haskell before. I mentioned that it was leading people to believe they could ignore typed FP, not redirecting to an ML derivative. Harper expressed dismay at this. There are more advanced languages than Haskell, they aren't ML, and PL researchers…
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 toward his grand vision of unified PL.
ML is better than Haskell in many ways. This should drive Haskell to improve as much as it drives people to check out ML. And it has!
Re: Haskell Is Exceptionally Unsafe (2012)
#53Earlier quoted context omitted.
Perhaps Coq, Agda, Idris, and other such dependently-typed languages are to be considered, at least in some dimensions, "more advanced" than Haskell.
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.
Re: Haskell Is Exceptionally Unsafe (2012)
#54Earlier quoted context omitted.
As an intermediate Haskeller I'm curious, what's the replacement for SYB? I've worked in haskell primarily on compiler-like tree tranformation code and SYB seems to fit the bill perfectly.
There's http://www.haskell.org/haskellwiki/Template_Haskell , for one
TH isn't really the same functionality as SYB.
Re: Haskell Is Exceptionally Unsafe (2012)
#55As 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)?
Full-timer here. I use cabal sandboxes heavily and recommend you do so.
Nix is great but you have to take some time to set it up and learn it - sandboxes are pretty standard and work as you would expect with ghc-mod (not that Nix doesn't I just had more time invested in getting it and the tooling setup to use it as a "dev environment" - cabal sandboxes are much simpler).
Stackage is great too, btw.
Re: Haskell Is Exceptionally Unsafe (2012)
#56As 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…
I've just finished a stint running a team building a start up in Haskell and clojurescript. It's been an amazing year, and for me has completely vindicated my view that not only is Haskell fine for real world use, but for a number of reasons that it's a superior tool to use. I'm ben perurbis com if you'd like me to expand on that a bit (I don't want to hijack this thread too much).
Re: Haskell Is Exceptionally Unsafe (2012)
#57Earlier quoted context omitted.
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 de…
To be fair other languages need sandboxes as well: Virtualenv in Python and Bundler in Ruby fill the role
But in a language like Haskell, a sandbox is definitely a subpar solution (glacial compilation times and huge artifacts sizes inside ~/.cabal: 1GB on my machine, compared to the few hundred MB of my ~/.m2). Unless we find a way to bootstrap a sandbox from a vetted/trusted base one that contains things like Yesod (but vetting packages is a job better handled by stackage and/or nix ).
I use Nix, but I'm not comfortable yet in using it with Haskell... to try things quickly I'd need to whip up a nix-shell. But I'm more used to simply have easy access to a ghci repl at my fingertip. And if I install both things, I have to keep care at not trying to cabal install things onto the nix-installed ghc, nor to do the quick-and-dirty thing (go back to install things in ~/.cabal)
Something like lein-try [1] plus Nix might cover my use cases. But Stackage seems simpler and closer to the workflow most haskell developers are accustomed with (and it could be useful also for platforms that don't have Nix available)... if only it'd have more adoption
Re: Haskell Is Exceptionally Unsafe (2012)
#58Earlier quoted context omitted.
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 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.
Trying to do any sort of open-source development without a library sandbox, in any language, is madness. OS package managers are completely unable to deal with multi-version dependency graphs. NixOS is no different, unless you want to install the cartesian product of the possible combinations -- how much SSD space do you have?
---
My experience with Haskell leads me to believe that "Cabal hell" is an artifact of certain library developers' API versioning philosophies. Namely, they release numerous libraries all depending on each other with tight version bounds, and change the API regularly. This behavior is fundamentally incompatible with dependency resolution in a compiled language.
Say you have four libraries:
foo-1.0 depends on bar==3.8 and qux==1.5
bar-3.8 depends on baz==0.2 and qux==1.5
baz-0.2 has no dependencies
qux-1.5 has no dependencies
foo-1.1 depends on bar==1.1 and qux==1.6
bar-1.1 depends on baz==1.1 and qux==1.5
Now imagine that instead of four libraries, it's O(50), and they're all changing regularly.
Writing lots of tooling and writing manifestos against Cabal sort of helps, for a bit, but it's a lot of work and is deeply unsatisfying for the kind of person who likes to make progress on other goals.
IMO the only practical solution is to loosen the dependency version bounds, and commit to maintaining API compatibility for several releases. I have never encountered Cabal hell when using packages with reasonable versioning philosophies.
Re: Haskell Is Exceptionally Unsafe (2012)
#59Earlier 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)?
Full-timer here. I use cabal sandboxes heavily and recommend you do so. Nix is great but you have to take some time to set it up and learn it - sandboxes are pretty standard and work as you would expect with ghc-mod (not that Nix doesn't I just had more time invested in getting it and the tooling setup to use it as a "dev environment" - cabal sandboxes are much simpler). Stackage is great too, btw.
Thanks. Since we got the ball rolling (I planned to ask it on some mailing list, but I kept procrastinating to write a semi-formal mail).
Do you know of any way to use multiple stackage repositories? (for now it's not a problem, but I envision a future when I'll have dozens of projects, and updating everyone of them to use the same library versions might not be feasible)
I know that I can `cabal --config-file=/path/to/cabal.config` but I'm wondering if there's an easier way and/or any convention
I'm especially worried of forgetting something (like reusing the same ~/.cabal for multiple stackage-cabal configs)
Re: Haskell Is Exceptionally Unsafe (2012)
#60As 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.
He's probably saying that he things the next big thing will be strict by default and feature a neat module system.