4 ms·

True but beyond hobby projects this becomes a double-edged sword that swings back at you.

circuit10 4y ago
Could it not have both? Can’t something work like Maven or Gradle but have some nice utility commands to make installing things easy? Or does that already exist?
- mike_hearn 4y ago
  IntelliJ has a dependency browser GUI that can edit your Maven/Gradle builds, but yes you're right, the CLI tooling from other ecosystems is nicer. Unfortunately the lack of robustness isn't. Just today I was debugging a sudden failure of a Python script because someone released a new version of a dependency of a dependency of a dependency which for some reason just fails to install on Ubuntu 20 without a proper error message. In the JVM world there's no such thing as a failure to install a library, because there's no install process at all, and you don't need lockfiles or any of these other hacks to avoid stuff breaking.
- twic 4y ago
  What did you learn first, npm or Maven/Gradle? I started in Java land, and to me, the idea that you would run a command to add a dependency has always seemed a bit weird. The file with dependencies in is part of the source code, and i don't want to modify it at arm's length with a command any more than i want to write code that way.
  - circuit10 4y ago
    I probably learned npm or pip first so I guess it depends on what you’re used to But with npm you can still modify the package.json and it feels simpler than than the Maven XML still (though I have no idea what’s going on with the package_lock file, but I don’t think you’re meant to edit that manually)
  - ye-olde-sysrq 4y ago
    also fwiw, while xml is kind of not very pretty, for most dependencies, you literally google "mydependency maven", click the first link, click the version you want, then literally just copy/paste the XML into your pom.xml. Is it as slick as 1 command? No. But it's certainly not rocket science, and most libraries github readmes even provide you the maven <dependency /> blob, so it's not usually confusing imo. And also, I do want to point out that "just npm -i mything" comes with problems like typosquatting, which is a lot less common in java afaik.
  - nawgz 4y ago
    This is a dinosaur opinion, wow. Would you also avoid generating client types for type-safe API consumption because you have to run a command to do that instead of writing the client yourself? After all, the client is source code for the client
    - Tostino 4y ago
      I don't see these as comparable at all.
      - nawgz 4y ago
        Say more. My package.json is part of source code. I can manually write it myself and run `npm install` afterwards; or I can do both steps via a command. The end result is identical: my package.json has a new package, and my local machine has a copy of that package somewhere too. Why wouldn't I use the command, exactly?
        ElectricalUnion 4y ago
        > The end result is identical Citation needed. Installing npm dependencies in different orders is not garanteed to be deterministic due to npm's package flattening and, before npm 8, plain broken dependency resolution strategy. The package-lock.json is essential to get the same mess that the initial developer got on the same order as his install. > and my local machine has a copy of that package somewhere too. On maven/gradle, like on pnpm, you get one copy of each library. Not 3000x copies of lodash spread around your disk.
        nawgz 4y ago
        > > The end result is identical > Citation needed. What do you mean? You cited it yourself: > Installing npm dependencies in different orders Fortunately, there is no difference in order between running it as a command and adding it and running `yarn install`, since you already had all the other packages locally either way. Anyways, these complaints are ridiculous, I'm sure I could dig into the past and find some broken Maven or Gradle resolutions. Let's see, 10 second time limit: > gradle.lockfile LOL wow. > 3000x copies of lodash spread around your disk LOL
- carimura 4y ago
  Yes especially in an education setting where the level of overhead of Maven/Gradle for a student just learning to program is too high.
nawgz 4y ago
Lol, what? NPM is amazing
- nawgz 4y ago
  These downvotes are absurd. The parent comment asserts, without evidence, that "NPM being easy to use is a double-edged sword that will swing back at you". I have never seen any evidence of this in action. What would it even mean!? Something being easy to use being casted as a negative in-and-of-itself sounds like Stockholm Syndrome. If you'll downvote a long-time NPM user for questioning what's wrong with NPM given how much better it is at navigating the complex corporate environment I sit in than Gradle or Maven, at least leave an anecdote.
  - speed_spread 4y ago
    It's all on you. You brought npm into the discussion which was until then quite generic comparing java builds against "others". You barge into a thread of people praising a certain ecosystem by defending your own turf and trying to convince everyone that your tools are actually ok. What did you expect? Sure bro, use npm, whatever.
    - nawgz 4y ago
      How is it "on me" that stupid "opinions" are being expressed? First of all, the context was: my initial comment's GP: "I do really like how easy the packaging is in Python and JS is", "Maven and Gradle are a bit of a pain to configure in comparison" my initial comment's parent: "True but beyond hobby projects this becomes a double-edged sword that swings back at you." This comment CONTINUES to be a naked assertion based on nothingness. The negative points about NPM I've heard are: * You should never touch human-readable files with CLIs (like package.json) * NodeJS imports make many files because it's interpreted code * running a command to install a package is "weird" and doing it manually is better * Something about module resolution that was fixed half a decade ago but still didn't impact most shops that avoided drowning in libraries You can't be serious that this is meaningful feedback.

Could it not have both? Can’t something work like Maven or Gradle but have some nice utility commands to make installing things easy? Or does that already exist?

mike_hearn 4y ago
IntelliJ has a dependency browser GUI that can edit your Maven/Gradle builds, but yes you're right, the CLI tooling from other ecosystems is nicer. Unfortunately the lack of robustness isn't. Just today I was debugging a sudden failure of a Python script because someone released a new version of a dependency of a dependency of a dependency which for some reason just fails to install on Ubuntu 20 without a proper error message. In the JVM world there's no such thing as a failure to install a library, because there's no install process at all, and you don't need lockfiles or any of these other hacks to avoid stuff breaking.
twic 4y ago
What did you learn first, npm or Maven/Gradle? I started in Java land, and to me, the idea that you would run a command to add a dependency has always seemed a bit weird. The file with dependencies in is part of the source code, and i don't want to modify it at arm's length with a command any more than i want to write code that way.
- circuit10 4y ago
  I probably learned npm or pip first so I guess it depends on what you’re used to But with npm you can still modify the package.json and it feels simpler than than the Maven XML still (though I have no idea what’s going on with the package_lock file, but I don’t think you’re meant to edit that manually)
- ye-olde-sysrq 4y ago
  also fwiw, while xml is kind of not very pretty, for most dependencies, you literally google "mydependency maven", click the first link, click the version you want, then literally just copy/paste the XML into your pom.xml. Is it as slick as 1 command? No. But it's certainly not rocket science, and most libraries github readmes even provide you the maven <dependency /> blob, so it's not usually confusing imo. And also, I do want to point out that "just npm -i mything" comes with problems like typosquatting, which is a lot less common in java afaik.
- nawgz 4y ago
  This is a dinosaur opinion, wow. Would you also avoid generating client types for type-safe API consumption because you have to run a command to do that instead of writing the client yourself? After all, the client is source code for the client
  - Tostino 4y ago
    I don't see these as comparable at all.
    - nawgz 4y ago
      Say more. My package.json is part of source code. I can manually write it myself and run `npm install` afterwards; or I can do both steps via a command. The end result is identical: my package.json has a new package, and my local machine has a copy of that package somewhere too. Why wouldn't I use the command, exactly?
      - ElectricalUnion 4y ago
        > The end result is identical Citation needed. Installing npm dependencies in different orders is not garanteed to be deterministic due to npm's package flattening and, before npm 8, plain broken dependency resolution strategy. The package-lock.json is essential to get the same mess that the initial developer got on the same order as his install. > and my local machine has a copy of that package somewhere too. On maven/gradle, like on pnpm, you get one copy of each library. Not 3000x copies of lodash spread around your disk.
        nawgz 4y ago
        > > The end result is identical > Citation needed. What do you mean? You cited it yourself: > Installing npm dependencies in different orders Fortunately, there is no difference in order between running it as a command and adding it and running `yarn install`, since you already had all the other packages locally either way. Anyways, these complaints are ridiculous, I'm sure I could dig into the past and find some broken Maven or Gradle resolutions. Let's see, 10 second time limit: > gradle.lockfile LOL wow. > 3000x copies of lodash spread around your disk LOL
carimura 4y ago
Yes especially in an education setting where the level of overhead of Maven/Gradle for a student just learning to program is too high.

nawgz 4y ago

Lol, what? NPM is amazing

nawgz 4y ago
These downvotes are absurd. The parent comment asserts, without evidence, that "NPM being easy to use is a double-edged sword that will swing back at you". I have never seen any evidence of this in action. What would it even mean!? Something being easy to use being casted as a negative in-and-of-itself sounds like Stockholm Syndrome. If you'll downvote a long-time NPM user for questioning what's wrong with NPM given how much better it is at navigating the complex corporate environment I sit in than Gradle or Maven, at least leave an anecdote.
- speed_spread 4y ago
  It's all on you. You brought npm into the discussion which was until then quite generic comparing java builds against "others". You barge into a thread of people praising a certain ecosystem by defending your own turf and trying to convince everyone that your tools are actually ok. What did you expect? Sure bro, use npm, whatever.
  - nawgz 4y ago
    How is it "on me" that stupid "opinions" are being expressed? First of all, the context was: my initial comment's GP: "I do really like how easy the packaging is in Python and JS is", "Maven and Gradle are a bit of a pain to configure in comparison" my initial comment's parent: "True but beyond hobby projects this becomes a double-edged sword that swings back at you." This comment CONTINUES to be a naked assertion based on nothingness. The negative points about NPM I've heard are: * You should never touch human-readable files with CLIs (like package.json) * NodeJS imports make many files because it's interpreted code * running a command to install a package is "weird" and doing it manually is better * Something about module resolution that was fixed half a decade ago but still didn't impact most shops that avoided drowning in libraries You can't be serious that this is meaningful feedback.