Thank you for your response. Please do not assume ill intent on my part; there's nothing condescending (or passive aggressive, etc.) in linking the word "control" to the article on scientific controls. (There is also no attempting to seek philosophical purity on my part at the expensive of productivity. I am _only_ interested in productivity and reason here.) However, I don't think you are thinking clearly. You're certainly not speaking clearly.

A reminder that the resolution up for debate is "Dependencies belong in version control". (Specifically, the author is making the case that they belong in the same version control system you're using to store your own application code which is relying on those dependencies—i.e. dependencies should should not be in e.g. some ZIP files "over there", nor should they be versioned in an orthogonal version control system like Cargo, NPM, RubyGems, etc—to the exclusion of your primary version control system. In other words, they should not be late-fetched from a package host immediately after cloning or at some point leading up to and including immediately prior to the build. The author is saying you should check them into your repo. By doing this, once you've cloned your repo, then you have the dependencies corresponding to the last version that you built/deployed/whatever at the time that you built/deployed it or whatever.)

I am not saying this to be condescending. I am saying this because it is important to be clear and for us to stay on topic rather than straying into totally unrelated territory, talking about totally unrelated things, or bringing hidden assumptions into the discussion, etc[1]. I believe that you are either responding to what could be reasonably characterized as perceived constraints that are unstated on my part (i.e. that I'm failing to disclose them but you understand them nonetheless—I'm not, and there are none there), or you are taking liberties in making assumptions of your own without stating them. This is bad, and it doesn't lead to clear thinking or useful conversation for the purpose of getting there.

> The problem is inherently in the bumping of versions, and pulling in new code from upstream and dealing with emerging tech debt and integration problem. Once you have builds reasonably reproducible (lockfiles, etc) then just dealing with all the new code you're pulling in dwarfs the benefits

Okay, that's nice, but... compared to what? How does late-fetching your dependencies from a third-party package repo sometime between cloning and build time solve the integration problem? (Alternatively, you can interpret this question as, "How does keeping a copy of those dependencies directly in your repo exacerbate integration problems?") Your position seems to hinge on some magical property where in the latter case, when your repo has its own copies of those dependencies and you don't have to fetch them in a separate step, integration somehow becomes hard. (NB: I'm not trying to be reductive. I'm trying to make sense of your position.) It doesn't; there is no such magical property. You were right the first time when you said "you _always_ have the cost of integration", with special emphasis on "always".

I'll repeat myself from before: if you're running into upgrade issues because of a change to a dependency, then not checking in your dependencies doesn't ipso fact solve any of those issues, and checking in your dependencies doesn't inexplicably cause any more. Where the bits are coming from—whether some location on your own disk, or streamed in at the last second over the network—doesn't matter in this regard. If there's a breaking change upstream, it's going to break no matter what.

(Am I being uncharitable? Am I misunderstanding what you're actually arguing for/against? I'm not saying this out of convenience for myself, that is, that it would be convenient for me if you were. It strikes me as something that nobody would actually advocate for because of how obviously untrue it is. Again, I'm trying to make sense of your position based on what you've actually said. This is exactly why I pre-emptively pleaded that you be specific in your response.)

> Based on a decade of experience

I don't know why you think this is relevant. I have two decades of experience to your one. I am not a neophyte programmer who e.g. picked up React last year and is stymied or frustrated by all this tooling and looking for excuses to assure myself that it's not really all that important after all. I was around before any of this tooling was. I adopted this tooling when it showed up. But then I had a realization one day and stopped and said, "Waitaminute. What the hell are we doing? What _actual_ problem, in concrete terms, are we saying this solves, exactly?" My position is that we've sleptwalked into adopting complex tooling for which we can't clearly articulate the tangible benefit it's supposed to deliver when we use it this way. I can't articulate "The NPM hypothesis" myself, and in my post-realization prodding, I've been unsuccessful at getting anyone else to, either. I covered this all in my first comment to this submission[2]. But most importantly, though, none of this matters.

You seem to be approaching this as if does matter—at least that's how I'm reading things. I could be wrong. (I'm just as open to the possibility that this is a poor reading as I am open to the possibility that I've overlooked something on the subject of package management—or anything else. I'm a programmer after all. We write bugs and have to debug them and are shown every single day the things that we were wrong about. There's no reason programmers shouldn't be among the most humble people in the world, having gotten used to consistently being told they're wrong like this.)

The reality is it doesn't matter. There are fact claims in play here that are within the realm of science, and they either true or they are untrue. We should be able to subject them to scrutiny. Science doesn't care who's asking the questions, nor should it.

Feel free to point out anything that I'm overlooking or anywhere I've misrepresented what you're saying. If that has happened, I hope you do.

1. e.g. <https://news.ycombinator.com/item?id=38438530#38437340>

2. <https://news.ycombinator.com/item?id=38426051>