3 ms·
> In case you are serious, and I am not super sure about that. What's unclear? I linked directly to a comment thread where we had this exact exchange. Yes, I
by cxr 3y ago
> In case you are serious, and I am not super sure about that.
What's unclear? I linked directly to a comment thread where we had this exact exchange. Yes, I'm being serious. Do you have solid backing for your position or not? Can you state it clearly or not?
"Seriously?" is not an argument. And in this context it is—ironically—a very unserious way to respond. If I had to guess, I'd say it's probably geared more towards being a vehicle for communicating some sort of subtext in the vein of, "You should abstain from asking these sorts of questions because the reasons are so obvious and so well-known that it is a foolish and embarrassing thing to ask, which makes anyone who is asking those questions look foolish and embarrassing."
> dependencys include [...] other blob like things(big code bases, think react) [...] there is a performance penalty for having to many things/big things in git
This is not a self-contained argument. A performance penalty compared to what?
> there is no nice way to keep dependencies up to date in git
Huh? (Alternatively: "How is this relevant?") When you check your dependencies in to the Git repo, you have all the same tools to update your dependencies that you have when you don't check them in.
- pinkgolem 3y ago>What's unclear? You linking to Ra and going on other tangends make you seem very trollish/edgelord like. >This is not a self-contained argument. A performance penalty compared to what? Compared to not checking them in? I don't understand what you are trying to say here. >Git repo, you have all the same tools to update So I still need a package manager of my choice & a dependency file to install & update dependencys? That also makes it easy to modify single source files which then only get overwriten on an dependency update as you have no clear separation between source code and dependencys.
- cxr 3y ago> You linking to Ra and going on other tangends make you seem very trollish/edgelord like. Huh? Did you read the essay? There's nothing trollish or edgy about it. It describes exactly the type of response I got in the other thread (and now from you here). > Compared to not checking them in? I don't think you're thinking clearly. You can opt not to check your dependencies in—there's certainly less overhead involved when you don't have your dependencies around compared to having them checked into your repo. But the question then becomes, "How are you going to get your app to build/run if you don't have your dependencies?" We are not talking about building projects with dependencies versus projects that don't have dependencies. Same project, same dependencies. You need these dependencies. That's why they're dependencies. When you say there are performance problems when you have a big Git repo, what are you actually comparing that _to_? > I don't understand what you are trying to say here. I haven't strayed from my goal. I am looking for someone to provide a clear answer to the question, "What is the NPM hypothesis?" In other words, state clearly in quantitative terms how it is that keeping e.g. 12% of your source code in Git and leaving the other 88% (or whatever) to be fetched after you clone the repo and run `npm install` is better than keeping 100% of the source code, dependencies included, in Git? I'll give you an example by what I mean: if I see that you're trying to email someone some artwork and it's a bunch of Windows BMP files or raw TIFFs, I could say something like, "If you save these as PNGs and JPEGs, they will take up less space on disk and will be quicker to download." We can test this. We can figure out if it's true or not. We have a hypothesis that is falsifiable. This is the basis of science. We're doing computer science. We are not asking people their favorite cheeses. We are not even asking them whether static types are better than dynamic types or if functional programming is good and object-oriented is bad. We are talking about version control systems. There are beliefs involved here, but they are not mere beliefs—I'd guess that you have some sort of belief about what makes NPM + Git the "right" way to do things and just checking the dependencies into Git the "wrong" way that can be stated in the form of one or more fact claims that we can scrutinize, do some measurements, work out the math, etc. and figure out whether those claims are true or untrue. I'm asking you to state clearly what your claims are. What are they? > So I still need a package manager of my choice & a dependency file to install & update dependencys? I don't understand this question. Is it a question? It looks like a declarative statement followed by a question mark instead of a period.
- pinkgolem 3y ago>Huh? Did you read the essay? Did I read a multiple page completely irrelevant Metapher... No, I did not. > I haven't strayed from my goal... Irrelevant tangent > How are you going to get your app to build/run? Already mentioned, lockfiles. >We have a hypothesis that is falsifiable. Already delivered multiple: you can test it... Git gets slow when you check in to many changes, esp. changed blobs. Diffs on blobs are unreadable/the version change alone is more readable Separation makes it more difficult to change your depencys, which is good because you can update easily/will prefer to use puplic interfaces. (This one might need a study to verify, but based on experience... Forks are a ton of work) > I don't understand this question. It's an assumption with an ask for clarification. I would the answer to be yes, or no because...