4 ms·
> If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong cor
by comma_at 5y ago
> If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and thus actually fix things).
Yes, and the result of that is cabal hell. Types aren't there to help you break your API. Once the API is out and it has users it is rude to break them. The linux kernel is a prime example how far can you get if you don't break your users.
- cies 5y agoCabal hell is fixed with tooling. Part of that tooling is running tests, but a large part of it is "it compiled together so it should work together" (which is a safety dynamic typed langs dont offer).
- comma_at 5y agoNo it is not. People still reach out from stack when a dependency has updates and it's not in stack yet. Nobody cares if it compiles together. The point is if a new feature or a bug fix is introduced in a breaking way you cannot bump your dependency and start using it, or progressively move to the new API.
- cies 5y agoIn my experience Stack solved all my cabal hell. I've come to accept some level of dependency juggling, as I had it with every languages. In Haskell is was more laborious before Stack (the place known as cabal hell) and it got better than average after Stack. Sure, this is just my subjective experience. > Nobody cares if it compiles together. Well I didi. If Stack guarantees that a set of software compiles/tests together, then I dont have to do that work.