Why Bloat Is Still Software’s Biggest Vulnerability

[H. S. Teoh]

On Mon, Feb 12, 2024 at 05:48:32PM +0000, Paolo Invernizzi via Digitalmars-d wrote:
> On Monday, 12 February 2024 at 17:30:23 UTC, H. S. Teoh wrote:
[...]
> > Reducing code size is, to paraphrase Walter, to plug one hole in a
> > cheese grater. There are so other many things wrong with the present
> > state of software that code size doesn't even begin to address.
> 
> Hey, at the end the title of the post is: Why Bloat Is Still
> Software’s __Biggest__ Vulnerability Let's start to plug the biggest!
> :-P

I'm skeptical whether it's the biggest. There are many holes in a cheese
grater; plugging each one individually will always leave you with more
holes afterwards. And they are all more-or-less the same size. :-D

However nobody seems willing to entertain the possibility of removing
the cheese grater altogether, which would be a much better solution.


> Long story short, the docker images was the last resource after having
> lost a three hours battle against PIP and conflicting dependencies,
> trying run 2 years old code (python ML environments sometimes is just
> crazy). Note that also using PIP involved GB of download, tensorflow,
> keras, etc

Which is why I said that these are all just holes in a cheese grater.
Conflicting dependencies and the inability to compile old code are
well-known (to me) symptoms of today's model of software development. I
won't go so far as to say that anything requiring GBs of downloads is
inherently broken -- perhaps for some applications, large amounts of
code / data *is* unavoidable. But I can't believe that the *majority* of
dependencies would require such incommensurate amounts of resources.  At
the most I'd expect one or two specialised dependencies that might need
this, not every other package in your typical online code repo.

//

When I was in college in the 90's code reuse was a big topic. Everyone
was talking about coding for libraries so that you don't have to
reinvent the wheel. Eventually that led to DLL hell in the Windows world
and .so hell in the Posix world.  After 30 years, people are moving away
from OS-level dependencies (DLLs and shared libs) to the likes of cargo,
npm, dub, and the like. However, the underlying problem of dependency
hell has not been solved.  I'm at the point where I'm ready to call BS
on the whole concept of code reuse.

So I've gradually come to the conclusion that code reuse, i.e.,
dependencies, is inherently evil, and should be avoided like the plague
unless you absolutely have no other choice. And where it can't be
avoided, it should be as shallow as possible. The best dependencies are
single-file dependencies like Adam's arsd libs, where you can literally
copy the file into your workspace and just compile.  The second best
dependency is the single package, where you copy/clone the files into
some subdir in your workspace and off you go.  The worst kind of
dependency is the one that recursively depends on other packages.  These
should be avoided as much as possible, because it's here that
NP-completeness and dependency hell begin, and it's here where madness
like multi-GB docker images is born.

Copy-pasta is oft-maligned, and I agree that it's evil when it happens
within a project.  But I'm at the point where I'm almost ready to
declare that copy-pasta is actually good and beneficial when it happens
across projects. Much better to just copy the darned code into your
local repo and modify it to whatever you need it to do, than to declare
a dreaded dependency that's the beginning of the slippery slope into
dependency hell and the inclusion of millions of lines of code bloat
into your project.


T

-- 
What are you when you run out of Monet? Baroque.