2 Mar
2023
2 Mar
'23
4:57 a.m.
On Tue, Feb 28, 2023, at 21:34, Dan Cross wrote:
On Tue, Feb 28, 2023 at 8:38 PM Will Senn
<will.senn(a)gmail.com> wrote:
[...]
I'm curious about the experience of those of
y'all who actually used them. Were there any early standouts and why did they stand
out?
This is not going to be popular, but...
Nemeth, E., Synder, G., & Seebass, S. (1989).
UNIX System Administration Handbook (5th edition is another fatty)
This book gave me some terrible advice when I was very young and impressionable.
In there somewhere it says something about not doing something unless
you're prepared to do it right lest one spend more time working around
a work-around than one would have spent just doing it well in the
first place.
The conclusion is, of course, true, but the admonition ignores all
sorts of externalities, like waiting users. And in some cases it could
really lead to paralysis Hopefully nowadays we have a better appreciation of
the power of
incrementalism; those grand plans for the perfect system rarely come
to fruition. It's better to be flexible and make small, impactful
changes along the way towards a better system, always being mindful of
and tamping down encroaching entropy.
- Dan C.
Yeah, good or bad advice at just the right time can have quite an
impact.
In the under-celebrated "Minimal Perl"[0], Tim Maher notes in the
last paragraph of section 5.8:
<quote>
In your own career, I'd advise you to develop an appreciation an
appreciation and an aptitude for both the /quick-and-dirty/ and
/elegant-and-formal/ styles of programming, and to cultivate the
ability to produce either kind on demand, as circumstances
warrant.
</quote>
Seems obvious, in retrospect -- but of course many things do with
the benefit of hindsight. For me, that articulated something that I
sensed was the right way to approach things, but was contrary to
much of the one-dimensional advice I had received up to that
point. It pairs well with one of the "lesser tenets" noted by
Gancarz: "Look for the 90 percent solution"[1].
In my own career, I've found I can often use the quick-and-dirty
approach to buy myself time to afford the "detour to build the
tools"[2] that could not be justified (to others) up-front. And
nothing gets it done faster than a shell script. Five or ten scrappy
N-line shell scripts that get the job done sub-optimally, and
lacking any real thought toward usability or generality buy time to
build better tools (usually more, better-written shell scripts). And
sometimes a scrappy script is "good enough" (for years, even).
-Al
[0] Minimal Perl for Unix People and Linux People
by Tim Maher
Forward by Damian Conway
Manning 2007
p. 175
ISBN-10: 1-932394-50-8
[1] The Unix Philosophy
by Mike Gancarz
Digital Press 1995
p. 117
ISBN-10: 1-55558-123-4
[2] [McIlroy78] The Bell System Technical Journal. Bell Laboratories.
M. D. McIlroy, E. N. Pinson, and B. A. Tague.
"Unix Time-Sharing System Forward". 1978. 57 (6, part 2). p. 1902.
https://archive.org/details/bstj57-6-1899/page/n3/mode/2up
Also quoted in ESR's "The Art of Unix Programming"
Addison-Wesley 2004
p. 12
ISBN-13: 9-780131-429017
https://www.catb.org/~esr/writings/taoup/html/ch01s06.html
--
a l a n d. s a l e w s k i
ads(a)salewski.email
salewski(a)att.net
https://github.com/salewski