28 ms·

I tried to use Haskell three times. Cabal was the always the reason why I left. I use three different machines. 2 at two different locations at work and one at

by baldfat 10y ago

I tried to use Haskell three times. Cabal was the always the reason why I left. I use three different machines. 2 at two different locations at work and one at home. All three would be different and have different errors. I would spend hours and always left with a horrible taste in my mouth. Today I use Racket and I won't go back but I am glad Stack is taking over Cabal.

cauterize 10y ago
stack uses cabal underneath, but your point stills stands that cabal has been historically hard to use.
danieldk 10y ago
Cabal was the always the reason why I left. It is not only Cabal, but also the constant churn in a lot of packages. For example, conduit was a great package when I used Haskell. But usually I had to update quite a bit of code when I would bump conduit up to the latest version after not touching a program for a year. Maybe I have been unlucky enough to use Haskell during some transitions (pre-arrows -> arrows rule, let's use them everywhere -> arrows suck, basic IO monad -> iteratees, old fashioned field access -> various lens proposals -> lens). But I never used a language ecosystem before or after where things would change or break so often.
- IngoBlechschmid 10y ago
  Yes, there have been quite a few transitions happening. They didn't happen "for fun", but because it had been felt that the optimal solutions were not found yet (optimal as in elegant, easy to use, maintainable, ...). Luckily, Haskell's static typing coupled with the extremely helpful error messages of the compiler makes refactoring a cheerful task: If it worked before and all type errors have been fixed, then we can be quite confident that it works again. Many areas have stabilized now. For instance, Edward Kmett's lens package is the de facto standard for all things related to records, getters, setters, and all those things on steroids. (Personally, I love how this turned out. Before lens, we quite frankly had the problem that field accesses were much more painful than they are in mainstream object-oriented languages like Python or Java. Nowadays field accesses are as simple as they are in other languages, and in addition to this we have the flexibility of composable first-class lenses.)
  - dllthomas 10y ago
    > all type errors have been fixed ... by someone trying to actually address the issues. There are almost always wrong ways you can fix a type error. Fortunately, that's usually the situation at hand...
chongli 10y ago
The number one mistake they made was in deciding to make the package database stateful. Such an odd choice for a language so focused on purely functional programming. Packages should be pure functions, with the final result being a read-only cache. This is how Nix [0] works and it makes everything else seem like a bad idea by comparison. [0] https://nixos.org/nix/ https://nixos.org/nix/
WmyEE0UsWAwC2i 10y ago
I started using haskell before stack but after cabal sandboxes. Once I learned to use sandboxes cabal gave no problem. I don't understand why it keeps receiving so much heat. What does stack do that cabal can't?
- dllthomas 10y ago
  With sandboxes, I had little-to-no trouble developing individually on a single machine. I sometimes ran into issues trying to get the same thing building elsewhere.

by baldfat 10y ago

cauterize 10y ago

stack uses cabal underneath, but your point stills stands that cabal has been historically hard to use.

danieldk 10y ago

Cabal was the always the reason why I left. It is not only Cabal, but also the constant churn in a lot of packages. For example, conduit was a great package when I used Haskell. But usually I had to update quite a bit of code when I would bump conduit up to the latest version after not touching a program for a year. Maybe I have been unlucky enough to use Haskell during some transitions (pre-arrows -> arrows rule, let's use them everywhere -> arrows suck, basic IO monad -> iteratees, old fashioned field access -> various lens proposals -> lens). But I never used a language ecosystem before or after where things would change or break so often.

IngoBlechschmid 10y ago
Yes, there have been quite a few transitions happening. They didn't happen "for fun", but because it had been felt that the optimal solutions were not found yet (optimal as in elegant, easy to use, maintainable, ...). Luckily, Haskell's static typing coupled with the extremely helpful error messages of the compiler makes refactoring a cheerful task: If it worked before and all type errors have been fixed, then we can be quite confident that it works again. Many areas have stabilized now. For instance, Edward Kmett's lens package is the de facto standard for all things related to records, getters, setters, and all those things on steroids. (Personally, I love how this turned out. Before lens, we quite frankly had the problem that field accesses were much more painful than they are in mainstream object-oriented languages like Python or Java. Nowadays field accesses are as simple as they are in other languages, and in addition to this we have the flexibility of composable first-class lenses.)
- dllthomas 10y ago
  > all type errors have been fixed ... by someone trying to actually address the issues. There are almost always wrong ways you can fix a type error. Fortunately, that's usually the situation at hand...

chongli 10y ago

The number one mistake they made was in deciding to make the package database stateful. Such an odd choice for a language so focused on purely functional programming. Packages should be pure functions, with the final result being a read-only cache. This is how Nix [0] works and it makes everything else seem like a bad idea by comparison. [0] https://nixos.org/nix/ https://nixos.org/nix/

WmyEE0UsWAwC2i 10y ago

I started using haskell before stack but after cabal sandboxes. Once I learned to use sandboxes cabal gave no problem. I don't understand why it keeps receiving so much heat. What does stack do that cabal can't?

dllthomas 10y ago
With sandboxes, I had little-to-no trouble developing individually on a single machine. I sometimes ran into issues trying to get the same thing building elsewhere.