From dave at horsfall.org Wed Dec 2 00:30:04 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 2 Dec 2020 01:30:04 +1100 (EST) Subject: [COFF] Screen saver on BSDi Message-ID: Is it just me, or did console messages really wake up the screen saver on BSDi (aka BSD/OS)? That old box has long since gone to $HEAVEN (along with the company itself; thank you WinDriver) but I'm getting annoyed at having to tap a key on FreeBSD to see the console, which I don't recall having to do on BSDi. -- Dave From steffen at sdaoden.eu Wed Dec 2 08:38:24 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Dec 2020 23:38:24 +0100 Subject: [COFF] [TUHS] The UNIX Command Language (1976) In-Reply-To: References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> <20201201202012.-40Ur%steffen@sdaoden.eu> <67EE6390-7E60-442B-AEEA-17951ED759A5@iitbombay.org> Message-ID: <20201201223824.gBVRZ%steffen@sdaoden.eu> Dan Cross wrote in : |On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah wrote: | |> On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso wrote: |>> Never without my goto:, and if it is only to break to error |>> handling and/or staged destruction of local variables after |>> initialization failures. Traumatic school impression, finding |>> yourself locked in some PASCAL if condition, and no way to go to. |> |> Pascal had goto. Hm, i did not receive Bakul's mail. Well i did not use it long enough. I think this came up in the past already, it could have been it was a mutilated version, there definetely was no goto in this DOS-looking UI with menu bar, with menu entries for compilation plus, help screen etc etc. Borland Pascal, Borland dBASE it must have been then. Didn't i say "maybe the teacher had an option to turn it on" or something :) Yeah, i do not know, but there was no goto, definetely. |Pascal also had to go. (Thanks...I'm here all week.) Ah, and all the many-page program listings in Delphi, what a waste of paper. Whether anyone really typed them out, not me. |You can even do a non-local goto! Help. |> In Go you don't need goto for the sort of thing you and McVoy |> talked about due to its defer statement and GC. Now granted |> GC may be too big of a hammer for C/C++ but a future C/C++ |> add defer gainfully as the defer pattern is pretty common. |> For example, mutex lock and unlock. Terrible just as pthread_cleanup_push/pop, and that can be entirely local-to-scope. Terrible even if there would be "closure"s that could be used as arguments instead of a function pointer. gcc supports/ed computed goto's, which would also be nice in that respect. And some kind of ISO _Xy() which could be used in conditionals dependent on whether the argument is a computed goto, a "closure" or a function pointer (or a member function pointer). I always hated that C++ is not ISO C plus extensions, so your "C/C++" is not true for a long time... --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Wed Dec 2 09:06:08 2020 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Dec 2020 00:06:08 +0100 Subject: [COFF] [TUHS] The UNIX Command Language (1976) In-Reply-To: <20201201223824.gBVRZ%steffen@sdaoden.eu> References: <15511090.6330.1606835354160.JavaMail.root@zimbraanteil> <202012011538.0B1FcLi5023858@freefriends.org> <202012011639.0B1GdjcD031722@freefriends.org> <20201201202012.-40Ur%steffen@sdaoden.eu> <67EE6390-7E60-442B-AEEA-17951ED759A5@iitbombay.org> <20201201223824.gBVRZ%steffen@sdaoden.eu> Message-ID: <20201201230608.KfHs2%steffen@sdaoden.eu> Steffen Nurpmeso wrote in <20201201223824.gBVRZ%steffen at sdaoden.eu>: |Dan Cross wrote in | : ||On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah wrote: ||> On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso \ ||> wrote: ||>> Never without my goto:, and if it is only to break to error ||>> handling and/or staged destruction of local variables after ||>> initialization failures. Traumatic school impression, finding ||>> yourself locked in some PASCAL if condition, and no way to go to. ||> ||> Pascal had goto. | |Hm, i did not receive Bakul's mail. Well i did not use it long Actually not true. Dec 1 21:39:30 postfix/qmgr[2670]: 4557B16056: from=, size=4251, nrcpt=1 (queue active) Dec 1 21:39:30 postfix/local[9475]: 4557B16056: to=, relay=local, delay=0.11, delays=0.08/0/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox) ... |Help. And increasingly so. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From dave at horsfall.org Sat Dec 5 07:05:34 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 5 Dec 2020 08:05:34 +1100 (EST) Subject: [COFF] ARPAnet now 4 nodes Message-ID: The ARPAnet reached four nodes on this day in 1969; at least one "history" site reckoned the third node was connected in 1977 (and I'm still waiting for a reply to my correction). Well, I can believe that perhaps there were only three left by then... According to my notes, the nodes were UCSB, UCLA, SRI, and Utah. -- Dave From jnc at mercury.lcs.mit.edu Sun Dec 6 09:14:46 2020 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 5 Dec 2020 18:14:46 -0500 (EST) Subject: [COFF] ARPAnet now 4 nodes Message-ID: <20201205231446.0A71E18C0B6@mercury.lcs.mit.edu> > The ARPAnet reached four nodes on this day in 1969 .. > the nodes were UCSB, UCLA, SRI, and Utah. Yeah; see the first map here: http://www.chiappa.net/~jnc/tech/arpageo.html Missing maps gratefully received! Noel From dave at horsfall.org Wed Dec 9 12:41:11 2020 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 9 Dec 2020 13:41:11 +1100 (EST) Subject: [COFF] ARPAnet now 4 nodes In-Reply-To: <20201205231446.0A71E18C0B6@mercury.lcs.mit.edu> References: <20201205231446.0A71E18C0B6@mercury.lcs.mit.edu> Message-ID: On Sat, 5 Dec 2020, Noel Chiappa wrote: > > The ARPAnet reached four nodes on this day in 1969 .. the nodes were > > UCSB, UCLA, SRI, and Utah. > > Yeah; see the first map here: > > http://www.chiappa.net/~jnc/tech/arpageo.html Yep; I know that first map well :-) For the newbies here, the ARPAnet was the predecessor of the Internet (no, it didn't spring from the brow of Zeus, nor Billy Gates), and what we now call "routers" were then IMPs (look it up). > Missing maps gratefully received! Indeed; history needs to be kept alive, lest it die. -- Dave From dave at horsfall.org Thu Dec 10 06:13:11 2020 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 10 Dec 2020 07:13:11 +1100 (EST) Subject: [COFF] Happy birthday, Ada Lovelace and JFO! Message-ID: Sorta relevant to both groups... Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), was born on this day in 1815; arguably the world's first computer programmer and a highly independent woman, she saw the potential in Charles Babbage's new-fangled invention. J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. Who'ld've thought that two computer greats would share the same birthday? -- Dave From grog at lemis.com Thu Dec 10 09:38:42 2020 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 10 Dec 2020 10:38:42 +1100 Subject: [COFF] Happy birthday, Ada Lovelace and JFO! In-Reply-To: References: Message-ID: <20201209233842.GA47484@eureka.lemis.com> [Removing TUHS] On Thursday, 10 December 2020 at 7:13:11 +1100, Dave Horsfall wrote: > > Who'ld've thought that two computer greats would share the same birthday? I, for one. This is the subject of the "birthday problem", https://en.wikipedia.org/wiki/Birthday_problem, though it's not clear where there's a problem. Take any 23 people and the chance of two of them having the same birthday is 50%. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From rudi.j.blom at gmail.com Thu Dec 10 18:12:29 2020 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Thu, 10 Dec 2020 15:12:29 +0700 Subject: [COFF] ARPAnet now 4 nodes Message-ID: I like a challenge although it wasn't really much of it. A simple arpa imp in yahoo spilled the beans :-) "The Interface Message Processor (IMP) was the packet switching node used to interconnect participant networks to the ARPANET from the late 1960s to 1989. It was the first generation of gateways, which are known today as routers.[1][2][3] An IMP was a ruggedized Honeywell DDP-516 minicomputer with special-purpose interfaces and software.[4] In later years the IMPs were made from the non-ruggedized Honeywell 316 which could handle two-thirds of the communication traffic at approximately one-half the cost.[5] An IMP requires the connection to a host computer via a special bit-serial interface, defined in BBN Report 1822. The IMP software and the ARPA network communications protocol running on the IMPs was discussed in RFC 1, the first of a series of standardization documents published by the Internet Engineering Task Force (IETF)." https://en.wikipedia.org/wiki/Interface_Message_Processor Cheers, uncle rubl From: Dave Horsfall To: Computer Old Farts Followers Cc: Bcc: Date: Wed, 9 Dec 2020 13:41:11 +1100 (EST) Subject: Re: [COFF] ARPAnet now 4 nodes On Sat, 5 Dec 2020, Noel Chiappa wrote: > The ARPAnet reached four nodes on this day in 1969 .. the nodes were > UCSB, UCLA, SRI, and Utah. Yeah; see the first map here: http://www.chiappa.net/~jnc/tech/arpageo.html Yep; I know that first map well :-) For the newbies here, the ARPAnet was the predecessor of the Internet (no, it didn't spring from the brow of Zeus, nor Billy Gates), and what we now call "routers" were then IMPs (look it up). Missing maps gratefully received! Indeed; history needs to be kept alive, lest it die. -- Dave From david at kdbarto.org Fri Dec 11 03:41:49 2020 From: david at kdbarto.org (David Barto) Date: Thu, 10 Dec 2020 09:41:49 -0800 Subject: [COFF] The Origins of C (from CPL to C) Message-ID: Interesting read. https://apple.news/A_-wNCMkYTUqUYmLw17kK-A David From dave at horsfall.org Sat Dec 12 18:39:51 2020 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 12 Dec 2020 19:39:51 +1100 (EST) Subject: [COFF] Happy birthday, Ada Lovelace and JFO! In-Reply-To: <20201209233842.GA47484@eureka.lemis.com> References: <20201209233842.GA47484@eureka.lemis.com> Message-ID: On Thu, 10 Dec 2020, Greg 'groggy' Lehey wrote: >> Who'ld've thought that two computer greats would share the same >> birthday? > > I, for one. This is the subject of the "birthday problem", > https://en.wikipedia.org/wiki/Birthday_problem, though it's not clear > where there's a problem. Take any 23 people and the chance of two of > them having the same birthday is 50%. Not only am I familiar with that (I majored in Mathematics), I also know about the timezone problem i.e. when did a certain event occur? And anyway, I was not talking about two people chosem at random, if you'd actually read what I wrote. I try to use the local timezone where possible, but sometimes I have to guess; what do you do? -- Dave From clemc at ccc.com Fri Dec 18 01:22:39 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 17 Dec 2020 10:22:39 -0500 Subject: [COFF] [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <20201217143558.GD13268@mcvoy.com> References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> Message-ID: 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. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Dec 18 01:50:39 2020 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 From bakul at iitbombay.org Fri Dec 18 02:35:46 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 17 Dec 2020 08:35:46 -0800 Subject: [COFF] Algol68 (was Re: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> <7e66e5eb-6cea-5403-a2cc-e8d93f038e66@gmail.com> Message-ID: <8D8E8160-F6F9-461A-BDFD-0E0A0E4C1A2B@iitbombay.org> On Dec 16, 2020, at 8:08 PM, John Cowan wrote: > > Sometimes I wonder what would have happened if A68 had become the medium-level language of Unix, and Pascal had become the language of non-Unix, instead of both of them using C. Funny how we seem to rehash the same things over the years! In a 1988 comp.lang.misc thread when I expressed hope that "a major subset of Algol 68 with a new and concise syntax (sort of like C's) can make a very elegant, type safe and well rounded language.", Piet van Oostrum[1] commented the combination of dynamic arrays *and* unions forced the use of GC in Algol68. Either feature by themselves wouldn't have required GC! The larger point being that compiler complexity is "almost exponential" (his words) to the number of added features. Piet and others also wrote that both Pascal and C had left out a lot of the hard things in A68. So I doubt A68 or a subset would have replaced C or Pascal in 70s-80s. [My exposure to Algol68 was when I had stumbled upon Brailsford and Walker's wonderful "Introductory Algol 68 programming" @ USC. After having used PL/I, Pascal & Fortran the regularity of A68 was quite enticing but AFAIK no one used A68 at USC. I must admit I still like it more than modern languages like Java, Go, Rust, C++, ...] [1] Piet had implemented major parts of both A68 and A60. From imp at bsdimp.com Fri Dec 18 03:57:13 2020 From: imp at bsdimp.com (Warner Losh) Date: Thu, 17 Dec 2020 10:57:13 -0700 Subject: [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <20201217155039.GA13368@mcvoy.com> References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> <20201217155039.GA13368@mcvoy.com> Message-ID: On Thu, Dec 17, 2020 at 8:50 AM Larry McVoy 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Dec 18 04:00:48 2020 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 17 Dec 2020 10:00:48 -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> <20201217155039.GA13368@mcvoy.com> Message-ID: <20201217180048.GG13368@mcvoy.com> On Thu, Dec 17, 2020 at 10:57:13AM -0700, Warner Losh wrote: > On Thu, Dec 17, 2020 at 8:50 AM Larry McVoy 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. 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. From michael at kjorling.se Fri Dec 18 04:30:51 2020 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 17 Dec 2020 18:30:51 +0000 Subject: [COFF] [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <20201217180048.GG13368@mcvoy.com> References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> <20201217155039.GA13368@mcvoy.com> <20201217180048.GG13368@mcvoy.com> Message-ID: On 17 Dec 2020 10:00 -0800, from lm at 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 at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From clemc at ccc.com Fri Dec 18 07:10:03 2020 From: clemc at ccc.com (Clem Cole) Date: Thu, 17 Dec 2020 16:10:03 -0500 Subject: [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <20201217180048.GG13368@mcvoy.com> References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> <20201217155039.GA13368@mcvoy.com> <20201217180048.GG13368@mcvoy.com> Message-ID: On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy 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 ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Dec 18 11:25:49 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 17 Dec 2020 17:25:49 -0800 Subject: [COFF] Algol68 (was Re: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> <7e66e5eb-6cea-5403-a2cc-e8d93f038e66@gmail.com> <8D8E8160-F6F9-461A-BDFD-0E0A0E4C1A2B@iitbombay.org> Message-ID: <3E1EB4E6-DC67-4FD9-A9DF-41568854205D@iitbombay.org> On Dec 17, 2020, at 4:31 PM, John Cowan wrote: > > > > On Thu, Dec 17, 2020 at 11:35 AM Bakul Shah > wrote: > Funny how we seem to rehash the same things over the years! > > Ars longa, vita brevis. > In a 1988 comp.lang.misc thread when I expressed hope that "a major > subset of Algol 68 with a new and concise syntax (sort of like C's) > can make a very elegant, type safe and well rounded language.", > > Thanks. The URL is >. > Piet > van Oostrum[1] commented the combination of dynamic arrays *and* > unions forced the use of GC in Algol68. Either feature by themselves > wouldn't have required GC! > > I can't find this anywhere in the thread or elsewhere in comp.lang.misc. Do you have a reference? Here's the link: https://groups.google.com/g/comp.lang.misc/c/qkmB_3zuC7Y/m/erN_TfDF38IJ > In any case, I don't understand how a safe language with pointers can avoid the need for *some* kind of GC. Note that I was talking about a "type safe" subset as opposed to as stricter "safe" subset. One can argue that Pascal was type safe even with new() / dispose() for pointers. [Referencing a dead pointer is a runtime error, just like divide by zero] I think his point was more that each of dynamic arrays by themselves wouldn't require GC and the same for unions. Remember I was talking about a vague typesafe subset. So the question is which features to remove? Rmoving pointers would certainly be under consideration. > [My exposure to Algol68 was when I had stumbled upon Brailsford and > Walker's wonderful "Introductory Algol 68 programming" > > Alas, I can only find this at one shady site, or in hardback at Amazon for USD 20 which is a lot for a pig in a poke (no preview). I think it was less useful as an introduction to programming but was just right for me! There are other introductory books/articles including one by Andrew Tanenbaum: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.4668&rep=rep1&type=pdf Lindsey and van der Muellen's Informal Introduction to Algol 68: http://www.softwarepreservation.org/projects/ALGOL/book/Lindsey_van_der_Meulen-IItA68-Revised.pdf J.E.L.Peck's Algol Companion may also be of help: http://www.softwarepreservation.org/projects/ALGOL/paper/An%20Algol%2068%20Companion.pdf I have heard good things about Frank Pagan's A Practical Guide to Algol 68... -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Fri Dec 18 17:47:18 2020 From: bakul at iitbombay.org (Bakul Shah) Date: Thu, 17 Dec 2020 23:47:18 -0800 Subject: [COFF] Running Scheme On Bare Metal (Experience Report) Message-ID: <32DDA988-8571-4240-8652-10F59B13030C@iitbombay.org> https://www.youtube.com/watch?v=GWr4iQfc0uw Abstract of the talk @ ICFP 2020 Programming language implementations have features such as threads, memory management, type safety, and REPLs that duplicate some of the work done by the underlying operating system. The objective of hosting a language on bare metal is to unify the language implementation and operating system to have a lean system with no redundancy for running applications. This seems to be the OS: https://github.com/udem-dlteam/mimosa The Mimosa operating system consists of a minimal kernel built on C++ and Scheme. It contains a Scheme implementation of a hard drive (ATA) driver, keyboard (PS2), serial (8250 UART), FAT32 filesystem and a small real time clock manager. The project was built to experiment with developement of operating system using a high level functional language to study the developement process and the use of Scheme to build a fairly complex system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Dec 18 10:31:36 2020 From: cowan at ccil.org (John Cowan) Date: Thu, 17 Dec 2020 19:31:36 -0500 Subject: [COFF] Algol68 (was Re: [TUHS] Were cron and at done at the same time? Or one before the other? In-Reply-To: <8D8E8160-F6F9-461A-BDFD-0E0A0E4C1A2B@iitbombay.org> References: <88E7F8CE-DC08-44AB-BF12-EFD4C5958950@iitbombay.org> <7e66e5eb-6cea-5403-a2cc-e8d93f038e66@gmail.com> <8D8E8160-F6F9-461A-BDFD-0E0A0E4C1A2B@iitbombay.org> Message-ID: On Thu, Dec 17, 2020 at 11:35 AM Bakul Shah wrote: > Funny how we seem to rehash the same things over the years! > Ars longa, vita brevis. > In a 1988 comp.lang.misc thread when I expressed hope that "a major > subset of Algol 68 with a new and concise syntax (sort of like C's) > can make a very elegant, type safe and well rounded language.", Thanks. The URL is < https://groups.google.com/u/2/g/comp.lang.misc/c/qkmB_3zuC7Y/m/-Bk9z-oZaqYJ >. > Piet > van Oostrum[1] commented the combination of dynamic arrays *and* > unions forced the use of GC in Algol68. Either feature by themselves > wouldn't have required GC! I can't find this anywhere in the thread or elsewhere in comp.lang.misc. Do you have a reference? In any case, I don't understand how a safe language with pointers can avoid the need for *some* kind of GC. [My exposure to Algol68 was when I had stumbled upon Brailsford and > Walker's wonderful "Introductory Algol 68 programming" Alas, I can only find this at one shady site, or in hardback at Amazon for USD 20 which is a lot for a pig in a poke (no preview). John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org "But I am the real Strider, fortunately," he said, looking down at them with his face softened by a sudden smile. "I am Aragorn son of Arathorn, and if by life or death I can save you, I will." -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Dec 19 00:43:32 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Dec 2020 06:43:32 -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> <20201217155039.GA13368@mcvoy.com> <20201217180048.GG13368@mcvoy.com> Message-ID: <20201218144332.GH13368@mcvoy.com> On Thu, Dec 17, 2020 at 04:10:03PM -0500, Clem Cole wrote: > On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy 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. 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. From clemc at ccc.com Sat Dec 19 01:46:10 2020 From: clemc at ccc.com (Clem Cole) Date: Fri, 18 Dec 2020 10:46:10 -0500 Subject: [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <20201218144332.GH13368@mcvoy.com> References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> <20201217155039.GA13368@mcvoy.com> <20201217180048.GG13368@mcvoy.com> <20201218144332.GH13368@mcvoy.com> Message-ID: Excellent! ᐧ On Fri, Dec 18, 2020 at 9:43 AM Larry McVoy wrote: > On Thu, Dec 17, 2020 at 04:10:03PM -0500, Clem Cole wrote: > > On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy 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. > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Sat Dec 19 03:41:58 2020 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Fri, 18 Dec 2020 12:41:58 -0500 Subject: [COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: <20201218144332.GH13368@mcvoy.com> References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> <20201217155039.GA13368@mcvoy.com> <20201217180048.GG13368@mcvoy.com> <20201218144332.GH13368@mcvoy.com> Message-ID: 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 From lm at mcvoy.com Sat Dec 19 05:24:07 2020 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 18 Dec 2020 11:24:07 -0800 Subject: [COFF] [TUHS] Algol 68 and Unix (was cron and at ...) In-Reply-To: References: <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com> <20201217143558.GD13268@mcvoy.com> <20201217155039.GA13368@mcvoy.com> <20201217180048.GG13368@mcvoy.com> <20201218144332.GH13368@mcvoy.com> Message-ID: <20201218192407.GC849@mcvoy.com> 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.