the current typical aproach to "code reuse", specifically - librarys, is TRASH

picture a venn diagram or some shit like that of every potential (somewat high 
level, like ui) library users needs:
it will look like a bunch of hairy irregular shapes with some overlap and tons 
of hairs extending into outer space
the current aproach to writing librarys is to take this diagram and draw a 
fence around an arbitrary part of it, making a futile attempt at accomplishig 
the inpossible task of "covering everybodys needs". it doesnt, and will never 
cover everyones needs - cuz of the space hairs. some librarys have bigger 
fences than others which means library is fatter and more disgusting and the % 
of hairs outside the fence is a bit smaler, but no matter how bloated a piece 
of shit u end up using it never fits ur requirements exactly
in practice what u end up with in every single case without exceptions is: 
disgusting morbidly obese type3000 diabetes lardberg of a "program" that wasnt 
easy to write (cuz u had to adopt the contorted mindset of the tortured souls 
trying to please evryone, the library authors), isnt easy to extend, read or 
maintain, and doesnt even do exactly what u wanted, cuz u had to deform ur 
vision to fit the library rather than the other way around

now that the fact that librarys fukcing sukc has been established, wat should 
you do? its stupid to write the same shit over and over again, which is a 
strategy many people (understandably) turn to

ladys and gentlemans, im pleased to announce, the solution is simpaL:
rather than viewing libarys as static unchangable items that exists entirely 
"outside" of ur program, think of them as basic nuts and bolts that become 
fully integrated parts of ur finished product. these parts should just be ultra 
basic, solid implementations with no bells and whistles watsoever, the fence 
should be placed around the INTERSECTION of all potential users needs rather 
than the incomplete union. only the stuff that is more or less guaranteed to be 
on evrybodys requirement list makes it into the libary.
when u need a bolt, grab a standard part from shelf, take the grinder and 
welder to it if necessary, watever u need for ur specific use case

u can imagine in practice there would, if sufficient recurrent demand exists, 
turn up forks of these ultra basic "root implementations", that are fatter and 
more specialized in some direction. it might in many cases make sense to pick 
one of these as your starting point, if they are closer to the exact part u need

this makes evrybodys lifes easier, dramaticaly improves the kvalitét of both 
librarys and programs:
the libraries are easier to write and transform into their permanent final 
state,  they no longer have users who depend on api not changing etc, all users 
have already frozen some earlier snapshot of the code for their projects.
the programs end up as lightweight as they can be, fully specified by their 
source with no stupid dependencies, and as close to the authors original vision 
as he wishes

my goodness, it appears ive just fixed the entire software industry
u r welcome 

as a litle end note, the kind of thinking presented here also aplies to the 
finished programs themselfs, in adition to the libarys used to bild them. 
gorrectly designed program has a clearly stated purpose and does exacly vat is 
necessary to fulfil this purpose and nothing else. the design is clean af, and 
does not include extensive facilities for "configuring the program". if you 
need any kind of unusual configuration or additional functionality, u just open 
up the hood and make the required modifications. u might think that its 
inconvenient to recompile every time you have to do this, but this is a symptom 
of a broken environment rather than anything else. compiling code is actually 
an automatic process, even though systems currently in use obscure this fact