4 ms·

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

>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...
  - cxr 3y ago
    I'm sorry, but I'm not going to continue the discussion this way. It's not productive.
    - pinkgolem 3y ago
      Sure if you want Would have really liked an explanation why: Git gets slow when you check in to many changes, esp. changed blobs. Is not provable, but well.

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...
- cxr 3y ago
  I'm sorry, but I'm not going to continue the discussion this way. It's not productive.
  - pinkgolem 3y ago
    Sure if you want Would have really liked an explanation why: Git gets slow when you check in to many changes, esp. changed blobs. Is not provable, but well.