Dependency
Dependency of a piece of [1]technology is another piece of technology
that's required for the former to [2]work (typically e.g. a software
[3]library that's required by given computer [4]program). Dependencies are
[5]bad! Among programmers the term dependency hell refers to a very common
situation of having to deal with the headaches of managing dependencies
(and [6]recursively dependencies of those dependencies). Unfortunately
dependencies are also unavoidable. However 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 [7]portability)
in order to be able to quickly drop-in replace them with alternatives. It
turns out with good approach we can minimize dependencies very close to
zero.
Having many dependencies is a sign of [8]bloat and bad design.
Unfortunately this is the reality of mainstream "[9]modern" programming.
For example at the time of writing this [10]Chromium in [11]Debian
requires (recursively) 395 packages LMAO xD And these are just runtime
dependency packages, we aren't even counting all the hardware features
each of this package relies on etc...
Though dependencies are primarily bad because they endanger whole
functionality of a program 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. [12]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 [13]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 [14]software development context we usually talk about software
dependencies, typically [15]libraries and other software [16]packages such
as various [17]frameworks. 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:
* [18]software
* [19]libraries
* [20]compiler supporting specific language standard, extensions
etc.
* [21]build system
* [22]GUI capabilities
* [23]operating system and its services such as support of
[24]multitasking, presence of a [25]window manager, [26]desktop
environment, presence of a [27]file system etc.
* ...
* [28]hardware
* sufficient [29]computing resources (enough [30]RAM, CPU frequency
and cores, ...)
* [31]graphics card with supported features
* [32]floating point unit and other [33]coprocessors
* CPU features such as special instructions, modes, ...
* [34]network/[35]Internet connection
* [36]mouse, [37]speakers and other I/O devices
* ...
* other:
* know-how/education: Your program may require specific knowledge,
e.g. knowledge of advanced math to be able to meaningfully modify
the program, or nonnegligiable amount of time spent studying your
codebase.
* running cost: e.g. electricity, Internet connection cost
* culture: Your program may require the culture to allow what it is
presenting or dealing with.
* ...
Good program will take into account ALL kinds of these dependencies and
try to minimize them to offer [38]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 [39]buggy (more [40]fuck up surface)
* less [41]portable (to port the program you also need to port or
replace all the dependencies)
* more expensive to [42]maintain (and create) (requires someone's
constant attention to just keep the dependencies up to date and
keeping up with their changing API)
* less [43]future proof and more fragile (your program dies as soon as
one of its dependencies, or any dependency of these dependencies...)
* more [44]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
[45]fork, modify and maintain a library you depend on even if it's
[46]free as you just take up another project to learn and maintain, so
you're typically doomed to just accept whatever is offered to you)
* less "secure" (more [47]attack surface, i.e. potential for
vulnerabilities which may arise in the dependencies) -- though we
don't fancy the [48]privacy/[49]security hysteria, it is something
that matters to many
* more dangerous [50]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)
* more complicated to developed and work with, customize, modify etc. --
a nice program without dependencies is built very simply: you just
download it and compile it. A program with tons of dependencies will
require a complex set up of all the dependencies first, making sure
they're of required versions, and then you have to build EVERYTHING of
course, usually adding the need for some complex build system to even
make recompiling bearable.
* ...
Really it can't be stressed enough that ALL dependencies have to be
considered, even things such as the [51]standard library of a programming
language or built-in features of a language that "should always" come with
the language. It is e.g. common to hear C programmers say "I can just use
float because it's part of C specification and so it has to be there" --
well technically yes, but in practice many C implementations for some
obscure platforms will end up being unfinished, incomplete or even
intentionally non-compliant with the standard, no standard can really
physically force people to follow it, OR the compiler's floating point
implementation may simply suck (or it HAS TO suck because there's no
floating point hardware on the platform) so much that it will technically
be present but practically unusable. This will mean that your program
COULD work on the platform but DOESN'T, even if some piece of paper
somewhere says it SHOULD. So REALLY REALLY do not use non-trivial features
that you don't really need, it really does help. If you really want to
make your program truly dependency light, always ask something like this:
"If our civilization and all its computers disappear and only the literal
text of my program survives, how hard will it be for future civilizations
to make it actually run?".
How to Avoid Them
TODO
Links:
1. technology.md
2. work.md
3. library.md
4. program.md
5. shit.md
6. recursion.md
7. portability.md
8. bloat.md
9. modern.md
10. chromium.md
11. debian.md
12. opengl.md
13. vulkan.md
14. software.md
15. library.md
16. package.md
17. framework.md
18. software.md
19. library.md
20. compiler.md
21. build_system.md
22. gui.md
23. operating_system.md
24. multitasking.md
25. window_manager.md
26. desktop_environment.md
27. file_system.md
28. hardware.md
29. computing_resources.md
30. ram.md
31. gpu.md
32. fpu.md
33. coprocessor.md
34. networking.md
35. internet.md
36. mouse.md
37. monitor.md
38. freedom.md
39. bug.md
40. fuck_up_surface.md
41. portability.md
42. maintenance.md
43. future_proof.md
44. bloat.md
45. fork.md
46. free_software.md
47. attack_surface.md
48. privacy.md
49. security.md
50. law.md
51. stdlib.md