From moody at posixcafe.org Tue Oct 1 01:00:31 2024 From: moody at posixcafe.org (Jacob Moody) Date: Mon, 30 Sep 2024 10:00:31 -0500 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> <202409300816.48U8GuKj303510@freefriends.org> Message-ID: <980281fd-8377-4780-bddc-cb0cd2ed6ff0@posixcafe.org> On 9/30/24 07:10, Russ Cox wrote: > On Mon, Sep 30, 2024 at 4:17 AM > wrote: > > > One of the tidyings I did during covid lockdown was to rewrite > > rc's parser not to use yacc anymore [1], specifically to make > > it easy to allow "foo x=y". As I wrote in the commit message, > > dd fans rejoice! (Also fans of -foo=bar flag syntax.) > > Very cool. Have other Plan 9 distros picked this up? Just wondering. > > > I looked at https://9p.io/plan9/ and also 9front and neither has the change. > I don't think either is particularly maintained at this point. Since (and including) 2020, 9front has averaged 700 commits a year to the project, a very large portion of that being bug fixes and upkeep. We've also been presenting some of the more interesting new work at recent IWP9 conferences, now that they've become a yearly occurrence again thanks to the Plan 9 Foundation. From my perspective things have been quite lively lately. We did take a look at your rc parser changes (closer to when they were first pushed to plan9port) but had decided not to adopt them at the time. Thank you, Jacob Moody From paul.winalski at gmail.com Tue Oct 1 01:49:28 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 30 Sep 2024 11:49:28 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928180559.GF9067@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180559.GF9067@mcvoy.com> Message-ID: [moving to COFF as this has drifted away from Unix] On Sat, Sep 28, 2024 at 2:06 PM Larry McVoy wrote: > I have a somewhat different view. I have a son who is learning to program > and he asked me about C. I said "C is like driving a sports car on a > twisty mountain road that has cliffs and no guard rails. If you want to > check your phone while you are driving, it's not for you. It requires > your full, focussed attention. So that sounds bad, right? Well, if > you are someone who enjoys driving a sports car, and are good at it, > perhaps C is for you." > > If you really want a language with no guard rails, try programming in BLISS. Regarding C and C++ having dangerous language features--of course they do. Every higher-level language I've ever seen has its set of toxic language features that should be avoided if you want reliability and maintainability for your programs. And a set of things to avoid if you want portability. Regarding managed dynamic memory allocation schemes that use garbage collection vs. malloc()/free(), there are some applications where they are not suitable. I'm thinking about real-time programs. You can't have your missle defense software pause to do garbage collection when you're trying to shoot down an incoming ballistic missile. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Oct 1 02:05:52 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 30 Sep 2024 12:05:52 -0400 Subject: [TUHS] On computerese In-Reply-To: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Sat, Sep 28, 2024 at 8:49 PM Aron Insinga wrote: > For the counter-example, I wonder if anyone ever tried to type very much > (verbose) DCL on VAX/VMS using a Teletype. :-) > > I had occasion to use an ASR model 33 Teletype with VAX/VMS. Hated it. The DECwriter LA36 was acceptable, though. While DCL commands generally involved complete words, they could be abbreviated to the smallest unique abbreviation. Thus one mostly typed DIR instead of DIRECTORY. Command keywords also were be required to be unique in the first 4 characters--the DCL parser ignored all but the first four. characters. The engineers at DEC's Marlboro MA facility named one of their networked machines TWINKIE so that to log into it they could type SET HOSTESS TWINKIE. The terse Unix command verb style can be a steep learning curve for beginners. How is one supposed to know that you say 'ls' to get a directory listing? And unfortunately man pages aren't very useful for beginners because you have to know what the command verb is in order to call up its man page. Unix lacks a place to ask questions such as "how do I get a directory listing?". -Paul W. -Paul W. > > On 9/15/24 16:43, sjenkin at canb.auug.org.au wrote: > > ... > For non touch typists, shorter commands & keywords are helpful. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Oct 1 04:07:17 2024 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Sep 2024 14:07:17 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, Sep 30, 2024 at 1:22 PM Paul Winalski wrote: > On Sat, Sep 28, 2024 at 8:49 PM Aron Insinga wrote: >> For the counter-example, I wonder if anyone ever tried to type very much (verbose) DCL on VAX/VMS using a Teletype. :-) >> > I had occasion to use an ASR model 33 Teletype with VAX/VMS. Hated it. The DECwriter LA36 was acceptable, though. > > While DCL commands generally involved complete words, they could be abbreviated to the smallest unique abbreviation. Thus one mostly typed DIR instead of DIRECTORY. Command keywords also were be required to be unique in the first 4 characters--the DCL parser ignored all but the first four. characters. The engineers at DEC's Marlboro MA facility named one of their networked machines TWINKIE so that to log into it they could type SET HOSTESS TWINKIE. > > The terse Unix command verb style can be a steep learning curve for beginners. How is one supposed to know that you say 'ls' to get a directory listing? And unfortunately man pages aren't very useful for beginners because you have to know what the command verb is in order to call up its man page. Unix lacks a place to ask questions such as "how do I get a directory listing?". This makes me wonder when the `apropos` command was introduced; surely the name was also somewhat of an obscure joke ("what is apropos of listing a directory?" is not exactly the phrase that springs immediately to mind when wondering how to list a directory). But the other form of it, `man -k`, is reasonable. Plan 9 called the similar thing, `lookman`. - Dan C. From steffen at sdaoden.eu Tue Oct 1 05:12:16 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 21:12:16 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Rob Pike wrote in : |On Mon, Sep 30, 2024 at 2:56 AM Douglas McIlroy < |douglas.mcilroy at dartmouth.edu> wrote: |>>>> malloc(0) isn't undefined behaviour but implementation defined. |>>> |>>> In modern C there is no difference between those two concepts. |> |>> Can you explain more about your view |> |> There certainly is a difference, but in this case the practical |> implications are the same: avoid malloc(0). malloc(0) lies at the \ |> high end |> of a range of severity of concerns about implementation-definedness. \ |> At the |> low end are things like the size of ints, which only affects applications |> that may confront very large numbers. In the middle is the default |> signedness of chars, which generally may be mitigated by explicit type |> declarations. |> |> For the size of ints, C offers guardrails like INT_MAX. There is no test |> to discern what an error return from malloc(0) means. |> |> Is there any other C construct that implementation-definedness renders |> useless? |Gradually the writers of optimizing compilers have leaned so hard on the |implementation-defined and undefined behaviors that, while far from |useless, C and C++ have become non-portable and dangerously insecure, as |well as often very surprising to the point that the US government arguing |against using them. Never attribute to malice what can adequately be explained by incompetence. is the signature of Poul-Henning Kamp (whose email regarding that cstr list (i did not yet have TM-74-1273-1 aka the C Reference Manual as of 1974-01-15, thank you!) was forwarded by Warren). Only propaganda left everywhere, including here, namely for Rust. But your statement in particular reminds me of "Who's afraid of a big bad optimizing compiler?" of LWN.net, from July 15, 2019. It may be fun to read by some. (Offline, searching surely works.) It ends with Acknowledgments We owe thanks to a surprisingly large number of compiler writers and members of the C and C++ standards committees who introduced us to some of the things a big bad optimizing compiler can do,[.] But i think those eh people there (that US government) surely have been hammered with "memory-safe language" a thousand times, and noone ever told them that even the eldest C can be used in a safe way; on freebsd-hackers (PHK is an early FreeBSD committer) there was one of their bikeshed threads around September 5th, after several CVEs where fixed, and another long time major contributor started a thread saying things like |>|The real takeaway here is that C is no longer sufficient for writing |>|high quality code in the 2020s. Everyone needs to adapt their tools. which (also) i (not FreeBSD, only by heart, maybe) spoke against. He was hailing Option>> or Vec::with_capacity(262144) as solutions to the CVEs. (Which, as far as i looked, had nothing really to do with C as such; one "guilty" programmer said, as far as i understood that, the same for "his CVE".) Vectors and string "objects" with (optionally) checked index access and such are uncomfortable, but easy to do, also with C, and right from the start (i said). (P.S.: i miss bit enumerations in C and C++, as compilers get stricter and stricter (you cannot even enum1|enum2 without warnings no more, in i think C23; without cast, of course), but bit flags "can" only come in via preprocessor constants, and are completely unchecked. And enum1|enum2 *i* often have, if some subtype adds flags on top of a basic type, isn't that natural, no support on that front. And cast-less "super class casts". I had not downloaded cstr#108-the_c++_programming_language yet.) --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 henry.r.bent at gmail.com Tue Oct 1 05:15:27 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 15:15:27 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > > This makes me wonder when the `apropos` command was introduced; surely > the name was also somewhat of an obscure joke ("what is apropos of > listing a directory?" is not exactly the phrase that springs > immediately to mind when wondering how to list a directory). > Looks like it was introduced in 2BSD, written by Bill Joy, though the 4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD source nor manpage are particularly enlightening about the choice of name. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Tue Oct 1 06:00:55 2024 From: halbert at halwitz.org (Dan Halbert) Date: Mon, 30 Sep 2024 16:00:55 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On 9/30/24 15:15, Henry Bent wrote: > On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > > > This makes me wonder when the `apropos` command was introduced; surely > the name was also somewhat of an obscure joke ("what is apropos of > listing a directory?" is not exactly the phrase that springs > immediately to mind when wondering how to list a directory). > > > Looks like it was introduced in 2BSD, written by Bill Joy, though the > 4.4BSD manpage claims that it was introduced in 3BSD.  Neither the BSD > source nor manpage are particularly enlightening about the choice of name. I was one of the Berkeley grad students in the office with Bill Joy around this time. I think the name probably  come from the "apropos" command in Emacs. That command is mentioned here: https://worrydream.com/refs/Stallman_1979_-_EMACS,_The_Extensible,_Customizable,_Self-Documenting_Display_Editor.pdf, which is dated June 1979, but the Emacs command existed before that date. The Berkeley source code is dated 1979: https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/apropos.c I had used Emacs at MIT as an undergraduate. Bill would sometimes ask me, "how do they do that in Emacs", or ITS, and then riff on a feature and put it into vi or whatever. Whether I suggested an "apropos" Unix command or someone wanted something like that, or I said, "sounds like 'apropos' in Emacs", I don't remember. Dan H -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Oct 1 06:03:15 2024 From: rich.salz at gmail.com (Rich Salz) Date: Mon, 30 Sep 2024 16:03:15 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930191216.tIpea9lo@steffen%sdaoden.eu> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote > noone ever told them that even the eldest C can be used in a safe > way; Perhaps we have different meanings of the word safe. void foo(char *p) { /* interesting stuff here */ ; free(p); } void bar() { char *p = malloc(20); foo(p); printf("foo is %s\n", p); foo(p); } Why should I have to think about this code when the language already knows what is wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Oct 1 06:11:27 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 16:11:27 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, 30 Sept 2024 at 16:01, Dan Halbert wrote: > On 9/30/24 15:15, Henry Bent wrote: > > On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > >> >> This makes me wonder when the `apropos` command was introduced; surely >> the name was also somewhat of an obscure joke ("what is apropos of >> listing a directory?" is not exactly the phrase that springs >> immediately to mind when wondering how to list a directory). >> > > Looks like it was introduced in 2BSD, written by Bill Joy, though the > 4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD > source nor manpage are particularly enlightening about the choice of name. > > > I was one of the Berkeley grad students in the office with Bill Joy around > this time. I think the name probably come from the "apropos" command in > Emacs. That command is mentioned here: > https://worrydream.com/refs/Stallman_1979_-_EMACS,_The_Extensible,_Customizable,_Self-Documenting_Display_Editor.pdf, > which is dated June 1979, but the Emacs command existed before that date. > The Berkeley source code is dated 1979: > https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/apropos.c > > I had used Emacs at MIT as an undergraduate. Bill would sometimes ask me, > "how do they do that in Emacs", or ITS, and then riff on a feature and put > it into vi or whatever. Whether I suggested an "apropos" Unix command or > someone wanted something like that, or I said, "sounds like 'apropos' in > Emacs", I don't remember. > That definitely tracks with an outlier I turned up in my search of sources, an "apropos.doc" that appears on the CSRG DVD with the sources for CMU Emacs. It's just a list of mappings from commands to keybindings, for example: ... delete-next-character ^D delete-next-word ESC-D delete-other-windows ^X1 delete-previous-character ^H delete-previous-character RUBOUT ... I'm not particularly an Emacs person, but it looks like it could be the output from an "apropos" command, or perhaps the input to it. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rik at rikfarrow.com Tue Oct 1 06:14:48 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Mon, 30 Sep 2024 13:14:48 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930191216.tIpea9lo@steffen%sdaoden.eu> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: This is the 'problem' with C/C++: it's not the language itself so much as the people who are allowed, or forced, to use it. Many, if not all, of the people on this list have worked with great programmers, when most programmers are average at best. I saw some terrible things back when doing technical sales support for a startup selling a graphics library with C bindings. I came away convinced that most of the 'programmers' I was training were truly clueless. Rik On Mon, Sep 30, 2024 at 12:12 PM Steffen Nurpmeso > Never attribute to malice what can adequately be explained by > incompetence. > > is the signature of Poul-Henning Kamp (whose email regarding that > cstr list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Oct 1 06:39:07 2024 From: clemc at ccc.com (Clem Cole) Date: Mon, 30 Sep 2024 16:39:07 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, Sep 30, 2024 at 4:01 PM Dan Halbert wrote: > I was one of the Berkeley grad students in the office with Bill Joy around > this time. > IIRC Dark curly hair, and I can not think of his name either. I bet if I saw a picture, I could identify him. apropos(1) was a great hack, but I always thought whoever came up with locate(1) really hit the jackpot. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Oct 1 06:51:00 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 22:51:00 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Henry Bent wrote in : |On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: |> This makes me wonder when the `apropos` command was introduced; surely |> the name was also somewhat of an obscure joke ("what is apropos of |> listing a directory?" is not exactly the phrase that springs |> immediately to mind when wondering how to list a directory). |> | |Looks like it was introduced in 2BSD, written by Bill Joy, though the |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD |source nor manpage are particularly enlightening about the choice of name. "a pro position" maybe. (Having said that #?0|kent:linux$ apropos 'directory list' CURLOPT_DIRLISTONLY (3) - ask for names only in a directory listing vs #?0|kent:linux$ apropos 'list directory' dir (1) - list directory contents ls (1) - list directory contents ls (1p) - list directory contents vdir (1) - list directory contents vs #?0|kent:linux$ apropos -a list directory chacl (1) - change the access control list of a file or directory CURLOPT_DIRLISTONLY (3) - ask for names only in a directory listing dir (1) - list directory contents ls (1) - list directory contents ls (1p) - list directory contents vdir (1) - list directory contents vs #?0|kent:linux$ apropos -a directory list ..same.. needs a "pro user" from the start; AI would instead and additionally clean your back i would assume. --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 Tue Oct 1 07:15:39 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 23:15:39 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <20240930211539.94nSvOdZ@steffen%sdaoden.eu> Rich Salz wrote in : |On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote |> noone ever told them that even the eldest C can be used in a safe |> way; | |Perhaps we have different meanings of the word safe. | | void foo(char *p) { /* interesting stuff here */ ; free(p); } | void bar() { char *p = malloc(20); | foo(p); | printf("foo is %s\n", p); | foo(p); |} |Why should I have to think about this code when the language already knows |what is wrong. It can also be used in an unsafe way? O-ha. Sounds dangerous in my ears (given human behaviour in particular). I was so focused on winning against Putin, .. that i did realize this context. (Btw i like The Cures new song "Alone", after 14 years!, and its accompanying thrilling mega mega boom boom boom video.) P.S.: In the real world i would now, as the conservative and integer (up against the floating-point!) person that i am point "you" to C++, and simply pass a string object. But let us pass a reference so we gain compile-time non-NIL "meat" (vegan!!), and impressive state-of-the-art speed characteristics. Human behaviour can destroy everything: faster so with C++! --End of Btw i hate these random message-ids, they reveal nothing! Like in all those rooms i never visit. I am all for the wonderful Klaus von Dohnanyi, now also 96 years old, and his saying "Ach bitte, sagen Sie nicht Chatroom, sagen Sie Plauderstübchen" ("Oh please, do not say chatroom, just say [little talk chamber][ʃtyːpçən]" [1] (needs scripting-enabled browser). [1] https://translate.google.com/?sl=auto&tl=en&text=Plauderst%C3%BCbchen&op=translate --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 henry.r.bent at gmail.com Tue Oct 1 07:25:09 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 17:25:09 -0400 Subject: [TUHS] On computerese In-Reply-To: <20240930205100.iOO2gbzi@steffen%sdaoden.eu> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso wrote: > Henry Bent wrote in > : > |On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > |> This makes me wonder when the `apropos` command was introduced; surely > |> the name was also somewhat of an obscure joke ("what is apropos of > |> listing a directory?" is not exactly the phrase that springs > |> immediately to mind when wondering how to list a directory). > |> > | > |Looks like it was introduced in 2BSD, written by Bill Joy, though the > |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD > |source nor manpage are particularly enlightening about the choice of > name. > > "a pro position" maybe. > > needs a "pro user" from the start; AI would instead and > additionally clean your back i would assume. > Well, I no longer have institutional access to the full Oxford English Dictionary, but Merriam Webster is happy to provide an extended paragraph (!) on the etymology: -- *Apropos* wears its ancestry like a badge—or a beret. From the French phrase *à propos*, meaning “to the purpose,” the word’s emphasis lands on its last syllable, which ends in a silent “s”: \ap-ruh-POH. *Apropos* typically functions as an adjective describing what is suitable or appropriate (“an apropos comment”), or as a preposition (with or without *of*) meaning “with regard to,” as in “apropos (of) the decision, implementation will take some time.” The phrase “apropos of nothing” suggests that something does not relate to a specified topic. -- -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Oct 1 08:00:35 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Oct 2024 00:00:35 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <20240930220035.3nZHrUot@steffen%sdaoden.eu> Rik Farrow wrote in : |On Mon, Sep 30, 2024 at 12:12 PM Steffen Nurpmeso  | || Never attribute to malice what can adequately be explained by || incompetence. | ||is the signature of Poul-Henning Kamp (whose email regarding that ||cstr list |This is the 'problem' with C/C++: it's not the language itself so much as |the people who are allowed, or forced, to use it. Many, if not all, of the |people on this list have worked with great programmers, when most |programmers are average at best. I saw some terrible things back when doing |technical sales support for a startup selling a graphics library with C |bindings. I came away convinced that most of the 'programmers' I was |training were truly clueless. I cannot comment on that, humans "get a good job with more pay you are ok", have interests here and there, have (unfulfilled) desires, problems with family or partner, aka "that sex machine", and so in the end one can be lucky if that was not Jeffrey Dahmer or something, and you do not end up as canned. "Or forced", yes! Here on this lists are (me aside) intellectual but especially witty people who love(d) their (likely) even-more-than-a-job, at the "top of the pyramid", Mr. McIlroy just again remembered an impressive scenario of how these people were (and are) self-driving up that spiral staircase with nothing but the help of their mind and a free library .. which was available for them. Other than that, you know, there are plenty of languages with plenty of support (syntax checks, sanitizers, "debug stuff"), far beyond vim(1), let that start with JAVA (documented pretty well right from the start as far as i know), and all the other options that arose since then, and in parts are used. I personally "go on the gums" if i have to work with OpenSSL, and image processing is no fun either, so it could be it was me who drove you down... (And complexity is never easy, i think, to noone.) --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 tuhs at tuhs.org Tue Oct 1 08:14:38 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 30 Sep 2024 15:14:38 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Sep 30, 2024, at 1:03 PM, Rich Salz wrote: > > > On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote > noone ever told them that even the eldest C can be used in a safe > way; > Perhaps we have different meanings of the word safe. > > void foo(char *p) { /* interesting stuff here */ ; free(p); } > void bar() { char *p = malloc(20); > foo(p); > printf("foo is %s\n", p); > foo(p); > } > Why should I have to think about this code when the language already knows what is wrong. The language doesn't know! The compiler can't know without the programmer indicating this somehow, especially if foo() is an extern function. I am still interested in making C safer (to secure as best as possible all the zillions of lines of C code in OS kernels). The question is, can we retrofit safety features into C without doing major violence to it & turning it into an ugly mess? No idea if this is even feasible but seems worth exploring with possibly a great ROI. Take the above code as an example. It is "free()" that invalidates the value of its argument on return and this property is then inherited by its callers. One idea is to declare free as follows: void free(`zap void*ptr); // `zap is says *ptr will be invalid on return Now a compiler can see and complain that foo() will break this and insist that foo() too must express the same thing. So we change it to void foo(`zap char* p) { ... free(p); } Now the compiler knows p can't dereferenced after calling foo() and can complain on seeing p being printf'ed. This was just an example of an idea -- remains to be seen if it amounts to anything useful. In an earlier email I had explored bounds checking. Clearly all such extensions would have to play well together as well as with the existing language. My hope is that the language can be evolved in this way and gradually kernel code can be fixed up to benefit from it. Bakul From steffen at sdaoden.eu Tue Oct 1 08:38:00 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Oct 2024 00:38:00 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: <20240930223800.Z9vdkp7Q@steffen%sdaoden.eu> Henry Bent wrote in : |On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso wrote: |> Henry Bent wrote in |> : |>|On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: |>|> This makes me wonder when the `apropos` command was introduced; surely |>|> the name was also somewhat of an obscure joke ("what is apropos of |>|> listing a directory?" is not exactly the phrase that springs |>|> immediately to mind when wondering how to list a directory). |>| |>|Looks like it was introduced in 2BSD, written by Bill Joy, though the |>|4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD |>|source nor manpage are particularly enlightening about the choice of |> name. |> |> "a pro position" maybe. |> |> needs a "pro user" from the start; AI would instead and |> additionally clean your back i would assume. | |Well, I no longer have institutional access to the full Oxford English |Dictionary, but Merriam Webster is happy to provide an extended paragraph |(!) on the etymology: Oh! Apropos is known in Germany as a (*that*) word, too, also commonly heard, even in the (upper) middle class, but sounding like "apro-poh" here. Ef "Apropos -- have i already" etc etc. I was "only leaving of the e of that creat", so to say. (I am not looking at the online "Duden" because they now require Javascript and tracking, if i recall correctly.) |-- |*Apropos* wears its ancestry like a badge—or a beret. From the French |phrase *à propos*, meaning “to the purpose,” the word’s emphasis lands on |its last syllable, which ends in a silent “s”: \ap-ruh-POH. *Apropos* |typically functions as an adjective describing what is suitable or |appropriate (“an apropos comment”), or as a preposition (with or without |*of*) meaning “with regard to,” as in “apropos (of) the decision, |implementation will take some time.” The phrase “apropos of nothing” |suggests that something does not relate to a specified topic. |-- | |-Henry --End of --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 tuhs at tuhs.org Tue Oct 1 08:46:44 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 30 Sep 2024 15:46:44 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: Apropos of apropos: https://www.etymonline.com/search?q=apropos etymonline.com is my goto etymological dictionary site. > On Sep 30, 2024, at 2:25 PM, Henry Bent wrote: > > On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso > wrote: >> Henry Bent wrote in >> >: >> |On Mon, 30 Sept 2024 at 14:08, Dan Cross > wrote: >> |> This makes me wonder when the `apropos` command was introduced; surely >> |> the name was also somewhat of an obscure joke ("what is apropos of >> |> listing a directory?" is not exactly the phrase that springs >> |> immediately to mind when wondering how to list a directory). >> |> >> | >> |Looks like it was introduced in 2BSD, written by Bill Joy, though the >> |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD >> |source nor manpage are particularly enlightening about the choice of name. >> >> "a pro position" maybe. >> >> needs a "pro user" from the start; AI would instead and >> additionally clean your back i would assume. > > Well, I no longer have institutional access to the full Oxford English Dictionary, but Merriam Webster is happy to provide an extended paragraph (!) on the etymology: > > -- > Apropos wears its ancestry like a badge—or a beret. From the French phrase à propos, meaning “to the purpose,” the word’s emphasis lands on its last syllable, which ends in a silent “s”: \ap-ruh-POH. Apropos typically functions as an adjective describing what is suitable or appropriate (“an apropos comment”), or as a preposition (with or without of) meaning “with regard to,” as in “apropos (of) the decision, implementation will take some time.” The phrase “apropos of nothing” suggests that something does not relate to a specified topic. > -- > > -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Tue Oct 1 09:25:28 2024 From: phil at ultimate.com (Phil Budne) Date: Mon, 30 Sep 2024 19:25:28 -0400 Subject: [TUHS] Origins of "Unix Philosophy" Message-ID: <202409302325.48UNPSfs020034@ultimate.com> I'm wondering if there are places where people who were in the Unix Room wrote about the origins and evolution of what people (at least used to(*)) refer to as "Unix Philosophy", and since some are in THIS (TUHS) room, what they might have to say about it. How much was in reaction to the complexity of Multics, and how much was simply a response to the limited address spaces of available and affordable hardware? Eric S. Raymond wrote in "The Art of Unix Programming" quoting Doug McIlroy and Rob Pike: http://www.catb.org/esr/writings/taoup/html/ch01s06.html And I wonder if they care to comment on it? I have trouble taking ESR as authoritative, as, it seems to me that Research Unix was more a product of the "Cathedral" (or at least a contained community) than the "Bazaar" (at least the modern bazaar, where everyone needs to leave a new feature grafito on the town walls), and ESR A side question for Rob Pike, is the "Not only is UNIX dead, it's starting to smell really bad." quote accurate? Was it in reaction to BSD, GNU, or all of the above? (*) I say "used to", because, for the most part, minimalism seems to have left the building. I can't look at modern GNU utilities, and many, if not most open source packages and think they've gone WAY past classic Unix minimalism, especially since I remember hearing that Bell Research had happily stripped excess features (removal of "cat -s" sticks in my mind) from later day research Unix, and because Stallman is said to have coined the term "New Jersey" style as a synonym for what Richard P. Gabriel called "Worse is Better", which seems, an attack on minimalism (nothing less than "the right thing" is acceptable) Worse is.... readings: https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/Files/IsWorseReallyBetter.pdf https://dreamsongs.com/Files/worse-is-worse.pdf Anti-flamage disclainmers: Inclusion of links above does not imply any agreement on my part! My apologies in advance for any offense, misquote, or misunderstanding on my part. From flexibeast at gmail.com Tue Oct 1 11:42:00 2024 From: flexibeast at gmail.com (Alexis) Date: Tue, 01 Oct 2024 11:42:00 +1000 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: (Bakul Shah via TUHS's message of "Mon, 30 Sep 2024 15:14:38 -0700") References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <87setgzjiv.fsf@gmail.com> Bakul Shah via TUHS writes: > I am still interested in making C safer (to secure as best as > possible > all the zillions of lines of C code in OS kernels). The question > is, > can we retrofit safety features into C without doing major > violence to > it & turning it into an ugly mess? No idea if this is even > feasible > but seems worth exploring with possibly a great ROI. Related: Ten years ago, Pascal Cuoq, Matthew Flatt, and John Regehr proposed "Friendly C": > We are not trying to fix the deficiencies of the C language nor > making > an argument for or against C. Rather, we are trying rescue the > predictable little language that we all know is hiding within > the C > standard. This language generates tight code and doesn’t make > you feel > like the compiler is your enemy. We want to decrease the rate of > bit > rot in existing C code and also to reduce the auditing overhead > for > safety-critical and security-critical C code. The intended > audience > for -std=friendly-c is people writing low-level systems such as > operating systems, embedded systems, and programming language > runtimes. These people typically have a good guess about what > instructions the compiler will emit for each line of C code they > write, and they simply do not want the compiler silently > throwing out > code. If they need code to be faster, they’ll change how it is > written. -- https://blog.regehr.org/archives/1180 Some of the concrete features proposed included: > 1. The value of a pointer to an object whose lifetime has ended > remains the same as it was when the object was alive. > > 2. Signed integer overflow results in two’s complement wrapping > behavior at the bitwidth of the promoted type. > > 3. Shift by negative or shift-past-bitwidth produces an > unspecified > result. i seem to recall there have been other proposals in the vein of "Friendly C", but they're not coming to mind right now. Alexis. From lars at nocrew.org Tue Oct 1 14:31:12 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 01 Oct 2024 04:31:12 +0000 Subject: [TUHS] On computerese In-Reply-To: (Dan Halbert's message of "Mon, 30 Sep 2024 16:00:55 -0400") References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: <7w7caswijz.fsf@junk.nocrew.org> Dan Halbert wrote: > I had used Emacs at MIT as an undergraduate. Bill would sometimes ask > me, "how do they do that in Emacs", or ITS, and then riff on a feature > and put it into vi or whatever. Whether I suggested an "apropos" Unix > command or someone wanted something like that, or I said, "sounds like > 'apropos' in Emacs", I don't remember. I'm curious if you remember any other features that Bill might have picked up from Emacs or ITS? From you or anyone else. Another interesting example would be job control that was done by Jim Kulp. From lars at nocrew.org Tue Oct 1 14:44:47 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 01 Oct 2024 04:44:47 +0000 Subject: [TUHS] Origins of "Unix Philosophy" In-Reply-To: <202409302325.48UNPSfs020034@ultimate.com> (Phil Budne's message of "Mon, 30 Sep 2024 19:25:28 -0400") References: <202409302325.48UNPSfs020034@ultimate.com> Message-ID: <7w34lgwhxc.fsf@junk.nocrew.org> Phil Budne wrote: > Stallman is said to have coined the term "New Jersey" style as a > synonym for what Richard P. Gabriel called "Worse is Better" Do you have a source for this? Gabriel does write "New Jersey Style" in his essay. Of course, he could have got it from Stallman anyway. From arnold at skeeve.com Tue Oct 1 22:43:20 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 06:43:20 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930003630.GE17434@mcvoy.com> Message-ID: <202410011243.491ChKiV419651@freefriends.org> Luther Johnson wrote: > 'Go' is also a pretty C-like advanced C kind of thing. What do Go > writers think of it vs. C, for safety, reliability, clarity of > expression, etc. ? I have what to say about the topics in this thread, but I wanted to answer this. I've been working in Go for about two years in my current $DAYJOB. I haven't done as much of it as I'd like. As preface, I've been programming (heavily) in C since 1983 and quite a fair amount in C++ since 1999 or so, with Python in the mix more recently. Overall, I like Go. The freedom from manual memory management takes some getting used to, but is very liberating once you do. I do find it too terse in some cases, mostly in the initialization syntax, and in the use of nested function objects. I also find Go modules to be totally opaque, I don't understand them at all. One thing I'm still getting used to is the scoping with := vs. =. Here's a nasty bug that I just figured out this week. Consider: var ( clientSet *kubernetes.Interface ) func main() { .... // set the global var (we think) clientSet, err := cluster.MakeClient() // or whatever .... } func otherfunc() { // use the global var (but not really) l := clientSet.CoreV1().NetworkPolicyList(ns).Items } In main(), I *think* I'm assigning to the global clientSet so that I can use it later. But because of the 'err' and the :=, I've actually created a local variable that shadows the global one, and in otherfunc(), the global clientSet is still nil. Kaboom! The correct way to write the code is: var err error clientSet, err = cluster.MakeClient() // or whatever "When the light went on, it was blinding." Of course, the Goland IDE actually warns me that this is the case, by changing the color of clientSet in the assignment, but it's an extremely subtle warning, and if you don't hover over it, and you're not paying a lot of attention to the coloring, you miss it. So, I like Go, and for a new project that I wouldn't write in Awk or Python, I would use Go. The time or two I've looked at Rust, it seemed to be just too difficult to learn, as well as still evolving too fast. It does look like Rust will eventually replace C and C++ for new systems level code. We can hope that will be a good thing. My two cents, Arnold From crossd at gmail.com Tue Oct 1 22:53:46 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Oct 2024 08:53:46 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Mon, Sep 30, 2024 at 4:22 PM Rik Farrow wrote: > This is the 'problem' with C/C++: it's not the language itself so much as the people who are allowed, or forced, to use it. Programmer ability is certainly an issue, but I would suggest that another goes back to what Rob was alluding to: compiler writers have taken too much advantage of UB, making it difficult to write well-formed programs that last. The `realloc` function I mentioned earlier is a good case in point; the first ANSI C standard says this: "If ptr is a null pointer, the realloc function behaves like the malloc function for the specified size. ... If size is zero and ptr is not a null pointer, the object it points to is freed." While the description of `malloc` doesn't say thing about what happens when `size` is 0, perhaps making `realloc(0, NULL)` nominally UB (??), the behavior of `realloc(0, ptr)` is clearly well defined when `ptr` is not nil, and it's entirely possible that programs were written with that well-defined behavior as an assumption. (Worth mentioning is that this language was changed in C99, and implementations started differing from there.) But now, C23 has made `realloc(0, ptr)` UB, regardless of the value of `ptr`, and since compiler writers have given themselves license to take an extremely broad view of what they can do if a program exhibits UB, programs that were previously well-defined with respect to C90 may well stop working properly when compiled with modern compilers. I don't think this is a hypothetical; C programs that appear to be working as expected for years have, and will continue, to suddenly break when compiled with a newer compiler, because the programmer tripped a UB trigger somewhere along the way, likely without even recognizing it. Moreover, I don't believe that there are any non-trivial C programs out there that don't have such timebombs lurking throughout. How could they not, if things that were previously well-defined can become UB in subsequent revisions of the standard? Perhaps I've mentioned it before, but a great example of the surprising nature of UB is the following program: unsigned short mul(unsigned short a, unsigned short b) { return a * b; } Is this tiny function always well-defined? Sadly, no, at least not on most common platforms where `int` is 32 bits and `short` is 16. On such platforms, the "usual arithmetic conversions" will kick in before the multiplication, and the values will be converted to _signed_ ints and _then_ multiplied; the product will then be converted back to `unsigned short`. And while the type conversion process both ways is well-defined, there exist values a,b of type unsigned short so that a*b will overflow a signed 32-bit int (consider 0xffff*0xffff), and signed integer overflow is UB; a compiler would be well within its rights to assume that such overflow can never occur and generate, say, a saturating multiplication instruction if it so chose. This would work, be perfectly legal, and almost certainly be surprising to the programmer. The fix is simple, of course: unsigned short mul(unsigned short a, unsigned short b) { unsigned int aa = a, bb = b; return aa * bb; } But one would have to know to write such a thing in the first place. > Many, if not all, of the people on this list have worked with great programmers, when most programmers are average at best. I saw some terrible things back when doing technical sales support for a startup selling a graphics library with C bindings. I came away convinced that most of the 'programmers' I was training were truly clueless. My sense is that tossing in bad programmers is just throwing gasoline onto a dumpster fire. Particularly when they look to charlatans like Robert Martin or Allen Holub as sources of education and inspiration instead of seeking out proper sources of education. - Dan C. From arnold at skeeve.com Tue Oct 1 23:13:04 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 07:13:04 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928180138.aygrwqdwrvq3n6xt@illithid> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> Message-ID: <202410011313.491DD4ac421643@freefriends.org> This is long, my apologies. "G. Branden Robinson" wrote: > [ screed omitted ] Branden, as they say, Hindsight is 20-20. But one needs to take into account that Unix and C evolved, and in particular on VERY small machines. IIRC the original Unix PDP-11s didn't even have split I/D spaces. Getting a decent compiler into that small an address space isn't easy (and by now is a lost art). The evolution was gradual and, shall we say "organic", without the pretension and formalisms of a language committee, but simply to meet the needs of the Bell Labs researchers. The value of a high level language for OS work was clear from Multics. But writing a PL/1 compiler from scratch for the tiny PDP-11 address space made no sense. Thus the path from BCPL to B to C. Today, new languages are often reactions to older ones. Java, besides the JVM portability, tried to clean up the syntax of C / C++ and add some safety and modernism (graphics, concurrency). C# was a reaction to (and a way to compete with) Java. Go was very clearly in reaction to current C++, but headed back in the direction of simplicity. Successfully, IMHO. Would the word have been better off if Ada had caught on everywhere? Probably. When I was in grad school studying language design, circa 1982, it was expected to do so. But the language was VERY challenging for compiler writers. C was easy to port, and then Unix along with it. C'est la vie. Larry wrote: > I have a somewhat different view. I have a son who is learning to program > and he asked me about C. I said "C is like driving a sports car on a > twisty mountain road that has cliffs and no guard rails. If you want to > check your phone while you are driving, it's not for you. It requires > your full, focussed attention. So that sounds bad, right? Well, if > you are someone who enjoys driving a sports car, and are good at it, > perhaps C is for you." This goes back to the evolution thing. At the time, C was a huge step up from FORTRAN and assembly. Programmers who moved to C appreciated all it gave them over what they had at the time. C programmers weren't wizards, they were simply using the best available tool. Going from a bicycle to an automobile is a big jump (to continue Larry's analogy). Larry again: > I ran a company that developed a product that was orders of magnitude more > complex than the v7 kernel (low bar but still) all in C and we had *NONE* > of those supposed problems. We were careful to use stuff that worked, > I'm "famous" in that company as the guy was viewed as "that was invented > after 1980 so Larry won't let us use it". Not true, we used mmap and used > POSIX signals, but mostly true. If you stick to the basics, C just works. > And is portable, we supported every Unix (even SCO), MacOS, Windows, and > all the Linux variants from ARM to IBM mainframes. This is also my experience with gawk, which runs on everything from ARM (Linux) to Windows to mac to VMS to z/OS (S/390x). OS issues give me more grief than language issues. > All that said, I get it, you want guard rails. You are not wrong, the > caliber of programmers these days are nowhere near Bell Labs or Sun or > my guys. This is a very important, key point. As more and more people have entered the field, the quality / education / knowledge / whatever has gone down. What was normal to learn and use back in 1983 is now too difficult for many, if not most, people, even good ones, in the field now. The people I work with here (Israel) don't know who Donald Knuth is. Two of the people in my group, over 40, didn't know what Emacs is. Shell scripting seems to be too hard for many people to master, and I see a huge amount of Cargo Cult Programming when it comes to things like scripts and Unix tools. Thus Go and Rust are good things, taking the sharp tools out of the hands of the people who aren't qualified to use them. Same thing Python. But for me, and I think others of my vintage, this state of affairs seems sad. My 4 cents, Arnold From lm at mcvoy.com Tue Oct 1 23:32:31 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 06:32:31 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: <20241001133231.GE13777@mcvoy.com> On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > Would the word have been better off if Ada had caught on everywhere? > Probably. When I was in grad school studying language design, circa 1982, > it was expected to do so. But the language was VERY challenging for > compiler writers. Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. It was the compilers course (701) and the really hard compilers course (702) at the time. The first course was to write a compiler for a subset of Ada and the second on increased the subset to be almost complete. We were supposed to do it on an IBM mainframe because the professor had his own version of lex/yacc there. Rob had a 3b1 and asked if we could do it there if he rewrote the parser stuff. Prof said sure. In one semester we had a compiler, no optimizer and not much in the way of graceful error handling, but it compiled stuff that ran. We did all of Ada other than late binding of variables (I think that was Ada's templates) and threads and probably some other stuff I don't remember. Rob is pretty smart, went on to be a tenured prof at Brown before going back to industry. Maybe he did all the heavy lifting, but I didn't find that project to very challenging. Did I miss something? > This is a very important, key point. As more and more people have > entered the field, the quality / education / knowledge / whatever > has gone down. What was normal to learn and use back in 1983 is > now too difficult for many, if not most, people, even good ones, in > the field now. > > But for me, and I think others of my vintage, this state of affairs > seems sad. 100% agree. A sharp young kid I know is/was working on finding bugs in binaries. He came to me for some insight and I had to understand what he was doing and when I did, I kept saying "just hire people that don't do this stupid stuff" and he kept laughing at me and said it was impossible. I don't consider myself to be that good of a programmer, I can point to dozens of people my age that can run circles around me and I'm sure there are many more. But apparently the bar is pretty low these days and I agree, that's sad. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From halbert at halwitz.org Tue Oct 1 23:36:37 2024 From: halbert at halwitz.org (Dan Halbert) Date: Tue, 1 Oct 2024 09:36:37 -0400 Subject: [TUHS] On computerese In-Reply-To: <7w7caswijz.fsf@junk.nocrew.org> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <7w7caswijz.fsf@junk.nocrew.org> Message-ID: <96dd889c-5749-48dc-8ea5-8910f51ca966@halwitz.org> On 10/1/24 00:31, Lars Brinkhoff wrote: > Dan Halbert wrote: >> I had used Emacs at MIT as an undergraduate. Bill would sometimes ask >> me, "how do they do that in Emacs", or ITS, and then riff on a feature >> and put it into vi or whatever. Whether I suggested an "apropos" Unix >> command or someone wanted something like that, or I said, "sounds like >> 'apropos' in Emacs", I don't remember. > I'm curious if you remember any other features that Bill might have > picked up from Emacs or ITS? From you or anyone else. > > Another interesting example would be job control that was done by Jim > Kulp. A lot of the vi visual-mode commands were inspired by emacs, like forward/back words, sentences/statements, paragraphs/functions. I specifically remember explaining the hierarchy of  ctrl-f, meta-f, ctrl-meta-f, etc., and then Bill went off and put in '{' and '}' and similar commands. And the "yank" commands were named after ctrl-Y and other "yank" commands in emacs. Those are on the 2BSD tape. Earl Cohen did the "finger" command quite soon after our class of first year grad students arrived at UCB. It's in 2BSD. I did "more" really early (https://danhalbert.org/more.html), but my very simple version did not get back into the sources, and the reworked "more" that Eric Shienbrood did is in 3BSD but not 2BSD. Dan From arnold at skeeve.com Tue Oct 1 23:47:10 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 07:47:10 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001133231.GE13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> Message-ID: <202410011347.491DlAsJ423777@freefriends.org> Larry McVoy wrote: > On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > > Would the word have been better off if Ada had caught on everywhere? > > Probably. When I was in grad school studying language design, circa 1982, > > it was expected to do so. But the language was VERY challenging for > > compiler writers. > > Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. > It was the compilers course (701) and the really hard compilers course (702) > at the time. The first course was to write a compiler for a subset of Ada > and the second on increased the subset to be almost complete. > > We were supposed to do it on an IBM mainframe because the professor had his > own version of lex/yacc there. Rob had a 3b1 and asked if we could do it > there if he rewrote the parser stuff. Prof said sure. > > In one semester we had a compiler, no optimizer and not much in the > way of graceful error handling, but it compiled stuff that ran. We did > all of Ada other than late binding of variables (I think that was Ada's > templates) and threads and probably some other stuff I don't remember. Did you do generics? That and the run time, which had some real-time bits to it (*IIRC*, it's been a long time), as well as the cross object code type checking, would have been real bears. Like many things, the first 90% is easy, the second 90% is hard. :-) > I don't consider myself to be that good of a programmer, I can point to > dozens of people my age that can run circles around me and I'm sure there > are many more. You are undoubtedly better than you give yourself credit for, even if there were people who could run circles around you. I learned a long time ago, that no matter how good you are, there's always someone better than you at something. I decided long ago to not try to compete with Superman. > But apparently the bar is pretty low these days and I agree, that's sad. And it makes it much less fun to be out in the working world. :-( Arnold From lm at mcvoy.com Wed Oct 2 00:01:02 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 07:01:02 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011347.491DlAsJ423777@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> Message-ID: <20241001140101.GG13777@mcvoy.com> On Tue, Oct 01, 2024 at 07:47:10AM -0600, arnold at skeeve.com wrote: > Larry McVoy wrote: > > > On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > > > Would the word have been better off if Ada had caught on everywhere? > > > Probably. When I was in grad school studying language design, circa 1982, > > > it was expected to do so. But the language was VERY challenging for > > > compiler writers. > > > > Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. > > It was the compilers course (701) and the really hard compilers course (702) > > at the time. The first course was to write a compiler for a subset of Ada > > and the second on increased the subset to be almost complete. > > > > We were supposed to do it on an IBM mainframe because the professor had his > > own version of lex/yacc there. Rob had a 3b1 and asked if we could do it > > there if he rewrote the parser stuff. Prof said sure. > > > > In one semester we had a compiler, no optimizer and not much in the > > way of graceful error handling, but it compiled stuff that ran. We did > > all of Ada other than late binding of variables (I think that was Ada's > > templates) and threads and probably some other stuff I don't remember. > > Did you do generics? That and the run time, which had some real-time > bits to it (*IIRC*, it's been a long time), as well as the cross > object code type checking, would have been real bears. None of those ring a bell so > Like many things, the first 90% is easy, the second 90% is hard. :-) I guess we did the easy stuff :-( > > I don't consider myself to be that good of a programmer, I can point to > > dozens of people my age that can run circles around me and I'm sure there > > are many more. > > You are undoubtedly better than you give yourself credit for, even > if there were people who could run circles around you. I learned > a long time ago, that no matter how good you are, there's always > someone better than you at something. I decided long ago to not > try to compete with Superman. Funny, I've come to the same conclusion, both in programming and my retirement hobby. There is always someone way better than me, but you are correct, that doesn't mean I'm awful. Just have more to learn. A buddy pointed out that I was probably better than 80% of the people leaving the dock, it's just I fish with a guy who is better than pretty much everyone. > > But apparently the bar is pretty low these days and I agree, that's sad. > > And it makes it much less fun to be out in the working world. :-( As a guy in his 2nd retirement (1st didn't stick) I can tell you I am so happy not having to deal with work stuff. My buddies who are still working tell me stories I find difficult to believe. They all say I'm so politically incorrect that I wouldn't last a week in today's world. If their stories are true, yeah, that's not for me. Weird politics and crappy programmers, count me out. From arnold at skeeve.com Wed Oct 2 00:18:34 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 08:18:34 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001140101.GG13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> Message-ID: <202410011418.491EIYYp426442@freefriends.org> Closing off the thread... > > Did you do generics? That and the run time, which had some real-time > > bits to it (*IIRC*, it's been a long time), as well as the cross > > object code type checking, would have been real bears. > > None of those ring a bell so > > > Like many things, the first 90% is easy, the second 90% is hard. :-) > > I guess we did the easy stuff :-( Even the easy stuff is good learning. > Funny, I've come to the same conclusion, both in programming and my > retirement hobby. There is always someone way better than me, but > you are correct, that doesn't mean I'm awful. Just have more to > learn. Right. > > > But apparently the bar is pretty low these days and I agree, that's sad. > > > > And it makes it much less fun to be out in the working world. :-( > > As a guy in his 2nd retirement (1st didn't stick) I can tell you I am > so happy not having to deal with work stuff. My buddies who are still > working tell me stories I find difficult to believe. They all say I'm > so politically incorrect that I wouldn't last a week in today's world. > If their stories are true, yeah, that's not for me. > > Weird politics and crappy programmers, count me out. I don't have to deal with the politics, and my team is good, but the company has a lot of crappy code. I am planning to retire quite soon, too. :-) Arnold From luther.johnson at makerlisp.com Wed Oct 2 00:25:04 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Tue, 1 Oct 2024 07:25:04 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001140101.GG13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> Message-ID: <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> I think because the of the orders of magnitude increase in the demand for programmers, we now have a very large number of programmers with little or no math and science (and computer science doesn't count in the point I'm trying to make here, if that's your only science, you're not going to have the models in your head from other disciplines to give you useful analogs) background, and that's a big change from 40 years ago. So that has had an effect on who is programming, how they think about it, and how languages have been marketed to that programming audience. IMHO. On 10/01/2024 07:01 AM, Larry McVoy wrote: > On Tue, Oct 01, 2024 at 07:47:10AM -0600, arnold at skeeve.com wrote: >> Larry McVoy wrote: >> >>> On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: >>>> Would the word have been better off if Ada had caught on everywhere? >>>> Probably. When I was in grad school studying language design, circa 1982, >>>> it was expected to do so. But the language was VERY challenging for >>>> compiler writers. >>> Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. >>> It was the compilers course (701) and the really hard compilers course (702) >>> at the time. The first course was to write a compiler for a subset of Ada >>> and the second on increased the subset to be almost complete. >>> >>> We were supposed to do it on an IBM mainframe because the professor had his >>> own version of lex/yacc there. Rob had a 3b1 and asked if we could do it >>> there if he rewrote the parser stuff. Prof said sure. >>> >>> In one semester we had a compiler, no optimizer and not much in the >>> way of graceful error handling, but it compiled stuff that ran. We did >>> all of Ada other than late binding of variables (I think that was Ada's >>> templates) and threads and probably some other stuff I don't remember. >> Did you do generics? That and the run time, which had some real-time >> bits to it (*IIRC*, it's been a long time), as well as the cross >> object code type checking, would have been real bears. > None of those ring a bell so > >> Like many things, the first 90% is easy, the second 90% is hard. :-) > I guess we did the easy stuff :-( > >>> I don't consider myself to be that good of a programmer, I can point to >>> dozens of people my age that can run circles around me and I'm sure there >>> are many more. >> You are undoubtedly better than you give yourself credit for, even >> if there were people who could run circles around you. I learned >> a long time ago, that no matter how good you are, there's always >> someone better than you at something. I decided long ago to not >> try to compete with Superman. > Funny, I've come to the same conclusion, both in programming and my > retirement hobby. There is always someone way better than me, but > you are correct, that doesn't mean I'm awful. Just have more to > learn. > > A buddy pointed out that I was probably better than 80% of the people > leaving the dock, it's just I fish with a guy who is better than pretty > much everyone. > >>> But apparently the bar is pretty low these days and I agree, that's sad. >> And it makes it much less fun to be out in the working world. :-( > As a guy in his 2nd retirement (1st didn't stick) I can tell you I am > so happy not having to deal with work stuff. My buddies who are still > working tell me stories I find difficult to believe. They all say I'm > so politically incorrect that I wouldn't last a week in today's world. > If their stories are true, yeah, that's not for me. > > Weird politics and crappy programmers, count me out. > From crossd at gmail.com Wed Oct 2 00:56:13 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Oct 2024 10:56:13 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: On Tue, Oct 1, 2024 at 10:32 AM Luther Johnson wrote: > I think because the of the orders of magnitude increase in the demand > for programmers, we now have a very large number of programmers with > little or no math and science (and computer science doesn't count in the > point I'm trying to make here, if that's your only science, you're not > going to have the models in your head from other disciplines to give you > useful analogs) background, and that's a big change from 40 years ago. > So that has had an effect on who is programming, how they think about > it, and how languages have been marketed to that programming audience. IMHO. I've found a grounding in mathematics useful for programming, but beyond some knowledge of the physical constraints that the universe places on us and a very healthy appreciation for the scientific method, I'm having a hard time understanding how the hard sciences would help out too much. Electrical engineering seems like it would be more useful, than, say, chemistry or geology. I talk to a lot of academics, and I think they see the situation differently than is presented here. In a nutshell, the way a lot of them look at it, the amount of computer science in the world increases constantly while the amount of time they have to teach that to undergraduates remains fixed. As a result, they have to pick and choose what they teach very, very carefully, balancing a number of criteria as they do so. What this translates to in the real world isn't that the bar is lowered, but that the bar is different. - Dan C. From stuff at riddermarkfarm.ca Wed Oct 2 01:08:06 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Tue, 1 Oct 2024 11:08:06 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: [-->COFF] On 2024-10-01 10:56, Dan Cross wrote (in part): > I've found a grounding in mathematics useful for programming, but > beyond some knowledge of the physical constraints that the universe > places on us and a very healthy appreciation for the scientific > method, I'm having a hard time understanding how the hard sciences > would help out too much. Electrical engineering seems like it would be > more useful, than, say, chemistry or geology. I see this as related to the old question about whether it is easier to teach domain experts to program or teach programmers about the domain. (I worked for a company that wrote/sold scientific libraries for embedded systems.) We had a mixture but the former was often easier. S. > > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. > > - Dan C. From lm at mcvoy.com Wed Oct 2 01:20:33 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 08:20:33 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: <20241001152033.GH13777@mcvoy.com> On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > wrote: > > I think because the of the orders of magnitude increase in the demand > > for programmers, we now have a very large number of programmers with > > little or no math and science (and computer science doesn't count in the > > point I'm trying to make here, if that's your only science, you're not > > going to have the models in your head from other disciplines to give you > > useful analogs) background, and that's a big change from 40 years ago. > > So that has had an effect on who is programming, how they think about > > it, and how languages have been marketed to that programming audience. IMHO. > > I've found a grounding in mathematics useful for programming, but > beyond some knowledge of the physical constraints that the universe > places on us and a very healthy appreciation for the scientific > method, I'm having a hard time understanding how the hard sciences > would help out too much. Electrical engineering seems like it would be > more useful, than, say, chemistry or geology. > > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. I really wish that they made students take something like the PDP-11 assembly class - it was really systems architecture, you learned the basic idea of a computer: a CPU, a bus to talk to memory, a bus to talk to I/O, how a stack works, ideally how a context switch works though that kinda blows minds (I personally don't think you are a kernel programmer if you haven't implemented swtch() or at least walked the code and understood all of it). I did all that and developed a mental model of all computers that has helped me over the last 4 decades. Yes, my model is overly simplistic but it still works, even on the x86 craziness. I don't know how you could get to that mental model with x86, x86 is too weird. I don't really know which architecture is close to the simplicity of a PDP-11 today. Anyone? If I were teaching it, I'd just get a PDP-11 simulator and teach on that. Maybe. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Oct 2 01:38:04 2024 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Tue, 1 Oct 2024 11:38:04 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001152033.GH13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> <20241001152033.GH13777@mcvoy.com> Message-ID: Each generation bemoans the qualities of following generations. (Perhaps justifiably in this case, but we're acting out a stereotyped pattern.) Having a mental model of a computer is a good idea, but I'd rather not have to teach the details of PDP-11 condition codes (which changed in unexpected ways over time) Now caches loom large, and should such a course provide a mental model of smart phones? [I think it should, and the course should cover secure boot, but that leaves lots less time for assembly language.] On Tue, Oct 1, 2024 at 11:20 AM Larry McVoy wrote: > > On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > > wrote: > > > I think because the of the orders of magnitude increase in the demand > > > for programmers, we now have a very large number of programmers with > > > little or no math and science (and computer science doesn't count in the > > > point I'm trying to make here, if that's your only science, you're not > > > going to have the models in your head from other disciplines to give you > > > useful analogs) background, and that's a big change from 40 years ago. > > > So that has had an effect on who is programming, how they think about > > > it, and how languages have been marketed to that programming audience. IMHO. > > > > I've found a grounding in mathematics useful for programming, but > > beyond some knowledge of the physical constraints that the universe > > places on us and a very healthy appreciation for the scientific > > method, I'm having a hard time understanding how the hard sciences > > would help out too much. Electrical engineering seems like it would be > > more useful, than, say, chemistry or geology. > > > > I talk to a lot of academics, and I think they see the situation > > differently than is presented here. In a nutshell, the way a lot of > > them look at it, the amount of computer science in the world increases > > constantly while the amount of time they have to teach that to > > undergraduates remains fixed. As a result, they have to pick and > > choose what they teach very, very carefully, balancing a number of > > criteria as they do so. What this translates to in the real world > > isn't that the bar is lowered, but that the bar is different. > > I really wish that they made students take something like the PDP-11 > assembly class - it was really systems architecture, you learned the > basic idea of a computer: a CPU, a bus to talk to memory, a bus to > talk to I/O, how a stack works, ideally how a context switch works > though that kinda blows minds (I personally don't think you are a > kernel programmer if you haven't implemented swtch() or at least > walked the code and understood all of it). > > I did all that and developed a mental model of all computers that > has helped me over the last 4 decades. Yes, my model is overly > simplistic but it still works, even on the x86 craziness. I don't > know how you could get to that mental model with x86, x86 is too > weird. I don't really know which architecture is close to the > simplicity of a PDP-11 today. Anyone? > > If I were teaching it, I'd just get a PDP-11 simulator and teach > on that. Maybe. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Oct 2 01:44:12 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Tue, 1 Oct 2024 08:44:12 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> > Thus Go and Rust are good things, taking the sharp tools out of the > hands of the people who aren't qualified to use them. Same thing Python. Sounds like boomer mentality... Kids these days... :-) Also sounds like the kind of arguments assembly language programmers presented when *we* were the "kids" trying out "structured programming"! From rminnich at gmail.com Wed Oct 2 01:50:58 2024 From: rminnich at gmail.com (ron minnich) Date: Tue, 1 Oct 2024 08:50:58 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> <20241001152033.GH13777@mcvoy.com> Message-ID: by the way, if you are hankering to do bare metal programming again, and you're done with C, tinygo is great, and it works on 200 or so boards, from the bbc micro on up. tinygo gives you all the nice bits from go, and uses llvm as the backend, so programs can be very small. Tamago is also bare metal go, using the standard Go compiler, and has even flown in space. I had thought Rust and C would always be the only path to very low level programming in tiny environments, but it turned out I was too pessimistic. https://docs.google.com/presentation/d/1nqZicux6SloS8AynBu0B7cJYxw5pKu4IfCzq_vqWccw/edit?usp=sharing It's been years now since I used C on bare metal; it's Rust or Go for me. These languages give me all I ever needed for "first instruction after reset" programming. On Tue, Oct 1, 2024 at 8:38 AM Peter Weinberger (温博格) via TUHS < tuhs at tuhs.org> wrote: > Each generation bemoans the qualities of following generations. > (Perhaps justifiably in this case, but we're acting out a stereotyped > pattern.) > > Having a mental model of a computer is a good idea, but I'd rather not > have to teach the details of PDP-11 condition codes (which changed in > unexpected ways over time) Now caches loom large, and should such a > course provide a mental model of smart phones? [I think it should, and > the course should cover secure boot, but that leaves lots less time > for assembly language.] > > On Tue, Oct 1, 2024 at 11:20 AM Larry McVoy wrote: > > > > On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > > > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > > > wrote: > > > > I think because the of the orders of magnitude increase in the demand > > > > for programmers, we now have a very large number of programmers with > > > > little or no math and science (and computer science doesn't count in > the > > > > point I'm trying to make here, if that's your only science, you're > not > > > > going to have the models in your head from other disciplines to give > you > > > > useful analogs) background, and that's a big change from 40 years > ago. > > > > So that has had an effect on who is programming, how they think about > > > > it, and how languages have been marketed to that programming > audience. IMHO. > > > > > > I've found a grounding in mathematics useful for programming, but > > > beyond some knowledge of the physical constraints that the universe > > > places on us and a very healthy appreciation for the scientific > > > method, I'm having a hard time understanding how the hard sciences > > > would help out too much. Electrical engineering seems like it would be > > > more useful, than, say, chemistry or geology. > > > > > > I talk to a lot of academics, and I think they see the situation > > > differently than is presented here. In a nutshell, the way a lot of > > > them look at it, the amount of computer science in the world increases > > > constantly while the amount of time they have to teach that to > > > undergraduates remains fixed. As a result, they have to pick and > > > choose what they teach very, very carefully, balancing a number of > > > criteria as they do so. What this translates to in the real world > > > isn't that the bar is lowered, but that the bar is different. > > > > I really wish that they made students take something like the PDP-11 > > assembly class - it was really systems architecture, you learned the > > basic idea of a computer: a CPU, a bus to talk to memory, a bus to > > talk to I/O, how a stack works, ideally how a context switch works > > though that kinda blows minds (I personally don't think you are a > > kernel programmer if you haven't implemented swtch() or at least > > walked the code and understood all of it). > > > > I did all that and developed a mental model of all computers that > > has helped me over the last 4 decades. Yes, my model is overly > > simplistic but it still works, even on the x86 craziness. I don't > > know how you could get to that mental model with x86, x86 is too > > weird. I don't really know which architecture is close to the > > simplicity of a PDP-11 today. Anyone? > > > > If I were teaching it, I'd just get a PDP-11 simulator and teach > > on that. Maybe. > > -- > > --- > > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Oct 2 02:40:32 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Oct 2024 12:40:32 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: On Tue, Oct 1, 2024 at 9:13 AM wrote: > This goes back to the evolution thing. At the time, C was a huge > step up from FORTRAN and assembly. > Certainly it's a step up (and a BIG step up) from assembly. But I'd say C is a step sidewise from Fortran. An awful lot of HPTC programming involves throwing multidimensional arrays around and C is not suitable for that. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Oct 2 02:49:10 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Oct 2024 12:49:10 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011347.491DlAsJ423777@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> Message-ID: On Tue, Oct 1, 2024 at 10:07 AM wrote: [regarding writing an Ada compiler as a class project] > Did you do generics? That and the run time, which had some real-time > bits to it (*IIRC*, it's been a long time), as well as the cross > object code type checking, would have been real bears. > > Like many things, the first 90% is easy, the second 90% is hard. :-) > > I was in DEC's compiler group when they were implementing Ada for VAX/VMS. It gets very tricky when routine libraries are involved. Just figuring out the compilation order can be a real bear (part of this is the cross object code type checking you mention). >From my viewpoint Ada suffered two problems. First, it was such a large language and very tricky to implement--even more so than PL/I. Second, it had US Government cooties. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Oct 2 05:04:36 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 13:04:36 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: <202410011904.491J4aOY448275@freefriends.org> Dan Cross wrote: > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. You also have a lot of self-taught programmers, and graduates of bootcamp programs, getting into programming. From arnold at skeeve.com Wed Oct 2 05:07:04 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 13:07:04 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> Message-ID: <202410011907.491J74wT448406@freefriends.org> Bakul Shah via TUHS wrote: > > > Thus Go and Rust are good things, taking the sharp tools out of the > > hands of the people who aren't qualified to use them. Same thing Python. > > Sounds like boomer mentality... Kids these days... :-) Also sounds like > the kind of arguments assembly language programmers presented when *we* > were the "kids" trying out "structured programming"! It's not that they're intrinsically unqualified. They were never taught, so they don't know what they're doing. I'm unqualified to fly a plane because I never learned or practiced, not because I'm not intelligent enough. Same thing for many of today's programmers and C / C++. From tuhs at tuhs.org Wed Oct 2 05:46:50 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 1 Oct 2024 15:46:50 -0400 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: <36800a31-cea8-4b74-a34b-2069d031945e@case.edu> On 9/28/24 7:38 PM, Warren Toomey via TUHS wrote: > ----- Forwarded message from Poul-Henning Kamp ----- > > I stumbled over this: > > https://www.telecomarchive.com/lettermemo.html > > is the TUHS crew aware of that resource ? This is an incredible resource as well: https://www.telecomarchive.com/bstj.html From 1922 to 1996. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From rik at rikfarrow.com Wed Oct 2 06:34:26 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Tue, 1 Oct 2024 13:34:26 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011907.491J74wT448406@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: And my comment about seeing code produced by programmers while doing sales support dates from 1990. This isn't something new, from my perspective. I was working in a small programming shop where there were a handful of excellent programmers, and then sent out to help customers get started using their libraries. That's when I experienced seeing things that still make me cringe. Rik On Tue, Oct 1, 2024 at 12:07 PM wrote: > Bakul Shah via TUHS wrote: > > > > > > Thus Go and Rust are good things, taking the sharp tools out of the > > > hands of the people who aren't qualified to use them. Same thing > Python. > > > > Sounds like boomer mentality... Kids these days... :-) Also sounds like > > the kind of arguments assembly language programmers presented when *we* > > were the "kids" trying out "structured programming"! > > It's not that they're intrinsically unqualified. They were never > taught, so they don't know what they're doing. I'm unqualified to > fly a plane because I never learned or practiced, not because I'm not > intelligent enough. Same thing for many of today's programmers > and C / C++. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Oct 2 10:55:58 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Oct 2024 02:55:58 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: <20241002005558.TiqDHtEk@steffen%sdaoden.eu> Rik Farrow wrote in : |On Tue, Oct 1, 2024 at 12:07 PM wrote: |> Bakul Shah via TUHS wrote: ... |>> Sounds like boomer mentality... Kids these days... :-) Also sounds like |>> the kind of arguments assembly language programmers presented when *we* |>> were the "kids" trying out "structured programming"! |> |> It's not that they're intrinsically unqualified. They were never |> taught, so they don't know what they're doing. I'm unqualified to |> fly a plane because I never learned or practiced, not because I'm not |> intelligent enough. Same thing for many of today's programmers |> and C / C++. |And my comment about seeing code produced by programmers while doing sales |support dates from 1990. This isn't something new, from my perspective. I |was working in a small programming shop where there were a handful of |excellent programmers, and then sent out to help customers get started |using their libraries. That's when I experienced seeing things that still |make me cringe. Btw the "official Linux firmware" https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary introduced a dependency for the "rdfind" utility i think ~two years ago (it was later made optional) for this code: $verbose "Finding duplicate files" rdfind -makesymlinks true -makeresultsfile false "$destdir" >/dev/null find "$destdir" -type l | while read -r l; do target="$(realpath "$l")" $verbose "Correcting path for $l" ln -fs "$(realpath --relative-to="$(dirname "$(realpath -s "$l")")" "$target")" "$l" done I proposed (because it really drove me mad, i have nothing to do with Linux kernel stuff etc shall you think that) ( cd "$destdir" && find . -type f | xargs cksum | sort | { ls= lf= while read s1 s2 f; do s="$s1 $s2" #$verbose $s $f if [ "$s" = "$ls" ] && cmp "$lf" "$f"; then $verbose 'duplicate '"${lf##*/}" "${f#./*}" rm -f "$f" #ln -s "${lf#./*}" "${f#./*}" ln -s "${lf##*/}" "${f#./*}" else ls=$s lf=$f fi done } ) (as a draft, with only light testing, but it is not far from doing it at maximum) which only uses POSIX default tools etc, but these guys from very big companies (RedHat; the guy who did *that* is from AMD) did not even respond, at least to that. (At times i tried to get rid of rsync dependency of kernel makefile officially, as that can also be done via plain shell tools, they at least answered "what is wrong with rsync".) Maybe because the patch also included - compress="zstd --compress --quiet --stdout" + compress="zstd -T0 --ultra -22 --compress --quiet --stdout" but that only brought the firmware into line with the normal Linux kernel make zstd usage. I will never know. I think what i am trying to say is that maybe "time is money" in addition to anything else. (I never heard about rdfind though. Btw its manual (it has one!) says SEE ALSO md5sum, sha1sum, find, symlinks were cksum is a standard tool. So it is. Everyone its own infrastructure, how large it is; you all only get the binary updates anyway, my Linux distribution compiles from source; and what the mesa library alone has grown in new dependencies that are mostly never needed let alone at runtime, like YAML, that has been done at release-tarball-creation time in the past. At least here.) --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 arnold at skeeve.com Wed Oct 2 15:49:33 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 23:49:33 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: <202410020549.4925nXHf489153@freefriends.org> Rik Farrow wrote: > And my comment about seeing code produced by programmers while doing sales > support dates from 1990. This isn't something new, Also true. In the late 80s I was a sysadmin at Emory U. We had a Vax connected to BITNET with funky hardware and UREP, the Unix RSCS Emulation Program, from the University of Pennsylvania. Every time I had to dive into that code, I felt like I needed a shower afterwards. :-) Arnold