[alexmingoia]

Why is that?

To be clear the lack of “shared” dependencies does not necessitate code duplication. By shared dependencies I’m talking about languages (Haskell for example) where only one version of a library can be used, which results in the diamond dependency problem (predictably so!).

Let’s say file A references file B and C, and files B and C both reference D. D doesn’t need to be duplicated.

If all includes are qualified/namespaced there is no diamond dependency problem, and the compiler/runtime can reuse the same code for multiple references to the same file.

[kubanczyk]

> Let’s say file A references file B and C, and files B and C both reference D. D doesn’t need to be duplicated.

Yes, if an ecosystem does not attempt to ensure that D is at a single version, which is both B-compatible and C-compatible, it moves a mountain of complexity onto A.

It might not be apparent for a small program that only uses standard library and never experiences diamond dependencies at all. But the complexity here is that

1. A might get a D1 object/structure/result from B, and later

2. A might get a D2 object/structure/result from C, and then

3. Some code may be needed to ensure D1 compatibility with D2, if they interact. This problem is better to be resolved in an ecosystem than in A.