4 ms·

Honestly, in the Haskell world, no one really complains about broken APIs, it's actually pretty common for a library to change things in a breaking way. People

Honestly, in the Haskell world, no one really complains about broken APIs, it's actually pretty common for a library to change things in a breaking way. People tend to either use Nix or stack to deal with versioning or they just plan to refactor when they have to. I personally just started with Haskell, but I've switched a small tool from one streaming library to another and it was super easy even though each had a very different API. Also, breaking API changes happen in every language, on every codebase, ask the time. At least with static types and a common linter I can refactor and be a hundred percent sure it works since it compiles, whereas in Python for example I can't be sure unless I add tests and stuff, even then...

skybrian 6y ago
Yes, there are easier and harder ways to deal with api migrations. But even in Haskell, isn't "Cabal hell" a thing? And the type of the standard prelude's head function is wrong but it can never be changed. Dependency migration is the sort of thing that's easy enough in small examples and gets harder as you scale up.
- lambda_obrien 6y ago
  You should use Haskell and see what it can do, you can change the prelude easily, for instance. The standard head function is partial, yes, but that's not a big deal at all.
- Chris_Newton 6y ago
  But even in Haskell, isn't "Cabal hell" a thing? Less so than it used to be. Cabal received a big update a few years ago, and the new-style commands now operate more like many other package managers in terms of isolation etc.
- Quekid5 6y ago
  > But even in Haskell, isn't "Cabal hell" a thing? No. Just use stack + Stackage and you have a huge set of packages which are mutually compatible. (You can also use cabal-install with a Stackage snapshot, I think. Not sure though. Cabal-install has also improved massively and doesn't really do "global" installation of dependencies, so it'll help a lot... but you may still run into difficulties making different versions of your project's dependencies work together.)
Chris_Newton 6y ago
Honestly, in the Haskell world, no one really complains about broken APIs I don’t believe that’s true. The very existence of Stack and Stackage is testament to how significant the compatibility problems had become in the Haskell ecosystem. Even if it were true, Haskell world is tiny and (in)famously has the motto “Avoid success at all costs”, so it isn’t necessarily a representative example of practices that would be effective in other contexts. The advantage with a type system as explicit as Haskell’s is that at least if there is a breaking change in an interface you depend on, you get quite good information about where the problem is and what you need to do to fix it. Also, breaking API changes happen in every language, on every codebase, ask the time. Some people take backwards compatibility extremely seriously, and code that depends on their interfaces still works just fine many years after it was written. The pace of development is usually slower when robust standardisation is part of the process, but that isn’t necessarily a bad thing given the stability you get in return. At least with static types and a common linter I can refactor and be a hundred percent sure it works since it compiles This is a common claim in the Haskell world, but of course it’s not really true. It always reminds me of Knuth’s famous quip, “Beware of bugs in the above code; I have only proved it correct, not tried it.”

skybrian 6y ago

Yes, there are easier and harder ways to deal with api migrations. But even in Haskell, isn't "Cabal hell" a thing? And the type of the standard prelude's head function is wrong but it can never be changed. Dependency migration is the sort of thing that's easy enough in small examples and gets harder as you scale up.

lambda_obrien 6y ago
You should use Haskell and see what it can do, you can change the prelude easily, for instance. The standard head function is partial, yes, but that's not a big deal at all.
Chris_Newton 6y ago
But even in Haskell, isn't "Cabal hell" a thing? Less so than it used to be. Cabal received a big update a few years ago, and the new-style commands now operate more like many other package managers in terms of isolation etc.
Quekid5 6y ago
> But even in Haskell, isn't "Cabal hell" a thing? No. Just use stack + Stackage and you have a huge set of packages which are mutually compatible. (You can also use cabal-install with a Stackage snapshot, I think. Not sure though. Cabal-install has also improved massively and doesn't really do "global" installation of dependencies, so it'll help a lot... but you may still run into difficulties making different versions of your project's dependencies work together.)

Chris_Newton 6y ago

Honestly, in the Haskell world, no one really complains about broken APIs I don’t believe that’s true. The very existence of Stack and Stackage is testament to how significant the compatibility problems had become in the Haskell ecosystem. Even if it were true, Haskell world is tiny and (in)famously has the motto “Avoid success at all costs”, so it isn’t necessarily a representative example of practices that would be effective in other contexts. The advantage with a type system as explicit as Haskell’s is that at least if there is a breaking change in an interface you depend on, you get quite good information about where the problem is and what you need to do to fix it. Also, breaking API changes happen in every language, on every codebase, ask the time. Some people take backwards compatibility extremely seriously, and code that depends on their interfaces still works just fine many years after it was written. The pace of development is usually slower when robust standardisation is part of the process, but that isn’t necessarily a bad thing given the stability you get in return. At least with static types and a common linter I can refactor and be a hundred percent sure it works since it compiles This is a common claim in the Haskell world, but of course it’s not really true. It always reminds me of Knuth’s famous quip, “Beware of bugs in the above code; I have only proved it correct, not tried it.”