Update
This commit is contained in:
parent
d44127c798
commit
e8579f4b86
23 changed files with 1753 additions and 1711 deletions
12
bloat.md
12
bloat.md
|
@ -44,7 +44,17 @@ One of a very frequent questions you may hear a noob ask is **"How can bloat lim
|
|||
|
||||
The **path of [degeneracy](degenerate_software.md)** drawn in the graph shows how from a certain breaking point (which may actually appear at different places, the diagram is simplified) many software projects actually start getting less powerful and useful as they get more complex -- not all, some project really do stay on the path of increasing their "richness", but this requires great skills, experience, expertise and also a bit of lucky circumstances; in the zone of huge complexity projects start to get extremely difficult to manage -- non-primary tasks such as organization, maintenance and documentation start taking up so many resources that the primary task of actually programming the software suffers, the project crumbles under its own weight and the developers just try to make it fall slower. This happens mostly in projects made by incompetent [soydevs](soydev.md), i.e. most today's projects. { Thanks to a friend for pointing out this idea. ~drummyfish }
|
||||
|
||||
Please note there may arise some disagreement among minimalist group about where the band is drawn exactly, especially old Unix hackers could be heard arguing for allowing even trivial programs, maybe as long as the source code isn't shorter than the utility name, but then the discussion might even shift to questions like "what even is a program vs what's just a 10 characters long line" and so on.
|
||||
Please note there may arise some disagreement among minimalist group about where the band is drawn exactly, especially old Unix hackers could be heard arguing for allowing (or even requiring) even trivial programs, maybe as long as the source code isn't shorter than the utility name, but then the discussion might even shift to questions like "what even is a program vs what's just a 10 characters long line" and so on.
|
||||
|
||||
As a quick [heuristic](heuristic.md) for judging programs you can really take a look at the lines of code (as long as you know it's a simplification that ignores dependencies, formatting style, language used etc.) and use the following classes (basically derived from how [suckless](suckless.md) programs are often judged):
|
||||
|
||||
- < 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.
|
||||
- 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.
|
||||
- more: Basically just [bloat](bloat.md), some operating systems can perhaps argue they are comparatively small even within this category, but as a matter of fact very few people can manage a codebase this big, issues of bloat start to play a very significant role here, the project should most likely be split or rewritten from scratch in much more simplified way.
|
||||
|
||||
Yes, **bloat is also unecological** and no, it cannot be fixed by replacing fossil fuel cars with cars that run on grass and plastic computers by computers made from recycled cardboards mixed with composted horse shit. It is the immense volume of human ACTIVITY that's required by the bloated technology all around the globe that's inherently unecological by wasting so much effort, keeping focus on maximalism, growth and preventing us from frugality and minimizing resource waste. Just as any other [bullshit](bullshit.md) that requires immense resources to just keep maintaining -- great complexity is just absolutely incompatible with ecology and as much as you dislike it, to achieve truly eco-friendly society we'll have to give up what we have now in favor of something orders of magnitude more simple and if you think otherwise, you are just yet too unexperienced (or remained purposefully ignorant) to have seen the big picture already. Consider that your program having bullshit dependencies such as [Python](python.md), [JavaScript](js.md), [C++](cpp.md), [Java](java.md), [OpenGL](opengl.md), [Vulkan](vulkan.md), [GPU](gpu.md), [VR](vr.md) sets, gigabytes of [RAM](ram.md) etcetc. requires having the inherently unecological system up, it needs millions of people doing bullshit jobs that are inherently wasting resources, increasing CO2 and making them not focus on things that have to be done -- yes, even if we replace plastic straws with [paper straws](greenwashing.md). All those people that make the thousand pages standards that are updated every year, reviews of those standards, writing tons and tons of tests for implementations of those standards, electing other people to make those standards, testing their tests, implementing the standards themselves, optimizing them, all of that collectively needing many billions of lines of code and millions of hours of non-programming activities, it all requires complex bureaucracy, organization and management (complex [version control systems](vcs.md), wikis, buildings, meeting spaces, ...) and communication tools and tons of other bullshit recursively spawning more and more waste -- all of these people require cars to go to work every day (even if some work from home, ultimately only a few can work from home 100% of the time and even so millions others need to physically go to factories to make all those computers, electricity, chair, food and other things those people need), they require keeping a high bandwidth 100% uptime global Internet network maintained, all of this requiring extra buildings, offices, factories, roads, buildings for governments overseeing the building of those buildings, maintenance of those roads etcetc. A newbie programmer (99.99999% programmers in the field nowadays) just don't see all this because they lack the big picture, a woman forced into programming has hard time comprehending an if statement, how do you expect her to see the deep interconnections between technology and society -- she may know that OpenGL is "something with graphics" and it's just there on every computer by default, she can't even picture the complexity that's behind what she sees on the screen. Hence the overall retardation. You just cannot have people living ecologically and at the same time have what we have now. So yes, by supporting and/or creating bloat you are killing the planet, whether you agree with it or not. No, you can't find excuses out of this, no, paper straws won't help, just admit you love point and click "programming without math" of your own shitty Minecraft clones in Godot even for the price of eliminating all life on Earth, that's fine (no it's not but it's better to just not bullshit oneself).
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue