From mboxrd@z Thu Jan  1 00:00:00 1970
From: michael@kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Sat, 6 May 2017 09:18:57 +0000
Subject: [TUHS] Discuss of style and design of computer programs from a
 user stand point
In-Reply-To: <5a2d6cc957c2efcd968f35aa5557c7a0e309dd27@webmail.yaccman.com>
References: <201705060202.v4622L1J013430@coolidge.cs.Dartmouth.EDU>
 <5a2d6cc957c2efcd968f35aa5557c7a0e309dd27@webmail.yaccman.com>
Message-ID: <20170506091857.GE12539@yeono.kjorling.se>

On 5 May 2017 22:33 -0700, from scj at yaccman.com (Steve Johnson):
> For me, a lot of what
> I learned was from Stan Brown at the Labs, who read piles of my
> (atrocious) FORTRAN code and repeatedly pointed out that when you
> wrote a program, you were not just communicating with the computer,
> but also other humans (including yourself) who would read (and perhaps
> modify) the code in the future...

I would actually take that one step further: When you are writing
code, you are _first and foremost_ communicating with whatever human
will need to read or modify the code later. That human might be you, a
colleague, or the violent psychopath who knows both where you live and
where your little kids go to school (might as well be you). You should
strive to write the code accordingly, _even if_ the odds of the threat
ever materializing are slim at most. Style matters a lot, there.

Sure, some code really needs to be heavily optimized, and might end up
obscure for it. In operating systems, interrupt routines are probably
one of the major candidates, but first stage bootloaders need their
fair share of it too for other reasons. Tight loops or code that needs
to be able to operate on lots of data quickly are other examples. But
_most code isn't like that_ and can allow for some extra verbosity and
some performance penalty if that means making it significantly easier
to read and modify. That's not to say code should be verbose _just
because_, but if you don't need ultimate performance, I say aim for
readability and modifyability first; processing and memory usage
second. You can always go back and optimize bits that turn out to need
it.

And of course, I find Doug McIlroy's shell snippet mentioned by Noel
interesting, _because I did something very similar not all that long
ago_; in my case, stringing together a bunch of shell tools to get a
list of all URLs from an e-mail message for further processing.
(Something like a composable _urlview_; if urlview had even had a
"dump to stdout" option, that would have done all I needed it for.)
Works like a charm, and isn't even terribly complicated. It could
probably be done in a single line of perl or awk instead of piping
through a grand total of six commands, but that's okay. And of course,
stringing together a bunch of commands was the first approach that
occured to me...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)