depth=2
A common observation of language ecosystems that reach a certain amount of critical mass in adoption is that they start to have an explosion in the depth of dependency trees when building applications.
The more I think about the problem, the more it resembles evolutionary biology. In natural ecosystems, resources are limited. This creates a selective pressure that regulates the growth of organisms. Developer ecosystems lack a naturally regulating force.
Imagine a language that imposed a restriction on packages such that:
- There are three kinds of packages: library, framework, application
- A library can only depend on the standard library (
depth=0
) - A framework can only depend on the standard library, or user libraries (
depth=1
) - An application can depend on frameworks, user libraries, and the standard library (
depth=2
)
The package ecosystem gets completely flattened to a maximum tree depth of 2.
Such a constraint, imposed on the entire ecosystem, might change the way it organizes. Serious consideration would be put into pulling in a package: congrats, you’re now a framework, the reusability of your code has reduced logarithmically.
I can imagine relaxing the restriction on libraries, or perhaps an additional type of package called an interface. Interfaces would be able to depend on each other, but they can only contain interface definitions – no implementations. You can imagine such an HTTP
interface package that exports Request
and Response
. It would then be easy for a language maintainer to identify which of these interfaces are candidates for promotion into the standard library.
Inevitably, someone would try to circumvent the limitation. If I were the language maintainer, I would probably attempt to blacklist the tool in my implementation. But I am not a language maintainer, and I’m certain that would result in a beautiful scandal – complete with angry people who do not, and will never, use the language trying to influence its direction.