~sircmpwn/public-inbox

4 4

Your Thoughts on my Rebuttal

Details
Message ID
<87mu8lkljq.fsf@server.domain.com>
DKIM signature
missing
Download raw message
Hello there.  I merely send this email to your public inbox, as you've
yet to respond to that rebuttal of some of your writings I've written:

  http://verisimilitudes.net/2020-03-06
gopher://verisimilitudes.net/02020-03-06

I would normally wait longer, believing you've not yet had the time to
do so, but you've yet to respond to an email with similar thoughts, it
being part of why I chose article over email here, and I wonder if I'm
simply being ignored in this; I'm interested in your thoughts on mine.
Details
Message ID
<20200313141301.kdxlb42fbxny4ugd@nullprogram.com>
In-Reply-To
<87mu8lkljq.fsf@server.domain.com> (view parent)
DKIM signature
missing
Download raw message
I, for the most part, agree with Drew in the three cited articles. 
You've also previously rebutted one of my own articles, and at the time 
I read a few of your other rebuttals. Revisiting it now, I've noticed 
and overarching theme for all your rebuttals: Perfect is the enemy of 
good.

That is, when you perceive a system or tool as flawed or imperfect, it 
is inappropriate for anyone to praise or prefer those systems. Since C 
and POSIX aren't perfect — and they certainly aren't — it's wrong to 
advocate for their use. Sometimes being imperfect simply means they 
don't make the particular trade-offs you personally prefer.

For instance, one of your criticisms of UTF-8 is that it doesn't support 
random access. This is absolutely true, but accessing Unicode code 
points by arbitrary index is virtually always wrong (e.g. combining 
characters, etc.). Your preferred trade-off — giving up one or more of 
UTF-8's benefits in order to have random access — would be awful in 
nearly all practical cases.

In your articles, you compare these existing, imperfect systems to your 
imaginary ideals. Sometimes you document these ideal systems, and 
sometimes we have to guess at what you mean. But, regardless, as they 
say: The devil is in the details. Until you've actually built a real, 
working version of your ideal, you cannot know what you're trading away. 
The real world is messy and full of difficult problems. 

In fact, your ideal, at least as you imagine it, is almost certainly 
unachievable. To quote Mike Acton, "Reality is not a hack you're forced 
to deal with to solve your abstract, theoretical problem. Reality is the 
actual problem." As you build your system, you'll run into trade-offs 
you had not anticipated, that you didn't imagine when comparing existing 
systems to your ideal. And you'd need to make those trade-offs 
appropriately enough for people to buy in, since otherwise nobody would 
use it. You will also make mistakes, and you will not be able to fix all 
of your mistakes.

The major problems with software development today do not stem from the 
flaws or trade-offs of C or POSIX. Not even close. The main enemy of 
good software engineering today is complexity and plain old sloppiness, 
and this would still be the case even if C and POSIX were perfect by 
whatever definition you have in mind.
Details
Message ID
<71901376-4e24-3da8-4100-364ac9067df8@national.shitposting.agency>
In-Reply-To
<87mu8lkljq.fsf@server.domain.com> (view parent)
DKIM signature
pass
Download raw message
You just don't get it, do you? He's not interested in talking to you!

On 2020-03-12 8:58 p.m., Programmer@verisimilitudes.net wrote:
> Hello there.  I merely send this email to your public inbox, as you've
> yet to respond to that rebuttal of some of your writings I've written:
> 
>   http://verisimilitudes.net/2020-03-06
> gopher://verisimilitudes.net/02020-03-06
> 
> I would normally wait longer, believing you've not yet had the time to
> do so, but you've yet to respond to an email with similar thoughts, it
> being part of why I chose article over email here, and I wonder if I'm
> simply being ignored in this; I'm interested in your thoughts on mine.
> 
Details
Message ID
<87eetnlkjp.fsf@server.domain.com>
In-Reply-To
<20200313141301.kdxlb42fbxny4ugd@nullprogram.com> (view parent)
DKIM signature
missing
Download raw message
Well, I suppose it's clear I won't get any thoughts from you, Drew Devault, as I'm being ignored so.
I'm going to update that article soon with thoughts on your Go generics article, as I'd already made
a heavy criticism of that I can recycle for the article; perhaps I'll keep adding to it in this way.

>You've also previously rebutted one of my own articles, and at the time I read a few of your other
>rebuttals. Revisiting it now, I've noticed and overarching theme for all your rebuttals: Perfect is
>the enemy of good.
Perfect is the enemy of good, yes, but there's also that lesser battle of better being enemy to bad.

>That is, when you perceive a system or tool as flawed or imperfect, it is inappropriate for anyone
>to praise or prefer those systems.
Both of C and POSIX are far more flawed than merely imperfect, and it's perfectly fine to criticize,
in light of being praised as ideals we should strive towards, when they're absolutely, nowhere near.

I also point out in part of the rebuttal that he's actually misleading his readers, in some aspects.

>For instance, one of your criticisms of UTF-8 is that it doesn't support random access. This is
>absolutely true, but accessing Unicode code points by arbitrary index is virtually always wrong
>(e.g. combining characters, etc.).
In that article, I criticize the entirety of Unicode, and I use an official Unicode document in that
criticism, because UTF-8 is one of those disgusting variable-length encodings maligned therein.  The
very idea of Unicode is fundamentally misguided, as it pours all edge cases of every language into a
single pool, I suppose thinking that this will force people to handle them, but that doesn't happen.

Further, UTF-8 is disgusting because of how it carefully steps around the many design flaws of C and
POSIX.  The C language makes queer demands of the character set it uses and specifies representation
unnecessarily, and a C program would normally need to be heavily modified to accomodate a new set of
characters, but Ken Thompson lovingly ensured C wouldn't be disadvantaged with a real-world problem.

>Until you've actually built a real, working version of your ideal, you cannot know what you're
>trading away.  The real world is messy and full of difficult problems.
Several of these problems don't actually exist, if the problem isn't mired in a historical quagmire.

>In fact, your ideal, at least as you imagine it, is almost certainly unachievable.
If I genuinely thought so, I wouldn't be working towards these things, but software, as you know, is
a malleable thing, and to merely glance at my work so far and call it unachievable is foolhardy; I'd
advise against falling into the insidious trap in which one thinks the current state is the natural.

>To quote Mike Acton, "Reality is not a hack you're forced to deal with to solve your abstract,
>theoretical problem. Reality is the actual problem."
This is amusing, in the context of my mentioning how UTF-8 does this, to accomodate C's poor design.

>The major problems with software development today do not stem from the flaws or trade-offs of C or
>POSIX. Not even close. The main enemy of good software engineering today is complexity and plain
>old sloppiness, and this would still be the case even if C and POSIX were perfect by whatever
>definition you have in mind.
I'm fond of ``The UNIX-HATERS Handbook'' and it's obvious that C and POSIX encourage complicated and
sloppy designs, by their very nature.  Further, despite their gargantuan size, POSIX systems do lack
a number of useful features which would be trivial to add properly, such as say, basic file locking.

In a similar vein, Unicode as UTF-8 disadvantages other languages so severely it's not even used for
some regions, commonly.  I find the current trend of WWW and JavaScript nonsense amusing, because it
follows this same trend of replacing things for no reason and blindly marching to tribal domination.

I know better is possible, because there are many examples of better which failed, and not by merit.
Details
Message ID
<1681758.eQR4N70OxJ@clamps>
In-Reply-To
<87eetnlkjp.fsf@server.domain.com> (view parent)
DKIM signature
pass
Download raw message
On Friday, March 20, 2020 12:25:30 AM EDT Programmer@verisimilitudes.net 
wrote:
> Well, I suppose it's clear I won't get any thoughts from you, Drew Devault,
> as I'm being ignored so.

In your rebuttal, you at turns called him a "fanatic", "ridiculous", 
"purposefully misleading", "boring" and you say that he betrays a "fundamental 
lack of understanding" of "abstractions."

Why on earth would you then want a response? When I hold someone in such low 
regard, I do my level best to ignore them, not make them talk more! While I'm 
curious as to what could possibly motivate that, that's not why I'm replying.

You say:
> 
> I know better is possible, because there are many examples of better which
> failed, and not by merit.

If there are many, surely you could cite a few. Maybe a dozen or two? When you 
cite the systems that are better, please include links to the things people 
have used them for, because practical demonstrations of their superiority are 
much more interesting than theoretical musings about why they must be 
superior.

Links to evidence that they failed for some reason other than lack of merit 
would also be more persuasive than a bald assertion that "there are many 
examples of better..."

Also, I'd just enjoy links to some good systems, even if they're old and 
failed, that I could take a look at to personally observe the contrast that 
seems to inspire your reaction.