This commit is contained in:
Miloslav Ciz 2023-11-13 16:29:28 +01:00
parent ba42573522
commit 62ed2dfb7e
9 changed files with 22 additions and 14 deletions

View file

@ -4,6 +4,8 @@ Dependency of a piece of [technology](technology.md) is another piece of technol
Having many dependencies is a sign of **[bloat](bloat.md) and bad design**. Unfortunately this is the reality of mainstream programming. For example at the time of writing this [Chromium](chromium.md) in [Debian](debian.md) 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](opengl.md) 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](vulkan.md) 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](software.md) development context we usually talk about software dependencies, typically [libraries](library.md) and other software [packages](package.md). 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:
- [software](software.md)