From mboxrd@z Thu Jan 1 00:00:00 1970 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 17 Dec 2020 07:50:39 -0800 Subject: [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> Message-ID: <20201217155039.GA13368@mcvoy.com> 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 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. > > > ??? -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm