4 ms·

It's interesting that you cite package managers that are deeply flawed while not listing the two that are, in my opinion, the best in class around: - The JVM M

It's interesting that you cite package managers that are deeply flawed while not listing the two that are, in my opinion, the best in class around: - The JVM Maven Central repo - Rust's Cargo Also, you never say exactly which product from Wirth you are referring to, I'm assuming Modula 2. If so, all Modula 2 introduced is namespaces at the language level, and while this was a pretty novel idea at the time, it was very simplistic. Also, the reason why Turbo-Pascal and family were fast was because the compilers were not just single pass but would abort on the first error. I can't think of any reason why I'd trade the current compilers I use on a daily basis (mostly Kotlin and Rust) to go back to a single pass compiler, even for speed. My time is precious and a fast compiler that then forces me to spend three times as much time writing and correcting my code is not a good use of my time.

PaulHoule 5y ago
I did mention maven. The advantage that Javascript has over Java in this respect is that in Javascript module A can import version B.1 of module B and module C can import version B.2 of module B and it works almost always. Contrast that to the Guava - Hadoop incompatiblity in which a tiny change to Guava that broke HDFS in an racy way got Hadoop stuck at Guava 13 so you have the choice of going with G13 forever, ditching Hadoop, or ditching Guava. I think that one is the worst diamond dependency in Java ever, but it is one of the scaling problems that maven has as the number of imports goes up, it might not be the worst one limiting what you can do with maven. (e.g. if you have a platoon of developers and a corresponding number of projects you might be able to complete a build that downloads SNAPSHOT(s) about 0.5 of the time)
- hota_mazi 5y ago
  You're over dramatizing. For one instance of the Guava/Hadoop incident (which could happen just the same in any env), there are millions of builds that are happening every day that work just fine with the JVM + Maven Central repo combination. And as opposed to the Javascript repos, you cannot delete anything on a Maven repo once it's been uploaded there.

PaulHoule 5y ago

I did mention maven. The advantage that Javascript has over Java in this respect is that in Javascript module A can import version B.1 of module B and module C can import version B.2 of module B and it works almost always. Contrast that to the Guava - Hadoop incompatiblity in which a tiny change to Guava that broke HDFS in an racy way got Hadoop stuck at Guava 13 so you have the choice of going with G13 forever, ditching Hadoop, or ditching Guava. I think that one is the worst diamond dependency in Java ever, but it is one of the scaling problems that maven has as the number of imports goes up, it might not be the worst one limiting what you can do with maven. (e.g. if you have a platoon of developers and a corresponding number of projects you might be able to complete a build that downloads SNAPSHOT(s) about 0.5 of the time)

hota_mazi 5y ago
You're over dramatizing. For one instance of the Guava/Hadoop incident (which could happen just the same in any env), there are millions of builds that are happening every day that work just fine with the JVM + Maven Central repo combination. And as opposed to the Javascript repos, you cannot delete anything on a Maven repo once it's been uploaded there.