4 ms·

I mean... if you're fixing a broken API, you're going to have to bite the bullet either way -- papering over it isn't going to fix anything... it just hides the

I mean... if you're fixing a broken API, you're going to have to bite the bullet either way -- papering over it isn't going to fix anything... it just hides the problems. With a type system which understands effects, at least the compiler can give you very accurate help in fixing call sites.

skybrian 6y ago
It does help by telling you what's wrong. But in a way, increased precision makes the problem worse. Suppose you have have a language with two categories of functions, those that can fail (returning an error) and those that can't. It's nice that within the "functions that can fail" category, you don't have to worry about what kind of error it might be. Error propagation can happen in a generic way. Adding a new kind of error doesn't change any API's. If instead, you have different kinds of errors and declare them everywhere, you end up with a situation like Java's checked exceptions. The problem is being too precise, which doesn't leave room for changes later. Similarly, we could be very generic about effects. Maybe we could just say "this function has effects" and treat them all the same? By not being precise about what the effects might be, we aren't promising too much, so we allow ourselves room for change. The downside is that the caller has to assume any effect is possible. This is a fundamental tradeoff between caller and callee convenience. You need to be specific enough for the caller to be able to deal effectively with the effects you declare, but not too specific, or you're painting yourself in a corner.
- lambda_obrien 6y ago
  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

It does help by telling you what's wrong. But in a way, increased precision makes the problem worse. Suppose you have have a language with two categories of functions, those that can fail (returning an error) and those that can't. It's nice that within the "functions that can fail" category, you don't have to worry about what kind of error it might be. Error propagation can happen in a generic way. Adding a new kind of error doesn't change any API's. If instead, you have different kinds of errors and declare them everywhere, you end up with a situation like Java's checked exceptions. The problem is being too precise, which doesn't leave room for changes later. Similarly, we could be very generic about effects. Maybe we could just say "this function has effects" and treat them all the same? By not being precise about what the effects might be, we aren't promising too much, so we allow ourselves room for change. The downside is that the caller has to assume any effect is possible. This is a fundamental tradeoff between caller and callee convenience. You need to be specific enough for the caller to be able to deal effectively with the effects you declare, but not too specific, or you're painting yourself in a corner.

lambda_obrien 6y ago
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.”