17 Dec
2020
17 Dec
'20
3:22 p.m.
Moving to COFF since this is really not UNIX as much as programming
philosophy.
On Thu, Dec 17, 2020 at 9:36 AM Larry McVoy <lm(a)mcvoy.com> wrote:
So the C version was easier for me to understand. But
it sort of
lost something, I didn't really understand Steve's version, not at any
deep level. But it made more sense, somehow, than the C version did.
I'm not too hard on Steve as herein lies the dichotomy that we call
programming. Looking back the BourneGOL macros were clearly convenient
for him as the original author and allow him to express ideas that he had
well in his source. They helped him to create the original and were
comforting in the way he was used to. Plus, as Larry notes, the action of
transpiling loses that (BTW -- look some time at comments in the C version
of advent and you can still vestiges of the original Fortran).
But the problem is that when we create a new program, we can easily forget
that it might live forever[1] - particularly if you are a researcher trying
to advance and explore a set of ideas (which of course is what Steve was at
the time). And as has been noted in many other essays, the true cost of SW
is in the maintenance of it, not the original creation. So making
something easy to understand, particularly in the future without the
context, starts to become extremely attractive - particularly when it has a
long life and frankly impact beyond what is was originally considered.
It's funny, coming across BourneGOL help to validate/teach/glue into me an
important concept when programming for real -> the idea of "least
astonishment" or "social acceptance" of your work. Just because you
understand it and like it might not be the same for your sisters and
brothers in the community. There is no such thing as a private program.
The moment a program leaves your desk/terminal, it will be considered and
analyzed by others.
So back to the time and seeing BourneGOL for the first time, please
consider that in the mid-70s, I was coming to C from BLISS, SAIL, Algol-W
as my HLLs, so I was used to BEGIN/END style programming and bracketing
lining up 4 spaces under the next line with B/E in the same column. The
White Book did not yet exist, but what would become 'one-true bracing
style' later described in K&R was used in the code base for Fifth and Sixth
Edition. When I first saw that, it just looked wrong to me. But I was
coming from a different social setting and was using a different set of
social norms to evaluate this new language and the code written in it.
At some point I took CMU's SW engineering course where we had to swap code
3 different times with other groups for the team projects, and I had come
to realize how important making things be understood by the next team was.
So, I quickly learned to accept K&R style and like Ron and Larry cursed
Steve a little. And while I admire Steve for his work and both ADB and
Bourne Shell were tools I loved and used daily, when I tried to maintain
them I had wished that Steve had thought about those that would come after
- but I do accept that was not on his radar.
That lesson has served me well for many years as a professional and it's a
lesson I try to teach with my younger engineers in particular. It's not
about being 100% easy for you now, it is about being easy for someone other
than you that has to understand your code in the future. Simply use the
social norms of the environment you live and work ("do as the Romans" if
you will). Even if it is a little harder now, learn the community norms,
and use them.
FWIW: You can actually date some of my learnings BTW with fsck (where we
did not apply this rule). Ted and I have come from MTS and
TSS respectively (*i.e.* IBM 360), which you remember from this first few
versions had all errors in UPPER CASE (we kept that style from the IBM
system -- not the traditional UNIX style). For many years after its success
and the program spreading like wildfire within the UNIX community, I would
run it on a system and be reminded of my failure to learn that lesson yet.
Clem
[1] BTW: the corollary to living forever, is that the worst hacks you do
seem to be the ones that live the longest.
ᐧ
17 Dec
17 Dec
3:50 p.m.
New subject: [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
I feel like I could have written everything that Clem said (except for the
BLISS, SAIL, Algol-W parts, I didn't experience that). But the sentiment
contained in this email is pretty much exactly how I think. I really feel
like Clem and I were separated at birth or something :-)
I told my people that it doesn't matter who wrote it 6 months from now,
even if it was you, you are going to have to relearn the code to fix a
bug in it. So make it easy on yourself, and everyone else, don't be
clever unless it is absolutely necessary. All of my core team were
dramatically smarter than me and I think that made me even more important.
Having me around, and leading, meant that the code had to be simple
enough that I understood it (there were some exceptions). Which meant
we could support it. We usually knew what the bug was within a couple
of minutes after the bug report came in. Not always but an astoundingly
high percentage of the time. That wouldn't be true if I had let every
"clever" hunk of code in. That shit adds up. Dumber is better.
On Thu, Dec 17, 2020 at 10:22:39AM -0500, Clem Cole wrote:
Moving to COFF since this is really not UNIX as much
as programming
philosophy.
On Thu, Dec 17, 2020 at 9:36 AM Larry McVoy <lm(a)mcvoy.com> wrote:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
So the C version was easier for me to understand.
But it sort of
lost something, I didn't really understand Steve's version, not at any
deep level. But it made more sense, somehow, than the C version did.
I'm not too hard on Steve as herein lies the dichotomy that we call
programming. Looking back the BourneGOL macros were clearly convenient
for him as the original author and allow him to express ideas that he had
well in his source. They helped him to create the original and were
comforting in the way he was used to. Plus, as Larry notes, the action of
transpiling loses that (BTW -- look some time at comments in the C version
of advent and you can still vestiges of the original Fortran).
But the problem is that when we create a new program, we can easily forget
that it might live forever[1] - particularly if you are a researcher trying
to advance and explore a set of ideas (which of course is what Steve was at
the time). And as has been noted in many other essays, the true cost of SW
is in the maintenance of it, not the original creation. So making
something easy to understand, particularly in the future without the
context, starts to become extremely attractive - particularly when it has a
long life and frankly impact beyond what is was originally considered.
It's funny, coming across BourneGOL help to validate/teach/glue into me an
important concept when programming for real -> the idea of "least
astonishment" or "social acceptance" of your work. Just because you
understand it and like it might not be the same for your sisters and
brothers in the community. There is no such thing as a private program.
The moment a program leaves your desk/terminal, it will be considered and
analyzed by others.
So back to the time and seeing BourneGOL for the first time, please
consider that in the mid-70s, I was coming to C from BLISS, SAIL, Algol-W
as my HLLs, so I was used to BEGIN/END style programming and bracketing
lining up 4 spaces under the next line with B/E in the same column. The
White Book did not yet exist, but what would become 'one-true bracing
style' later described in K&R was used in the code base for Fifth and Sixth
Edition. When I first saw that, it just looked wrong to me. But I was
coming from a different social setting and was using a different set of
social norms to evaluate this new language and the code written in it.
At some point I took CMU's SW engineering course where we had to swap code
3 different times with other groups for the team projects, and I had come
to realize how important making things be understood by the next team was.
So, I quickly learned to accept K&R style and like Ron and Larry cursed
Steve a little. And while I admire Steve for his work and both ADB and
Bourne Shell were tools I loved and used daily, when I tried to maintain
them I had wished that Steve had thought about those that would come after
- but I do accept that was not on his radar.
That lesson has served me well for many years as a professional and it's a
lesson I try to teach with my younger engineers in particular. It's not
about being 100% easy for you now, it is about being easy for someone other
than you that has to understand your code in the future. Simply use the
social norms of the environment you live and work ("do as the Romans" if
you will). Even if it is a little harder now, learn the community norms,
and use them.
FWIW: You can actually date some of my learnings BTW with fsck (where we
did not apply this rule). Ted and I have come from MTS and
TSS respectively (*i.e.* IBM 360), which you remember from this first few
versions had all errors in UPPER CASE (we kept that style from the IBM
system -- not the traditional UNIX style). For many years after its success
and the program spreading like wildfire within the UNIX community, I would
run it on a system and be reminded of my failure to learn that lesson yet.
Clem
[1] BTW: the corollary to living forever, is that the worst hacks you do
seem to be the ones that live the longest.
??? 
5:57 p.m.
New subject: [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
On Thu, Dec 17, 2020 at 8:50 AM Larry McVoy <lm(a)mcvoy.com> wrote:
I told my people that it doesn't matter who wrote
it 6 months from now,
even if it was you, you are going to have to relearn the code to fix a
bug in it.
This goes double or triple for open source. 6 months from now, the odds are
50/50 the original contributor is busy, unavailable at the moment or
otherwise gone if it wasn't one of the current top 20 contributors.
Clever is almost always wrong... It's only right if the code is performance
critical and the cleverness gives better performance in a meaningful way.
And even then the bias is against being too clever.
Warner
6 p.m.
New subject: [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
On Thu, Dec 17, 2020 at 10:57:13AM -0700, Warner Losh wrote:
On Thu, Dec 17, 2020 at 8:50 AM Larry McVoy
<lm(a)mcvoy.com> wrote:
Most old guys get it. But my guys were seasoned and still would try and
slip stuff in.
I think it is part of being really smart, it's a puzzle for them and they
"win" if they can do something clever. I always replied "It is write
once,
read many. Optimize for reads". It's depressing how much of my job was
pounding that message home year after year.
I told my people that it doesn't matter who
wrote it 6 months from now,
even if it was you, you are going to have to relearn the code to fix a
bug in it.
This goes double or triple for open source. 6 months from now, the odds are
50/50 the original contributor is busy, unavailable at the moment or
otherwise gone if it wasn't one of the current top 20 contributors.
Clever is almost always wrong... It's only right if the code is performance
critical and the cleverness gives better performance in a meaningful way.
And even then the bias is against being too clever. 
6:30 p.m.
New subject: [TUHS] Algol 68 and Unix (was cron and at ...)
On 17 Dec 2020 10:00 -0800, from lm(a)mcvoy.com (Larry McVoy):
Most old guys get it. But my guys were seasoned and
still would try and
slip stuff in.
I think it is part of being really smart, it's a puzzle for them and they
"win" if they can do something clever. I always replied "It is write
once,
read many. Optimize for reads". It's depressing how much of my job was
pounding that message home year after year.
I would rather say to optimize for debugging, which in my experience
happen even more often than (casual) reads. My personal experience is
that most code pretty much just sits there until there's (a) a bug
involving it in some manner, or (b) a new feature that requires
somehow modifying it. When you're trying to figure out why in the
$DEITY $EXPLETIVE $VOLUME the code doesn't do what you think it
should, _any_ amount of "clever" is usually too much.
Yes, it might save a few lines of code somewhere.
Yes, it might be fun to play with a brand new language or compiler or
framework feature.
Yes, every once in a long while there's actually an actual, good
reason to go the "clever" route because it provides some _significant_
advantage. Performance for performance-critical code is one such
example. (I think that so far, professionally, I've written _one_
piece of code where performance was actually critical enough to
warrant getting clever. More often, trying to be clever has just ended
up confusing the compiler.)
But if it takes the next person a week to figure out why the code
doesn't work right when a more direct approach would have made the
error obvious at a glance without any significant downsides other than
that it doesn't use Feature X, then almost every time that's going to
be a really, really, _really_ bad trade-off.
What was that saying again? The person who will need to fix the bugs
in or build upon your code is a sociopathic axe murderer who knows
where you live, so write your code accordingly?
For me, I try quite hard to steer clear of "clever" unless the
cleverness offers some seriously compelling advantage.
And I don't even consider myself particularly old.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
9:10 p.m.
New subject: [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy <lm(a)mcvoy.com> wrote:
I think it is part of being really smart, it's a
puzzle for them and they
"win" if they can do something clever. I always replied "It is write
once,
read many. Optimize for reads".
Amen to that bro.
And at the risk of getting either Jon or Ted (or both probably) I think
that what astonished me when Jon and I were discussing how the Linux FS
stuff got spliced in with so many macros and indirections, frameworks, *et
al*. earlier in the summer (i.e. when Jon was trying to build up his newest
idea); the Linux kernel code for the FS interface was so 'clever' (ney
complex and indirect) that was no longer clear what in the code did what to
either of us (and Jon and I are hardly neophyte C programmers). As Ted
fairly points out it works and seems to be reasonably fast in practice, and
the Linux kernel team has created test code for some of it all which is far
better than the coding practice in a lot of the rest of the FOSS community
at large. But I suggest that sometimes just because *you can do something,
doesn't mean you should *(tipping my cap to Rob's '*cat -v harmful*'
observation of years gone by).
As a side note, I will say there is another vector to this same curse.
It's the new guy coming into the project and deciding what is there is
crap, they can not understand and they can do a better job. IMO this is
a problem that is rampant in many FOSS community projects, but I used to
see it at DEC >>all the time<< and still run into it at Intel these days.
Picking on DEC and using Tru64 as an example, it took 3 extra years to get
Tru64 out the door from the original OSF/1 codebase because of it. Every
major subsystem was rewritten. Not saying what they got from OSF was
perfect, but DEC could have shipped Tru64 with the original terminal
handler/SCSI/memory/graphics/100% 64-bit clean ... and replaced the code
later with 'better' implementations.
The bottom line for me is that I rather give up a tiny amount of the
absolute speed for long-term scale and maintenance cost (then again it one
of the reasons while I'm a microkernel fan too). Unless this new
feature/rewrite something that is really going to make or break me, I
rather make what works today, and evolve over time when I have a revenue
stream (*i.e.* OSF/1 was good enough for most of Alpha, but Tru64 was
amazing -- it just took three years]. Plus, as Warner points out, the
original author will be long gone - which only play farther into my
thinking of simple is clear is better in the long run. No just in FOSS,
again, DEC/Intel, we have people retire or go elsewhere all the time (plus
we get a new set of VPs that reset the corporate direction every 18-24
months).
My basic thinking is you should pick the one or two specific features that
really matter for your product and you need to ensure that its value is
exposed and very much available to the customer. The rest needs to be simple,
clear, and works, and you're done. Get on to the next thing.
BTW: this is not just a system SW issue. I suspect it's more fundamentally
human when people get excited by their own ideas and what they can do and
don't stop to think about the true ramifications of the effort. One of my
all-time favorite papers is Tom Lyon and Joe Skudlarek's wonderful 1985
tome 'All the Chips That Fit' which bemoans the hardware equivalent of this
same problem [which if you have never read, as a system person you should].
Also, it's also not a computer business only issue. I have another story,
I'm not sure if I have told here before, which I call the 'Milacron
problem.' I use it to explain to our younger engineers why creating
something new is not always the right way. Cincinnati-Milacron is one of
the oldest, largest, and most respected machine tool manufacturers in the
world. My HBS brother ran the robot division and later the machine tool
group at one point. Milacron can make anything -- period. That is their
business. So what happens, ever newly minted Mech E wants to make his own
hydraulic values for their project. At some point in the 80s, Milacron had
over 5000 different hydraulic values in their internal parts catalog
because no one would take the time to see if one from a previous project
would work.
Clem
ᐧ
18 Dec
18 Dec
2:43 p.m.
New subject: [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
On Thu, Dec 17, 2020 at 04:10:03PM -0500, Clem Cole wrote:
On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy
<lm(a)mcvoy.com> wrote:
Source management to the rescue. I hired an extremely smart guy (he
reads papers on string theory, the physics ones, for fun). Taught him
how to use our tools. Gave him a bug to fix. He looks at the source
file and goes "This is crap, I'm gonna rewrite it so it is clean".
Then remembers I showed him how he could see how the file evolved.
So he looks at the first version of the file. It is *exactly* what he
was going to write. Huh. He starts going through the history. Oh,
this wart is for IRIX. This wart is for windows 2000 that reuses PIDs
right away. This wart is for NFS. Etc.
In the end, he added another wart to fix the bug and left the file alone.
I did say he was smart.
I think it is part of being really smart,
it's a puzzle for them and they
"win" if they can do something clever. I always replied "It is write
once,
read many. Optimize for reads".
Amen to that bro.
As a side note, I will say there is another vector to this same curse.
It's the new guy coming into the project and deciding what is there is
crap, they can not understand and they can do a better job.
3:46 p.m.
New subject: [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
Excellent!
ᐧ
On Fri, Dec 18, 2020 at 9:43 AM Larry McVoy <lm(a)mcvoy.com> wrote:
On Thu, Dec 17, 2020 at 04:10:03PM -0500, Clem Cole
wrote:
Source management to the rescue. I hired an extremely smart guy (he
reads papers on string theory, the physics ones, for fun). Taught him
how to use our tools. Gave him a bug to fix. He looks at the source
file and goes "This is crap, I'm gonna rewrite it so it is clean".
Then remembers I showed him how he could see how the file evolved.
So he looks at the first version of the file. It is *exactly* what he
was going to write. Huh. He starts going through the history. Oh,
this wart is for IRIX. This wart is for windows 2000 that reuses PIDs
right away. This wart is for NFS. Etc.
In the end, he added another wart to fix the bug and left the file alone.
I did say he was smart.
On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy
<lm(a)mcvoy.com> wrote:
> I think it is part of being really smart, it's a puzzle for them and
they
> "win" if they can do something
clever. I always replied "It is write
once,
read
many. Optimize for reads".
Amen to that bro.
As a side note, I will say there is another vector to this same curse.
It's the new guy coming into the project and deciding what is there is
crap, they can not understand and they can do a better job. 
5:41 p.m.
New subject: [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)
On Fri, Dec 18, 2020 at 06:43:32AM -0800, Larry McVoy wrote:
Source management to the rescue. I hired an extremely
smart guy (he
reads papers on string theory, the physics ones, for fun). Taught him
how to use our tools. Gave him a bug to fix. He looks at the source
file and goes "This is crap, I'm gonna rewrite it so it is clean".
Then remembers I showed him how he could see how the file evolved.
So he looks at the first version of the file. It is *exactly* what he
was going to write. Huh. He starts going through the history. Oh,
this wart is for IRIX. This wart is for windows 2000 that reuses PIDs
right away. This wart is for NFS. Etc.
In the end, he added another wart to fix the bug and left the file alone.
I did say he was smart.
....and this is why when I do code reviews, I'm asking for
improvements in the commit (or CL) description at least as much as I
am pointing out issues in the code itself. In some cases, when the
contributor is someone for whom English is not their first language,
I'll end up rewriting the commit description as well. Code archeology
is *definitely* a powerful tool, but this relies on the source control
metadata is sufficiently rich; in some cases, having links to bug
trackers or mailing list discussions are super-useful.
- Ted
7:24 p.m.
New subject: [TUHS] Algol 68 and Unix (was cron and at ...)
On Fri, Dec 18, 2020 at 12:41:58PM -0500, Theodore Y. Ts'o wrote:
Code archeology
is *definitely* a powerful tool, but this relies on the source control
metadata is sufficiently rich; in some cases, having links to bug
trackers or mailing list discussions are super-useful.
- Ted
Believe it or not, this is one of my major complaints about Git, it only
has commit comments, there are no per file comments (because there is no
per file meta data other than contents, type, and permissions).
BitKeeper has full per file meta data including comments, user who made
the change, etc. Which means you can have commits that have more than
one author.
The GUI tool we built for checkins had 3 panes:
list
of
files
that
are
changed
--------------
space
for
comments
-------------
diffs
for
current
file
The ChangeSet file, which is just another version controlled file that
is the manifest for the repository, its graph is the same graph as Git
has, is always the last file of the list of files, but here is the trick:
the diffs for the ChangeSet file were all the comments you just typed
in. So what do people do? On the files, they tended to say what they
did to that file, some bread crumbs specific to that file. On the
ChangeSet file, seeing all those comments, they tended "up level" their
comments and provide more of a "what" than a "how".
Intel looked at the quality of the checkin comments done at the command
line vs those done with the GUI tool and mandated the use of GUI tool,
the comments were _that_ much more useful.
1224
days inactive
1225
days old
9 comments
5 participants
participants (5)
-
Clem Cole -
Larry McVoy -
Michael Kjörling -
Theodore Y. Ts'o -
Warner Losh