Hacker News Reader

Comment by doktrin | Hacker News Reader

I think it helps to look at the scope of the analogies being presented. For instance, the friction of installing & configuring Postgres is compared unfavorably to MySQL. Objectively speaking, those are pretty minor differences (i.e. installing Postgres is easy). However, the point that was being made was that even minor increases in "friction" can negatively impact adoption.

No-one is saying Maven / Gradle / Ant are terrible package management systems. However, when compared against tools used in other popular languages (ruby gems, pip, NPM), it's fair to argue that other language's package management systems are more fluid - in that neither of them require prior configuration and work quite well outside of an IDE.

View on HN

Maybe these other systems are more fluid, but their are also a lot weaker in what their platform gives them. What I mean by this is that the Java world never needed the extra rvm, virtualenv, etc.

The complexity of dependency management doesn't come from declaring dependencies, but from managing conflicts over time and being able to create isolated environment.

Even if many call it the "jar nightmare", I don't know other systems that offer better isolation.

I think you've misunderstood the point I was making, which makes sense in context of the video in the OP. I'm not arguing NPM > Maven. I'm arguing NPM is conceptually simpler and easier for a newcomer to use than Maven.

Namely, the speaker made reference to "weaker" DB technologies being used due simply to a frictionless barrier to entry. Mongo was cited as one example. The use of MySQL over Postgres was another. This is basically taken verbatim from the presentation in the video.

This isn't about which systems are "better" or "worse", but which are simpler to get up and running with. Mongo is super duper simple to install and configure. So is NPM. Managing complexity is a real and valid concern, but also not what we're talking about here.

What I wanted to suggest is that: at the tool level npm, gem, pip are simpler to get started. But I don't think that's the case at the env level where you'll need more tools.

So while I've used some wrong words in my comment, I was still (trying at least) referring to simplicity vs complexity.

PS: I've never been very fond of other complexities introduced by the maven approach, but that's a different (and probably longer) story.

Yeah, that's what I'm disagreeing with.

Maven doesn't require an IDE and uses a convention over configuration based approach where it will run against the public repo with zero config.

Moreover, it's significantly 'more fluid' due to the ability to ship assembled fat binaries that have all of their dependencies packaged with them. No need to worry about which version of what is installed on this machine.

I think you glossed over the 'configuration' that adds friction to Maven adoption. Namely, the pom.xml file. You could argue that its complexity is typically overstated, but the fact remains that it exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

> No need to worry about which version of what is installed on this machine.

That's not a concern when using NPM (out of the box), and when using virtualenv it's not a concern when using pip (which most Python devs do).

> the fact remains that it [Maven] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

Are you saying that when developing in Node, you don't have to interact with npm or other build & deployment utilities? End-users of packaged Java applications don't have to interact with Maven any more than end users of packaged C applications have to interact with Make.

I was probably not clear. 'It' refers quite specifically to pom.xml, not Maven as a whole.

Thus :

> the fact remains that it [pom.xml] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

Again, I would like to highlight that this entire discussion should be viewed through the lens of friction vs. frictionless tools, and what that means for community adoption.

A big part of the ease of use of package managers comes from implicit trust in the maintainers of the repositories. Convention over configuration dictates you as a node dev trust the NPM repos. Ditto for ruby gems.

Like most things java related maven is very extensible from an env perspective. People complain about java programs/tools being over engineered but in this case it's a good thing.

One of the great things about maven is that you can trivially point it to a repo you control that is shared across a team or even an entire corporation. This allows whitelisting of packages, confirmed trusted versions, and consistency across different applications (my app and you app both use library X and we know its the same jar).

How many of you actually verify the origin of the modules and libraries you use as dependencies?

I think you got it backwards. Maven doesn't support any form of authentication or verification for packages. So you better trust the network you're on, the core network, and the remote repository.

Maven central and other repositories contain a lot of software, under many different licenses. So unlike, say, apt-get or rpm, you can't always be sure that what you're getting is free/open source software. Be careful with the licenses!

Reply on news.ycombinator.com