4 ms·

Completely agree. For a long time, I've thought that humans shouldn't be in charge of version numbers at all. The main problem is that a human isn't reliable at

by arohner 12y ago

Completely agree. For a long time, I've thought that humans shouldn't be in charge of version numbers at all. The main problem is that a human isn't reliable at determining "is this change breaking?". Unfortunately our software isn't well-specified enough to allow the computer to determine version numbers automatically yet. To make this a reality, you'd need Haskell-level type safety, along with specifying other constraints, like "this fn is O(log(n)) or better". >If you're pinning versions, you're reducing the package manager to a glorified CURL I'm actually quite happy with this. I realized it when a few weeks ago, bower broke for me. Turns out, a grandchild dependency of bower failed to follow semver. This means that it's not enough for you to follow semver, every single dependency of all of your dependencies have to follow semver as well.

ZitchDog 12y ago
> Unfortunately our software isn't well-specified enough to allow the computer to determine version numbers automatically yet. To make this a reality, you'd need Haskell-level type safety, along with specifying other constraints, like "this fn is O(log(n)) or better". Isn't this going to be impossible for the same reason the Halting Problem is unsolvable?
- deleted 12y ago
  [deleted]
- arohner 12y ago
  The halting problem is unsolvable in the general case, but there are lots of specific, practical cases where you can answer "yes, this program terminates". Is it possible to specify the complexity of every arbitrary function? Probably not. Is it possible (and useful!) to specify the complexity of most functions you use on a daily basis? Absolutely. A stronger critique I heard once is that 'computer generated complexity analysis has too much noise in it', where you ask what is the complexity of this fn, and rather than giving you O(n^2), it gives you back O(n^2 * m * q * log(r) * s^4), but it turns out 's' is "always" a small number, and m & q are constants. You can improve (but not completely eliminate) this by doing empirical testing, i.e. "the statistical sample of 1000 test runs varying the input does appear to fit an O(n^2) curve".
  - ZitchDog 12y ago
    While it may be possible to statically analyze time complexity of code, I'm not sure it will ever be a good idea to go whole hog and generate version numbers from these analyses due to the fact that it's never going to be 100% accurate.
AaronFriel 12y ago
For anyone in the Haskell world, it's obvious that semantic versioning[1] doesn't work. Some non-trivial amount of that is likely due to how horribly broken Cabal is, a problem the community remains in staunch denial of. But for the rest, one problem is that because Haskell more thoroughly specifies types, individual functions can remain the same in behavior but change in type because a bug-fix, say, fixes a record type used somewhere. The external interface might be largely the same, or even identical, but the binary output is non-backwards compatible. Dynamic libraries and strong, descriptive type systems aren't very compatible. The result is that a lot of bug fixes become minor version bumps. These minor version bumps scare library developers, especially people that produce libraries that depend on libraries that depend on... and so on. So packages fail to build too often because of constraints. So the irony of this thorough process for package building is that humans have mucked it up and made it break builds. In almost every case in which semantic versions blocked some update from occurring and caused my work to stop, it was because I needed to bump the constraints on some third-party package. It's a boring process that I've only become too accustomed to: 1. try to build with updated libA 1.1.0-foobar 2. libB depended on libA < 1.1 3. download source for libB 4. update constraint and repackage libB locally 5. rebuild main application This happens just about every time there's a new version of any major piece of Haskell software. If we really want to move into The Future, we need to start versioning individual modules or functions, instead of whole suites of software. But the cognitive burden of doing this is very high, and the software to do it hasn't been written yet. [1] The Haskell community doesn't technically use semver, but rather a related policy called the package versioning policy. That's a nitpick though, and doesn't affect my argument.
- wycats 12y ago
  How would you say that Cabal is horribly broken?
- judk 12y ago
  Haskell's problem isn't that semver (ironically called PVP in Haskell land) is broken, it's that library authors don't care about providing stable interfaces, so the set of libraries really are not compatible.
- 12y ago

by arohner 12y ago

ZitchDog 12y ago

> Unfortunately our software isn't well-specified enough to allow the computer to determine version numbers automatically yet. To make this a reality, you'd need Haskell-level type safety, along with specifying other constraints, like "this fn is O(log(n)) or better". Isn't this going to be impossible for the same reason the Halting Problem is unsolvable?

deleted 12y ago
[deleted]
arohner 12y ago
The halting problem is unsolvable in the general case, but there are lots of specific, practical cases where you can answer "yes, this program terminates". Is it possible to specify the complexity of every arbitrary function? Probably not. Is it possible (and useful!) to specify the complexity of most functions you use on a daily basis? Absolutely. A stronger critique I heard once is that 'computer generated complexity analysis has too much noise in it', where you ask what is the complexity of this fn, and rather than giving you O(n^2), it gives you back O(n^2 * m * q * log(r) * s^4), but it turns out 's' is "always" a small number, and m & q are constants. You can improve (but not completely eliminate) this by doing empirical testing, i.e. "the statistical sample of 1000 test runs varying the input does appear to fit an O(n^2) curve".
- ZitchDog 12y ago
  While it may be possible to statically analyze time complexity of code, I'm not sure it will ever be a good idea to go whole hog and generate version numbers from these analyses due to the fact that it's never going to be 100% accurate.

AaronFriel 12y ago

For anyone in the Haskell world, it's obvious that semantic versioning[1] doesn't work. Some non-trivial amount of that is likely due to how horribly broken Cabal is, a problem the community remains in staunch denial of. But for the rest, one problem is that because Haskell more thoroughly specifies types, individual functions can remain the same in behavior but change in type because a bug-fix, say, fixes a record type used somewhere. The external interface might be largely the same, or even identical, but the binary output is non-backwards compatible. Dynamic libraries and strong, descriptive type systems aren't very compatible. The result is that a lot of bug fixes become minor version bumps. These minor version bumps scare library developers, especially people that produce libraries that depend on libraries that depend on... and so on. So packages fail to build too often because of constraints. So the irony of this thorough process for package building is that humans have mucked it up and made it break builds. In almost every case in which semantic versions blocked some update from occurring and caused my work to stop, it was because I needed to bump the constraints on some third-party package. It's a boring process that I've only become too accustomed to: 1. try to build with updated libA 1.1.0-foobar 2. libB depended on libA < 1.1 3. download source for libB 4. update constraint and repackage libB locally 5. rebuild main application This happens just about every time there's a new version of any major piece of Haskell software. If we really want to move into The Future, we need to start versioning individual modules or functions, instead of whole suites of software. But the cognitive burden of doing this is very high, and the software to do it hasn't been written yet. [1] The Haskell community doesn't technically use semver, but rather a related policy called the package versioning policy. That's a nitpick though, and doesn't affect my argument.

wycats 12y ago
How would you say that Cabal is horribly broken?
judk 12y ago
Haskell's problem isn't that semver (ironically called PVP in Haskell land) is broken, it's that library authors don't care about providing stable interfaces, so the set of libraries really are not compatible.
12y ago