BLU Discuss list archive

But nooooo! Witness GTk. What *doesn't* it do? It
includes Graphene to do vector math. It does UTF-8 and language
handling. It has everything and a marching band: 800K lines of code.
Maybe your distro is different, but every GTk application on my
computer spews GTk warnings by the dozens to camouflage any real
warnings. 

All these functionalities should be curated by the application's
developer, not tossed into an already monstrous toolkit.

When I write an extra 100 lines of code to avoid incorporating yet
another library, I'm lectured haughtily: "Don't reinvent the wheel."
And yet these people drag in a wheel, tire, inner tube, rim strip, hub,
cones, bearings, axle, 36 spokes with nipples and a coaster brake, when
all they really needed was one spoke nipple.

And man, don't they just love to require the latest version of every
library they use? That's OK if you use a rolling release like Void, but
it really sucks with Debian/Devuan stable. And then there are those
developers who think it's fun to modify the interface (not
implementation) of their library to break every application that worked
with the old version?

Just use PIP! Just use UV! Just make a Python specific to your program.
Who cares if your backups take hours and terabytes? And what's this
absurdity of Python library developers writing non-timing-critical
Python libraries in C? Geez Louise!

I'm not going to rewrite Tk for every application, but I sure don't
need a two ton toolkit: In a sane world I could pull in what I need
a-la-carte.

Markw, I'm not defending pre-compiled shared libraries: Anybody could
predict the problems. But of course, if every library, before
compilation, was less than 1000 lines, perhaps less than 100 lines,
with today's wildly fast computers a make file could compile the whole
thing in a couple minutes, and if there were some stupid error or
warning it could be fixed with an #IFDEF or similar, and then sent back
to the library developer.

SteveT

Steve Litt 

http://444domains.com