Update
This commit is contained in:
parent
6a169e2f14
commit
66fe12a69c
16 changed files with 1814 additions and 1711 deletions
2
bloat.md
2
bloat.md
|
@ -50,7 +50,7 @@ As a quick [heuristic](heuristic.md) for judging programs you can really take a
|
|||
|
||||
- < 10: Extremely small but may be useful, may be also too trivial for such small size to be justifiable, can aim to be completely bug-free. Example could be the [cat](cat.md) program.
|
||||
- 11 to 100: Very small, can be debugged to a great level, many greatly useful utilities, e.g. [compression](compression.md) programs, may fit this class.
|
||||
- 101 to 1000: Quite small "bigger" kinds of programs, often very minimalist implementations of programs that are usually not minimalist in nature like window managers, interactive text editors, web browsers and so on.
|
||||
- 101 to 1000: Small "bigger" kinds of programs, often very minimalist implementations of programs that are usually not minimalist in nature like window managers, interactive text editors, web browsers and so on. Simplified version of [comun](comun.md) language, called *minicomun*, fits here.
|
||||
- 1001 to 5000: Still considered small, a bit more "feature rich" kind of previous class, you may find minimalist 3D games here, quite powerful programming languages, libraries handling complex file formats (that weren't designed to be minimalist) etc. Currently a lot of [LRS](lrs.md) programs like [SAF](saf.md), [small3dlib](small3dlib.md) and [comun](comun.md) would fall here.
|
||||
- 5001 to 10000: Often imposed upper limit on suckless programs, these programs aren't the smallest possible but may still be called minimalist, they are easily manageable by a single man without much hassle, anyone can modify them and there is a comfortable margin for implementing many "comfort" and fancy features that aren't complete [BS](bullshit.md). [Anarch](anarch.md) might be given as an example (if we subtract lines of code taken by game data and count only pure engine code).
|
||||
- 10001 to 100000: Here things start to be called real bloat but may still be accepted as a compromise, not an "insanely bloated" program, we have to judge on a case by case basis as the transition towards bloat is gradual, but generally projects here must focus on not growing bigger, priority should be on minimizing. We have to consider anything here bloat unless proven otherwise. Minimalist projects end up here when trying to combine minimalism with some mainstream concept, e.g. implementing a complete operating system with all the standard features, trying to reimplement some mainstream, non-minimalist program etc. Example is [tcc](tcc.md), the C compiler that has a little over 20000 LOC. Also many "good old" mainstream programs like [Doom](doom.md) fall here.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue