[TUHS] End of an era: the last ATC (USENIX Annual Technical Conference)

[G. Branden Robinson]

At 2025-07-19T20:16:33-0500, Will Senn wrote:
> I've thought about the "if you worked for me", dig and it kind of
> stung.

Manure often does.

Larry came up in the soil from which grew tech bro culture.

A preoccupation with managing the preferences of others, as with Steve
Jobs's "thought leadership", is consistent with the authoritarian style
he advocates.

In contrast I think questions of engineering are more important than
those of fashion.  But fashion is easier, and apparently more profitable
to write about, so people who like to see their names trafficked by
journalists follow the path of less resistance.

I admit that a lot more people have heard of Condé Nast than Isambard
Brunel or Oliver Heaviside.

> As a former global tech guy, I never told my architects, engineers,
> developers, qa analysts, bus analysts or even executive assistants
> what to use to get their job done. I argued my position on various
> technical directions, but I gave in when the argument had merit. Yes,
> I insisted on some decisions, but these were high level architectural
> decisions where I had budgetary responsibility as well as technical.
> On smaller matters of personal productivity, I pretty much ceded that
> territory to the individual. When monetary cost was involved, that
> brought in its own approval threshold, but by and large, if the
> individual wanted to use qedit, q, emacs (why?), ultraedit, etc. So
> long as it wasn't burdensome in some way, I could care less. Probably
> the smartest and most productive engineer I ever worked with was in
> love with Borland Brief... I could edit circles around him with vi,
> but... he was a masterful engineer... he got his brief and he seemed
> happy with it, we got excellence and quality systems from him...

I was taught "if it ain't broke, and we don't expect it to break, don't
fix it" as a principle of sound engineering.

I'd say it applies to personnel management as well.  Larry may not.

On the milder topic of editor preferences, I'm a vi(m) user but employ
Emacs bindings in readline applications and maintained my own fork of mg
(microemacs) for a while, to see how the other half lived.  I discovered
that a much bigger chunk of Emacs advocacy is predicated on its
"finger-feel"[1] and some other built-in features than upon Lisp
scriptability.  In other words, far more Emacs advocates trumpeted the
value of its customizability via Lisp than actually developed competence
in writing Lisp for themselves.  (On the bright side, Atom/Electron and
VSCode could well have drawn away people of this mentality from younger
generations, such that anyone choosing an Emacs today is more serious
about developing Lisp expertise.  Good for them.)

While Vim has also been Turing-equivalently programmable for decades
now, via peculiar extensions to the ex language,[1] but also Perl,
Python, and Tcl, its community has seemed less brash about that fact.  I
think that's because unsophisticated Emacs users were attempting to ride
on Lisp's coattails as an early and innovative yet satisfyingly esoteric
development in the history of programming languages.  Again, we
encounter people more concerned with superficial matters of fashion than
with overcoming problems of engineering.

I did once have loyalty to nvi, and did have a conversion experience,
and I remember exactly what it was.  It was visual mode.  I was
practiced at writing ed-style commands applying to address ranges to get
stuff done at the colon prompt.  That frequently meant having to think
up the shortest possible regex that would capture the range I wanted, or
having to count lines on the screen--both tedious--or make a crude and
thus frequently inaccurate guess.  Visual mode, where I use line mode
"V" 10 times more often than character mode "v" and character mode 10
times more often than rectangle mode "Control+V", killed off that
problem for me completely.

Nowadays, I only ever write ed/ex-style addresses when composing sed
scripts, which suits me just fine, because I only write a sed script
when I need a repeatable procedure or operation in the first place,
maybe in a Makefile.  In those scenarios, the extra brain cycles given
to regex construction or perfectly reliable line-counting pays off.

Like others in this thread, but later in my personal history, I came to
find vertical splits (and vimdiff(1)) extremely useful.  For composing
emails, though, but for one factor[3] I could probably be thrown into
nvi and not miss any Vim features.

Maybe I should start submitting "textwidth" patches to the various nvi
descendants and see if anyone will accept them.

For years I nursed the thought that a wonderful joke to play on RMS's
tedious Emacs partisanship would have been to add Guile to Vim's list of
extension languages.

But I guess no one enjoys schadenfreude _that_ much.

Regards,
Branden

[1] which I suspect is objectively worse than vi's by keystroke count,
    but I am unwilling to write a grant proposal to research the matter
    properly ;-)

[2] recently given a major overhaul with "vim9script", which seems like
    a worthwhile cleanup but of which I've not reached an informed
    opinion

[3] The "textwidth" option is a killer Vim feature because vi's
    "wrapmargin" was ill-conceived.  It arose from Teletype/punched-card
    thinking, poorly anticipating varying terminal display widths.  I'll
    piss off Larry some more by punking on Bill Joy and claim that
    "wrapmargin" solved the wrong problem.  Unless you're composing for
    paper, which was expressly _not_ the point of *VI*, you don't _care_
    how wide the right margin is in character cells.  You care about how
    wide the line of text is.  (You might also care about an indent.)

    _nroff_ had already gotten this right in 1972, even on paper output,
    with `.ll` and `.in`.  There was no configuration knob for a right
    margin or indent.

    I'm sorry, Bill--I think you missed it.

    So saith the GBR 9000, foolproof and incapable of error. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20250720/56abe77b/attachment.sig>