Hacker News Reader

Comment by arohner | Hacker News Reader

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.

View on HN

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.

How would you say that Cabal is horribly broken?

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.

> 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.

I don't think this problem is related to any cognitive burden, but is an artifact of how the package manager works and how easy it is to liberally publish packages. Consider npm, where people publish packages with little to no coordination and everything is mostly fine (whatever the author of the parent article says). Because it's so easy to make an npm account (anybody can `npm adduser` and start publishing immediately) and so easy to publish (just pick an unused name, make a package.json, and `npm publish`), people routinely make very granular packages, often just a single function. Importantly, these functions don't need to fit into a taxonomy namespace like in haskell which prevents namespace hierarchy turf wars for the lesser price of namespace landgrabs.

Better still, you can have multiple different versions of a library in the same application. In your example, libB would just get the version of libA that its constraints satisfy but elsewhere other libraries could depend on a version of libA that do not satisfy the constraints on libA that libB requires because every package gets their own copy of their dependencies, with automatic deduping when the constraints are satisfied to save space.

> 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?

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".

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.

Reply on news.ycombinator.com