A Rebuttal of Some Nihilistic Sophistry

I occasionally see others reference this article being rebutted when discussing ideals, as if excuse
to purposefully fall short of them.  His pilpul employs rhetoric and misleading he playfully calls a
``fib'' to convince unwary readers that ``All non-trivial abstractions, to some degree, are leaky''.

The sophistry may be found here; the author's other work has this attack on principles unsurprising:
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions

The sophistry begins by analogizing TCP, lying about its reliability guarantees; sans equating side-
channels with abstractions leaking, this is the entire substance thereof, providing meagre examples.

Beginning with the Internet, it provides no guarantee of transmission.  Network programming requires
accepting this caveat and accomodating it; it's inherent to the problem and can't be done away with.
In contrast, sending messages throughout a lone machine can be done perfectly reliably, meaning this
isn't part of the problem, although poor interfaces may still pretend failure is possible, requiring
a good programmer to handle this anyway.  As for message integrity, this is reasonably provided with
checksumming, which only truly guarantees that checksum passes; improvements in integrity guarantees
end with ensuring perfect integrity through all of the prior methods and by sending multiple copies.
Addressing speed of the networks is unnecessary, as no guarantees are made by such Internet systems.

Addition of integers of arbitrary sizes is another abstraction, one which can be and has been stated
in hardware.  That typical interface is that proper one, accepting two or more integers for addition
and returning the result, which must generally be allocated from unused storage.  It's inherent with
storage allocation that there may be insufficient storage, and so it may fail.  Another interface is
to require the storage for the sum to be given as a parameter, and then it will never fail; this can
take the form of a separate parameter, reuse thereof, indication of overflow, or other combinations.

To call that former interface a ``leaky abstraction'' is misguided.  It's perfectly reasonable for a
system to lack a concern for such tangential considerations as minor storage management; such is the
domain of the machine.  Importantly, a system which lets such tangents ``leak'' permits an operator,
the opinion of which is all that truly matters, to decide how to carry on, which can include options
such as substituting results, retrying operations, ending the calculation early, adding memory, etc.

Addition of arbitrary integers is linear in time and space, but adding integers of known sizes makes
these become constant.  Overflow can be a concern unless saturation, modular, or other arithmetic is
used, which is a valid method of eliminating this.  Be made aware specifying correct systems becomes
isomorphic to specifying abstractions which don't ``leak''; I'll now address his choice of examples:

He pretends iterating over a multi-dimensional array is a ``leak''; where be the leaks when ordering
is specified?  If operations more efficient should be made equivalent to others, trivial solution is
to make that more be less; it's obvious that array iteration in any dimension can be made equivalent
through merely not eliding those calculations sequential access makes implicit.  That note regarding
caching boundaries is more onerous, with solutions being to avoiding caching or fit all inside such.

I refuse to address the SQL or C++ examples.  I'll avoid those abstractions, which I'm sure do leak.

The proper way to treat a network file system as equivalent to a local is to use timeouts, if we are
to pretend access time is being measured for this.  Poor systems only providing poor implementations
aren't an indictment of the concept.  That stupid concept of ``forward files'' is addressed by ``The
UNIX-HATERS Handbook''; an idiot designing trivially failing email forwarding methods is immaterial.

Pretending windshield wipers, headlights, roofs, and heaters somehow form a broken guarantee of cars
being safe to drive recklessly in bad weather has me wanting that he had tried doing so, beforehand.

Current systems for current people aren't concerned with eliminating side-channels such as timing or
power consumption, but it's clear systems with constant rather than variable characteristics can be.

His following examples of poor systems using broken abstractions which actually make life harder I'd
figure are true, but his attacking poor systems and then making claims about all abstraction foments
my ire.  Were he experienced with better systems, perhaps he wouldn't've made such incorrect claims,
but it's clear to me his business is to work with such poor systems, encouraging them to come to be.

In writing this article I'm using abstraction to communicate my thoughts through writing, as opposed
to cracking open another's skull and attempting to place my thoughts directly, although I'd at times
prefer doing that; the proper way to communicate with a man who debates using language for spreading
thought isn't speech, which has been denied, but violence, after which understanding will be coming.
There are ``semantic primes'' that underlie a language and evade description therein, but to pretend
such somehow invalidates a language is obvious subversion which should be stomped out without mercy.

Importantly, man should never cease in the strive towards ideals, even those which are unachievable,
if any actually are.  To lack this stepping is spiritual death and acceptance of mediocrity, which I
don't find surprising given this author's other work; unsatisfied with merely killing his spirit, he
wrote that article which has convinced others that mediocrity is acceptable and even necessary.  Men
such as myself who strive to write correct and idealized software don't suffer these hallucinations.