You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

5.0 KiB

Dependency

Dependency of a piece of technology is another piece of technology that's required for the former to work (typically e.g. a software library that's required by given computer program). Dependencies are bad! Among programmers the term dependency hell refers to a very common situation of having to deal with the headaches of managing dependencies. Unfortunately dependencies are also unavoidable. We at least try to minimize dependencies as much as possible while keeping our program functioning as intended, and those we can't avoid we try to abstract (see portability) in order to be able to quickly drop-in replace them with alternatives.

Having many dependencies is a sign of bloat and bad design. Unfortunately this is the reality of mainstream programming. For example at the time of writing this Chromium in Debian requires (recursively) 395 packages LMAO xD And these are just runtime dependencies...

Though dependencies are primarily bad because they endanger whole functionality as such, i.e. "it simply won't run without it", they are also bad for another reason: you have no control over how a dependency will behave, if it will be implemented well and if it will behave consistently. OpenGL for example caused a lot of trouble by this because even though the API is the same, different OpenGL implementations performed differently under different situations and made one game run fast with certain combinations of GPUs and drivers and slow with others, which is why Vulkan was created. It is also why some programmers write their own memory allocation functions even though they are available in the standard library etc. -- they know they can write one that's fast and will be fast where they want it to be.

In software development context we usually talk about software dependencies, typically libraries and other software packages. However, there are many other types of dependencies we need to consider when striving for the best programs. Let us list just some of the possible types:

Good program will take into account all kinds of these dependencies and try to minimize them to offer freedom, stability and safety while keeping its functionality or reducing it only very little.

Why are dependencies so bad? Because your program is for example:

  • more buggy (more fuck up surface)
  • less portable (to port the program you also need to port all the dependencies)
  • more expensive to maintain (and create) (requires someone's constant attention to just keep the dependencies up to date and keeping up with their changing API)
  • less future proof and more fragile (your program dies as soon as one of its dependencies, or any dependency of these dependencies)
  • more bloated and so probably less efficient, i.e. slower, eating up more RAM than necessary etc.
  • less under your control (in practice it's extremely difficult to modify and maintain a library you depend on even if it's free, so you're typically doomed to just accept whatever it does)
  • less "secure" (more attack surface, i.e. potential for vulnerabilities which may arise in the dependencies) -- though we don't fancy the privacy/security hysteria, it is something that matters to many
  • more dangerous legally (reusing work of other people requires dealing with several to many different licenses with possibly wild conditions and there's always a chance of someone starting to make trouble such as threatening to withdraw a license)
  • ...

How to Avoid Them

TODO