Re: GNUism in groff tests, was: pic anomalies

[G. Branden Robinson]

At 2020-01-01T23:49:38-0500, Larry Kollar wrote:
> 
> G. Branden Robinson <address@hidden> wrote:
> 
> > A rock star cowboy with a smoke machine to conceal the spit and
> > bailing wire in his implementation is hailed as a genius.
> > 
> > An engineer who spends effort building a robust system is regarded
> > as a cost center.
> 
> Can I steal these quotes (with attribution)?

Of course!  I would appreciate you correcting "bailing" to "baling",
however.  I realized I'd used the wrong term after sending the mail.

Baling wire is wire used for making hay bales, natch.  :)

[horror story elided...XSL:FO <shudder>]

> I can partly get the cowboy motivation—that demo has to work, at all
> costs, and everyone’s depending on him (usually a him) to make it
> happen. And if we don’t expect the cowboy to help turn the demo into
> production code, he won’t take the necessary steps to make it
> maintainable.

Right.  I've started to adopt the philosophy that _especially_ for
critical stuff, a senior engineer should not be writing an
implementation--he or se should be producing a spec, which junior
engineers then implement.

A senior should also, of course, participating in code reviews and
helping out with validation and verification.

But the Thing-Itself-Which-Is-To-Be-Maintained?  The senior should not
be directly touching that at all.  If there's a stumper of a problem,
the senior should be working alongside the juniors to solve it.  But the
keystrokes and commits to resolve the issue should belong to those
juniors.

This, I believe, is how expertise is built and transmitted in a
collaborative environment.

> So at the very least, I’ll be writing specs for the future software
> person to handle the re-architecture.

I wrote the above before reading this sentence!  Which shows two things:
(1) I have poor email composition/response discipline; and (2) we know
what needs to be done to unscrew our industry.  What is stopping us?

I'm tempted to say "engineering managers" but I suspect that is painting
with too broad a brush.

> As I told a former manager, “we knocked down our silos, but nobody is
> stepping over the rubble.”

I feel an urge to quote you in return.  :)

> Sorry about the long rant, if anyone has read this far, but I all too
> well understand how easy it is to skip that boring testing phase and
> roll out the Shiny! New!  Version! of code. Especially when half your
> user base is clamoring for release, and the other half is suggesting
> more enhancements. Automated tests are perhaps our only hope.

Machine-assisted formal verification holds great promise, I think.
There are two barriers to its explosive success:

(1) Too few people know that it is even possible; and
(2) There is too little pedagogy about it accessible to the
practitioner, as opposed to the academic.

Hmm, let me add a third.

(3) C is one of the worst possible foundation languages conceivable for
automated formal verification, primarily because its semantics are
generously sloppy to accommodate portability.  Perversely, in spite of
C's lauded portability, the industry produces microprocessors that go
out of their way to expose a quasi-PDP-11[1] for the sake of
accommodating the millions of lines of extant C code in the world.

And where does industry get this idea?

If I remember the chorus of irritated grumbles from 1995-2015 correctly,
C programmers especially the rock-starriest of them with the biggest
Stetsons, found going back to "legacy" code (in spite of its continued
deployment) to purge it of careless int/pointer handling and accommodate
64-bit ints as nearly too much tedium to bear.

I wonder now if this didn't play a large but hidden role in Java's
success.  Rock star cowboys would rather rewrite their old showboat
demos in a new language than go back and do unglamorous work in C.

A genius, you see, neither requires nor pays any attention to compiler
warnings.

This would also explain Java's success, apart from being a new tech
during the dot-com bubble and Sun spending itself into insolvency
promoting it.  I long wondered why a language that was such a minimal
improvement on C or C++ managed to succeed where other, better
languages failed.  Java boldly brought the PL theory insights of 1979
to a 1994 programming language.  Anything newer was too dubiously
"academic" for the brogrammers[2].

Worse is better, indeed.

Of course now, we know that C will live on, and Java is less than a
paper tiger.  Thanks, Oracle!

Regards,
Branden

[1] https://queue.acm.org/detail.cfm?id=3212479

[2] Python already had lambda functions, map(), filter(), and reduce()
by 1994.  And sure, that language has its flaws.  But what mattered to
the cowboys was only this: it was INTERPRETED.  Just like Visual
Basic[3], therefore it is exactly as good--hurr, hurr.

[3] This reminds me of a hilarious quote that I haven't been able to
source in years of searching.  May one of y'all knows.  Apparently there
was this guy who wrote all kinds of useful and best-selling books about
Visual Basic, but was not a Microsoft employee.  This guy was
highly esteemed and Microsoft was pleased as punch with him because he
was a great exponent for the language by increasing its popularity and
cost them nothing.  Then VB 6 or so came out, and had so many kitchen
sink features thrown in (like their later C#) that, similarly to Scott
Meyers with C++ years later[4], he publicly threw in the towel, with a
statement along the lines of:

"I refuse to any longer promote the work of a company that designs a
language by focus group."

May all our apostasies be as glorious.

[4] https://scottmeyers.blogspot.com/2015/12/good-to-go.html?m=1

signature.asc
Description: PGP signature