Hacker News Reader

Comment by akkartik | Hacker News Reader

Two obvious constraints in sharing software:

* If software producers are pushing out obviously incompatible changes (excluding Hyrum's law and https://xkcd.com/1172) to consumers, the eco-system is broken. This includes SemVer-aware package managers which transparently bump up past major-version boundaries by default. (That doesn't seem to be what's happening here.)

* If software consumers can't handle new warnings, the eco-system is broken. This includes C and now Common Lisp.

Creating an eco-system that threads the needle between these constraints is an exercise for the reader. One thing that helps is minimizing the depth of dependency stack: https://news.ycombinator.com/item?id=16882140#16882555. Beyond that, producers should be free to make incompatible changes as long as consumers can pick them up on their own schedule. Anything else is absolutely bonkers.

View on HN

> If software consumers can't handle new warnings, the eco-system is broken. This includes C (...)

I didn't get that. Won't this only happen to those using `-Werror` or something similar? If so, aren't they responsible for their breakage, and not the ecosystem?

A frothy discussion along these lines is a big part of why we have -Wextra.

I don't think it's reasonable to exclude Hyrum's law in this case. The existing users of ASDF aren't doing anything prohibited by the software. The new change being pushed by the ASDF maintainers breaks existing builds and will break more when they promote it from a warning to an error, as planned.

"Don't break userspace" is a solid guideline. The ASDF maintainers should come up with a less opinionated way to achieve their goals.

No opinion on what anyone should do here. It's pretty clear it's a challenging situation.

More generally, the way I feel about Hyrum's Law is:

* The only way to guarantee you won't run afoul of Hyrum's Law is to make no updates.

* As a consequence, I don't care about Hyrum's Law. I make updates to the best of my ability, trying not to break others, but I don't/can't guarantee they won't break others.

* If my updates can break others, I can't push them to others without explicit consent. Others have to pick them up on their own schedule, when they have the time to test them for their own context.

* If my updates can break others, others may have to make changes to them for themselves.

Rather surprisingly, these baby steps lead to a world entirely different from the one I live in. One where we don't have interchangeable parts (https://en.wikipedia.org/wiki/Interchangeable_parts) yet, where software is often tweaked for a specific situation.

I've been ranting about this for a long time: http://akkartik.name/post/division-of-labor. It's shockingly unconventional, but I find the reasoning to be ironclad. If you can think of a refutation, I'd love to hear it. (Beyond, "no way anyone will use it." My goal is to understand what we _should_ do today, excluding tech breakthroughs.)

The one open question with this approach is how to notify people when you discover a security vulnerability in the software they're running. The way we deal with such notifications today feels highly inefficient, and yet I don't really know how to improve things.

Reply on news.ycombinator.com