Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Two months ago, someone made one for Servo, in Rust: https://dirkjan.ochtman.nl/files/servo-graph.svg

https://crates.io/crates/cargo-graph can be used to produce them easily.

Rust is somewhere between Ruby and Node here: leaning towards small modules (one of my crates is in this graph, and it exports four functions), but not to the same level.

  > It would be neat to visualise which language/framework has
  > the worst case of dependency hell

So, one thing I've come to realize is that different people have different opinions on what "dependency hell" even means. If you have a lot of dependencies, but your tooling reliably makes it easy to get them, build them, and upgrade them, is that hell?

View on HN

There are a number of objective measures of cyclomatic complexity in software. These metrics show that the higher the complexity, the lower the cohesion of the code[1].

Code that is complex, and has low cohesion, is harder to understand, and therefore harder to change. It's the elephant you have to push on every time you want your program to do something new[2].

  [1] https://en.wikipedia.org/wiki/Cyclomatic_complexity
  [2] https://www.youtube.com/watch?v=rI8tNMsozo0

"Dependency hell" might be subjective, but tools that reduce the upfront cost of increased dependencies don't remove the other burdens from you, the developer. In fact they often allow you to produce an impenetrable, unrecoverable tangle more quickly than doing without them.

Edit: Just realized who I responded to... "But, you knew all that."

  > Edit

So, what's interesting is, I would often consider many small bits to have a _lower_ cyclomatic complexity number. That is, whenever I've used tools that measure this kind of thing, the solution is always to take the big things and break them up into many, smaller bits. It's possible that this is bias in the tooling, though.

I think some of this comes down to individual preference as well. It's like that joke, would you rather fight one horse-sized duck or 100 duck-sized horses? In this admittedly very stretched metaphor, the former are relatively monolithic codebases, and the latter are relatively modular ones. I know that I used to prefer one hundred-line class to ten ten-line classes, but now, much much prefer the latter. My experience talking to people about this is that people fall somewhere on this line, often in different places, and that makes it harder to understand. The action that I'm taking to reduce complexity can often be perceived as increasing complexity, depending on where the other person falls on that line.

Lots-of-little-ones (LOLO? LOLO) is the right answer in a number of cases. One big god service? No; microservices (lots-of-little-ones). Large many-lined functions with copious branching and conditionals? No, LOLO. Big teams with multi-hour status meetings? No... LOLO. One big integration at the end of the project? No...

That dependency diagram for Servo actually looked relatively clean. You can clearly see which elements are library or utility code. The visualization would probably be better as a three-dimensional model with weighting.

For OO practice, state of the art is SOLID (with a sprinkling of RAII if you happen to be using C++). SOLID leads you straight down the path of LOLO. Small increments FTW.

Dependency hell for me is when I have one target depending on two or more libraries that result in conflicts that can not be resolved without resorting to butchering one or more of the libraries.

One nice example that springs to mind here is that there is a package in some linux C library that defines a 'list', which in turn conflicts with lots of other libraries and applications that also wish to define 'list' but in their own scope.

This one is solved by namespaces.

> but your tooling reliably makes it easy to get them, build them, and upgrade them, is that hell?

Dependencies are never free. If you have a bunch of dependencies and not have too much resources it's still hell. Managing dependencies is not hard because of the tooling. It's hard because a dependency upgrade could cause pain, or the current version is buggy but the fix inside the upgrade works, but there will be another bug and so on.

Right, this is what I mean: different people mean different things by "dependency hell". Difficulty of upgrading is certainly a possible meaning, but it's not a unified term.

actually people just trust too much other people. but since you don't know anything about other people you should not trust them and especially not trust their ability to create good code.

Wrong. You trust yourself too much. A vibrant, well-documented and tested framework will likely be better than your own one-off code

If you really believe what you say, why are you using Go (or Java, or Rust or whatever) at all? Someone else wrote it...

Reply on news.ycombinator.com