Like @Wintermute, I'm struggling to follow what you're trying to say. The "better tools" you're referring to are precisely package managers. And they're useful precisely because they don't automate the decision entirely (leaving humans disempowered) but because they "help with those decisions" as you put it. So it's unclear to me where we disagree. Let me try to knock off a few things I'm not saying, just in case they weren't clear before:

a) I'm not saying we should be deploying software to production by wantonly installing whatever the latest version of our dependencies happen to be. Things like Gemfile.lock in the Ruby/Bundler world are a good idea, and my post isn't about them at all.

b) I'm not saying we should be upgrading our dependencies en masse and immediately running `git commit` without testing that the upgrade actually worked.

Upgrading dependencies will and should always be a manual process. I just want it to be less of a bottomless time-sink.

The two links I mention at the start of OP set all this background up. Perhaps I should have explicitly said people need to read/watch them before reading me. They're actually better posts written by better writers and programmers, so they're almost certain to be a better use of your time than my miniscule contribution (that I wrote without understanding Cargo, and so may well already be hopelessly wrong).

Yes, I'm not familiar with Rust, and I've been meaning to learn more there. The best response to my post thus far started off with a description of how Rust has successfully policed SemVer, and the issues they ran into: https://news.ycombinator.com/item?id=15676691#15677343. I'd greatly appreciate further pointers to how that community does things.

> Nothing interesting is trivial. That's almost tautological. Calling something out for being non-trivial is either meaningless..

I just provided a trivial alternative that I found interesting. So much for your "tautology".

> ..or equivalent to calling it hard[er than it should be].

I do call it harder than it should be, by providing a simpler alternative.

It doesn't look like you disagree that a tuple is easier for the package manager to unpack than a string. You seem to be only saying that the difference isn't much. I've already agreed with that. So what are we arguing about?

---

I have a problem with the statement that "nothing interesting is trivial": it becomes license for hiding over-engineering. I'd rather say that "everything can be trivial". It's right about the same fraction of the time, and even when it's wrong it's an impetus to find better ways, rather than to be complacent.

I spend some time teaching programming, and it's amazing to me how often finding the right approach to teach something renders it almost trivial. See also Alan Kay's statement about the right perspective being worth 80 IQ points.

---

I have a problem with statements as general as "nothing interesting is trivial" (Or, indeed, "everything can be trivial".) They aren't concrete enough to actually support any serious amount of reasoning. You can end up anywhere you like depending on how you interpret them. This comment is about as much of such fluffy debate as I can handle without breaking out in hives.

---

Seriously, stop nit-picking wording in one sentence I quickly moved past in OP. It's mystifying to me why that's a better use of your time, rather than to elaborate on the "practical reasons" you so quickly skip past. I'm going to stop engaging here unless it is to discuss more substantive criticisms.

I agree that the article needs to change something. I'm not a good writer yet, and I definitely failed to get my point across to many (most?) readers.

But I don't think separating package managers from the discussion of versioning is a good idea. Versioning is a social convention (as evidenced by the quantity of criticism my attempt at changing convention has engendered), and the #1 place the convention is propagated is in the package manager.

You can in principle implement every one of my recommendations (or any alternatives people proposed in comments) without changing the package manager. But of course nobody would expect that to take.

The big insight that provoked my post was that the bad behaviors the creators of Clojure and Mercurial were complaining about stemmed from bad defaults in package managers.

> "3.0.2" is hard to parse? Are you serious?

If this was the only sentence-level criticism you could make I'm not doing so bad :) Notice that I said "non-trivial", not "hard". In a tool whose #1 reason for existence is to "get the latest version", it seems a bad idea to make the format of version strings unstructured in code (they're literally strings surrounded in quotes) or convention (people are encouraged to add arbitrary words to them). Why make comparison unnecessarily difficult?

I'm talking about creating a package manager from scratch (I'm not proposing every package manager break their users in a post about not breaking your users) for some hypothetical next big language, and in that situation it seems worth fixing even if it's not that big a deal.

> The software I write for my job has version numbers, even though it isn't distributed through any package manager.

My recommendation may absolutely not apply then. If your software isn't ever being upgraded en masse I have no opinion on what versions it should have. I'm speaking in the context of eco-systems that want to be able to distribute security fixes (at the least) on an ongoing basis. That's what the two links I was putting together were talking about, and that usually involves a package manager to automate the upgrade process.

The convention programmers have long followed is now enshrined as something called Semantic Versioning (which comes with its own version, lol). Basically if a library makes an incompatible change it's supposed to increment the major version. So going from Rails 4.x to Rails 5.0 is a sign that you can't upgrade. Which is great in theory, except that the tools we programmers use to manage versions don't understand SemVer and just pick the latest version by default. Which causes programmers to explicitly ask for the version they want to avoid moving to the next. And all the 'pinning' in turn causes libraries to be less than disciplined about incrementing the major version number when they break something. So it's all a mess.

Sorry, yes you're absolutely right and I'm being unclear. I'm a reasonable programmer but not a good writer.

When I say "rename" I don't mean going from "Snow Leopard" to "El Capitan". That's stupid, yes. (And it's also marketing, which I know even less about. So I have no comment on what an improvement would be.) My proposal is going from "Rails-4" to "Rails-5". Which would have the same benefits as 10.11 and 10.12.

The comments I've gotten so far are making clear that I failed to set the stage for this post. The scenario I'm concerned about (as are the links I refer to) is this: you have an app you built, and it relies on some versions of other libraries. You'd like to periodically pick up bugfixes and security fixes for those libraries without it turning into a bottomless time-sink (because your libraries failed to adequately distinguish between compatible and incompatible changes). How do we do that? (It's not just about tool design, it's about eco-system design.)

Yes, if you can't relate with the problems mentioned in the talk and article I linked to, I guess you don't need the solution 🙂

Code shared between closely coupled teams tends to be the easier use case. Have you ever had issues upgrading your personal devices? I remember times when I couldn't get some Rails app running on my laptop after upgrading the OS. Anything like that ever happen to you?

I wrote an article about my first game a couple of years ago. Probably massively over-thinking it :)

On a related note, I've been watching Survivor after looking down my nose at it for the last 15 years.

I read this passage this morning, and it reminded me of this old bicycle I used to have, that I didn't realize I loved until after it was stolen:

Love is a kind of giving of attention. The one that is feeling the love has the universe organized for it as if by a kind of polarization. The giving is the getting. The feeling of attentiveness is its own reward. We had a labor of love. It absorbed our attention entirely. It gave a meaning to our existence. And this is a very great gift; this meaning is in the end what love gives. Because there is no obvious meaning to be found in the universe, as far as we can tell. But a consciousness that cannot discern a meaning in existence is in trouble, very deep trouble, for at that point there is no organizing principle, no end to the infinite search, no reason to live. No: meaning is the hard problem, and we solve it by giving and getting attention, and then it's all very interesting. It is a joy to serve.

-- Kim Stanley Robinson, "Aurora"

Sorry I wasn't clear. I'm not saying anything permanent and immutable about either men/women or high/low level languages. Rather I'm thinking about the path by which people learn, and claiming that the way we teach has, by historical accident, favored a very narrow subset of personality types with specific initial cognitive strengths. The others might well have become just as good or better programmers in the end, but they drop out very close to step 1, because of a format ill-suited to them, before they have a chance to find out.

When we say someone is a more visual or linguistic learner we aren't claiming they can't understand pictures or that their verbal GRE score is doomed to be low. We're just saying that they lean on one side/lobe of their brain more heavily than the others at the most initial stages of learning. I was speculating in similar vein.

Yeah, the 'motor control' section could be emulated by tmux+inotify. But you'd still have trouble writing tests that "the screen looks like this when you type this", and so on. It's also hard for learners to grok tests and code at the same time, so they currently learn testing later and not as well, or not at all.

I shared it recently, a logarithmic radial view of the known universe: