Hi Arnold, I agree the original Software Tools is a must read, but having done so, why would I suffer working through the hurdles put in place by Pascal compared to Ratfor? I never bothered so your recommendation makes me wonder what I missed. I did read Kernighan's ‘not my favourite’ and took from that I wouldn't enjoy the Pascal book given I'd read the original. -- Cheers, Ralph.

Whilst I haven’t read the original, believe Kernighan and Plauger state in preface that Pascal enabled recursive algorithms to be written in their natural manner. Don’t believe Fortran has record or set datatypes and imagine those enabled code improvements between the Ratfor and the Pascal Not quite sure reading both editions of the book but would definitely recommend examining the code which Arnold states is available on the TUHS archive. Silas

I've been having a good time watching YouTube videos that have Brian either interviewing or being interviewed by assorted folks. My favorite one, so far, is this "fireside chat": VCF East 2019 -- Brian Kernighan interviews Ken Thompson https://www.youtube.com/watch?v=EY6q5dv_B-o In any case, the K&P book I'd _really_ like to see brought up to date is "The Elements of Programming Style". It could have been subtitled "How to write small, simple programs that work." It's still a very fine book, but I'm not sure that the current crop of beginning programmers would be patient enough to deal with the sadly dated example code. If you're still here, I'll give you a vignette from many years ago. My spouse and I were both early fans of AWK, having been introduced to it around 1983 by our friend Jim Joyce. Indeed, she used AWK to process line printer plot files (dendograms, for the curious) into a format that my homegrown SunCore interpreter could render for screen display and printing on our dot matrix printer. Some of them ended up in her Master's Thesis... Anyway, we traveled with Jim to Copenhagen for a EurOpen conference. At the closing banquet, I got to an empty table before anyone else and tossed down a "no smoking" placard. Vicki and I then sat down. Shortly thereafter, Brian walked past and saw the placard. Brian: "Is this a non-smoking table?" Us: "It is now. (:-)" So, he sat down and we had a chance to dine with a personal hero (and all-around nice guy). The next day, we got on a train to Stockholm, on our way to Helsinki (to teach a Unix Intro course with Jim). Our four-person compartment turned out to include Brian, Vicki, me, and a long-suffering European businessman. IIRC, we pestered Brian for hours about AWK, Bell Labs, and so forth. He was unfailingly gracious and a wonderful person to spend the trip with. -r

Not really. It's a fine book, but a lot bigger, so it contains a lot more (and more diverse) material. I like the facts that "The Elements of Programming Style" is pretty tightly focused and that it can be read quickly (and absorbed over time :-). That is, the title's homage to "The Elements of Style" is not an accident... -r

Adam Thornton writes: Well, I'm not an august personage and am not a Rust programmer. I did spend a while trying to learn rust a while ago and wasn't impressed. Now, I'm heavily biased in that I think that it doesn't add value to keep inventing new languages to do the same old things, and I didn't see anything in Rust that I couldn't do in a myriad of other languages. But, my real issue came from some of the tutorials that I perused. Rust is being sold as "safer". As near as I can tell from the tutorials, the model is that nothing works unless you enable it. Want to be able to write a variable? Turn that on. So it seemed like the general style was to write code and then turn various things on until it ran. To me, this implies a mindset that programming errors are more important than thinking errors, and that one should hack on things until they work instead of thinking about what one is doing. I know that that's the modern definition of programming, but will never be for me. Jon

[TUHS to Bcc, +COFF &lt;coff(a)minnie.tuhs.org&gt; ] This isn't exactly COFF material, but I don't know what list is more appropriate. On Thu, Feb 3, 2022 at 9:41 PM Jon Steinhart &lt;jon(a)fourwinds.com&gt; wrote: I'm a Rust programmer, mostly using it for bare-metal kernel programming (though in my current gig, I find myself mostly in Rust userspace...ironically, it's back to C for the kernel). That said, I'm not a fan-boy for the language: it's not perfect. I've written basically four kernels in Rust now, to varying degrees of complexity from, "turn the computer on, spit hello-world out of the UART, and halt" to most of a v6 clone (which I really need to get around to finishing) to two rather more complex ones. I've done one ersatz kernel in C, and worked on a bunch more in C over the years. Between the two languages, I'd pick Rust over C for similar projects. Why? Because it really doesn't just do the same old things: it adds new stuff. Honest! Further, the sad reality (and the tie-in with TUHS/COFF) is that modern C has strayed far from its roots as a vehicle for systems programming, in particular, for implementing operating system kernels ( https://arxiv.org/pdf/2201.07845.pdf) C _implementations_ target the abstract machine defined in the C standard, not hardware, and they use "undefined behavior" as an excuse to make aggressive optimizations that change the semantics of one's program in such a way that some of the tricks you really do have to do when implementing an OS are just not easily done. For example, consider this code: uint16_t mul(uint16_t a, uint16_t b) { return a * b; } Does that code ever exhibit undefined behavior? The answer is that "it depends, but on most platforms, yes." Why? Because most often uint16_t is a typedef for `unsigned short int`, and because `short int` is of lesser "rank" than `int` and usually not as wide, the "usual arithmetic conversions" will apply before the multiplication. This means that the unsigned shorts will be converted to (signed) int. But on many platforms `int` will be a 32-bit integer (even 64-bit platforms!). However, the range of an unsigned 16-bit integer is such that the product of two uint16_t's can include values whose product is larger than whatever is representable in a signed 32-bit int, leading to overflow, and signed integer overflow is undefined overflow is undefined behavior. But does that _matter_ in practice? Potentially: since signed int overflow is UB, the compiler can decide it would never happen. And so if the compiler decides, for whatever reason, that (say) a saturating multiplication is the best way to implement that multiplication, then that simple single-expression function will yield results that (I'm pretty sure...) the programmer did not anticipate for some subset of inputs. How do you fix this? uint16_t mul(uint16_t a, uint16_t b) { unsigned int aa = a, bb = b; return aa * bb; } That may sound very hypothetical, but similar things have shown up in the wild: https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf In practice, this one is unlikely. But it's not impossible: the compiler would be right, the programmer would be wrong. One thing I've realized about C is that successive generations of compilers have tightened the noose on UB so that code that has worked for *years* all of a sudden breaks one day. There be dragons in our code. After being bit one too many times by such issues in C I decided to investigate alternatives. The choices at the time were either Rust or Go: for the latter, one gets a nice, relatively simple language, but a big complex runtime. For the former, you get a big, ugly language, but a minimal runtime akin to C: to get it going, you really don't have to do much more than set up a stack and join to a function. While people have built systems running Go at the kernel level ( https://pdos.csail.mit.edu/papers/biscuit.pdf) that seemed like a pretty heavy lift. On the other hand, if Rust could deliver on a quarter of the promises it made, I'd be ahead of the game. That was sometime in the latter half of 2018 and since then I've generally been pleasantly surprised at how much it really does deliver. For the above example, integer overflow is defined to trap. If you want wrapping (or saturating!) semantics, you request those explicitly: fn mul(a: u16, b: u16) -> u16 { a.wrapping_mul(b) } This is perfectly well-defined, and guaranteed to work pretty much forever. But, my real issue came from some of the tutorials that I perused. Rust is That's one way to look at it, but I don't think that's the intent: the model is rather, "immutable by default." Rust forces you to think about mutability, ownership, and the semantics of taking references, because the compiler enforces invariants on all of those things in a way that pretty much no other language does. It is opinionated, and not shy about sharing those opinions. To me, this implies a mindset that programming errors are more important It's funny, I've had the exact opposite experience. I have found that it actually forces you to invest a _lot_ more in-up front thought about what you're doing. Writing code first, and then sprinkling in `mut` and `unsafe` until it compiles is a symptom of writing what we called "crust" on my last project at Google: that is, "C in Rust syntax." When I convinced our team to switch from C(++) to Rust, but none of us were really particularly adept at the language, and all hit similar walls of frustration; at one point, an engineer quipped, "this language has a near-vertical learning curve." And it's true that we took a multi-week productivity hit, but once we reached a certain level of familiarity, something equally curious happened: our debugging load went way, _way_ down and we started moving much faster. It turned out it was harder to get a Rust program to build at first, particularly with the bad habits we'd built up over decades of whatever languages we came from, but once it did those programs very often ran correctly the first time. You had to think _really hard_ about what data structures to use, their ownership semantics, their visibility, locking, etc. A lot of us had to absorb an emotional gut punch when the compiler showed us things that we _knew_ were correct were, in fact, not correct. But once code compiled, it tended not to have the kinds of errors that were insta-panics or triple faults (or worse, silent corruption you only noticed a million instructions later): no dangling pointers, no use-after-free bugs, no data races, no integer overflow, no out-of-bounds array references, etc. Simply put, the language _forced_ a level of discipline on us that even veteran C programmers didn't have. It also let us program at a moderately higher level of abstraction; off-by-one errors were gone because we had things like iterators. ADTs and a "Maybe" monad (the `Result<T,E>` type) greatly improved our error handling. `match` statements have to be exhaustive so you can't add a variant to an enum and forget to update code to account in just that one place (the compiler squawks at you). It's a small point, but the `?` operator removed a lot of tedious boilerplate from our code, making things clearer without sacrificing robust failure handling. Tuples for multiple return values instead of using pointers for output arguments (that have to be manually checked for validity!) are really useful. Pattern matching and destructuring in a fast systems language? Good to go. In contrast, I ran into a "bug" of sorts with KVM due to code I wrote that manifested itself as an "x86 emulation error" when it was anything but: I was turning on paging very early in boot, and I had manually set up an identity mapping for the low 4GiB of address space for the jump from 32-bit to 64-bit mode. I used gigabyte pages since it was easy, and I figured it would be supported, but I foolishly didn't check the CPU features when running this under virtualization for testing and got that weird KVM error. What was going on? It turned out KVM in this case didn't support gig pages, but the hardware did; the software worked just fine until the first time the kernel went to do IO. Then, when the hypervisor went to fetch the instruction bytes to emulate the IO instruction, it saw the gig-sized pages and errored. Since the incompatibility was manifest deep in the bowels of the instruction emulation code, that was the error that returned, even though it had nothing to do with instruction emulation. It would have been nice to plumb through some kind of meaningful error message, but in C that's annoying at best. In Rust, it's trivial. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ 70% of CVEs out of Microsoft over the last 15 years have been memory safety issues, and while we may poo-poo MSFT, they've got some really great engineers and let's be honest: Unix and Linux aren't that much better in this department. Our best and brightest C programmers continue to turn out highly buggy programs despite 50 years of experience. But it's not perfect. The allocator interface was a pain (it's defined to panic on allocation failure; I'm cool with a NULL return), though work is ongoing in this area. There's no ergonomic way to initialize an object 'in-place' (https://mcyoung.xyz/2021/04/26/move-ctors/) and there's no great way to say, essentially, "this points at RAM; even though I haven't initialized it, just trust me don't poison it" ( https://users.rust-lang.org/t/is-it-possible-to-read-uninitialized-memory-w… -- we really need a `freeze` operation). However, right now? I think it sits at a local maxima for systems languages targeting bare-metal. - Dan C.

Well, this topic certainly took an odd turn. Owell... The incursions of Rust (and not Go) into Linux, Mozilla, and such may indicate a trend. I quite enjoyed this and found it to be informative, as well. My personal reaction to Go (mostly derived from skimming Brian's book) is that (a) it's well tuned to Google's needs and (b) not well tuned to mine. Specifically... Google needs a language which runs efficiently and links in a reasonable amount of time, even when HUGE sets of libraries are involved. It also needs a convenient way to do massive concurrency. Finally, it needs zillions of programmers to be fungible, dropping into code bases that they've never seen before, without tripping over landmines. My impression is that Go meets these criteria admirably. But, horses for courses... I program mostly on my own, so most of these criteria are irrelevant to my needs. I use Ruby for short scripts and Elixir for larger programs. Neither one is blazingly fast, but they both feel comfortable to write in. I like Matz's taste in design and think that José Valim has pulled together a very appealing mix of concepts and syntax from Clojure, Erlang, F#, Lisp, Ruby, etc. One problem I have with Go is that it doesn't match the way I code. Kind of like (I imagine) an oil painter might work, I start with broad swatches and fill in the details over time. So, any new program is likely to have stubs lying about, waiting to be implemented. Also, I might well calculate a variable only to support a trace statement which is currently commented out. Go is very intolerant of this sort of thing: an unused variable, IIRC, is a fatal error. Google isn't paying me to put up with this sort of thing, so I don't. Another problem I have with Go is the concurrency model. First, it uses threads, which I've never felt competent to use safely. Shared mutable state is one of those things that seem to me like an accident waiting to happen. Also, though I have no real experience with CSP, it seems like the Actor model may be better suited to exploratory programming. Getting back to Rust, my impression is that its design assumes that having the computer put up guard rails will (mostly) keep programmers from making catastrophic mistakes. In contrast, the Erlang (and thus Elixir) approach assumes that things WILL crash and that the important thing is to make sure that the system as a whole keeps running smoothly. So, for example, it provides supervision trees which can handle any crash of an Actor, etc. Also, I learned pretty early in my career (ca. 1972) that some of the biggest botches come from folks not understanding the needs of the users. I wrote a 10 KLOC PDP-11 assembly language program, based on a 1" thick specification document. It never got used, because it didn't solve the users' problem. Fine code, broken spec... Having said all this, I'm actually quite happy about the fact that Rust is creeping into Linux. The coding style is likely to be a bit more careful and it may well help to provide some protection against security issues. (ducks) -r

I really wish there were a manpage that says "foo is the one true language" just like ed(1). Then this thread would stop.

I've written COBOL for money. I'm not proud of it but I won't deny it. I've written Python, C, Perl, and Go (and doubtless some others) for both love and money at different times. I've written LISP (well, Scheme) for a grade and for love. I've written Inform 6 and 7, and 6502 assembler, and a bunch of other things, just for love. I am sure I couldn't stop writing programs if I had to. As Emmylou Harris sang: Well, I did it for kicks and I did it for hate I did it for lust and I did it for faith I did it for need and I did it for love Addiction stayed on tight like a glove On Fri, Feb 4, 2022 at 4:22 PM Seth J. Morabito &lt;web(a)loomcom.com&gt; wrote:

On Fri, 4 Feb 2022, Andy Kosela wrote: I tend to prefer to keep everything to 77-79 when I'm actually formatting code for releases as opposed to "just don't care". I tend to feel that C strikes a perfect balance between minimalist and powerful. Same. I mean, I've started to pick up 8086 assembler, but I can write C, I can code for my Apple //e, or I can code for my AMD64 boxen, or for my old PS/2, or theoretically for my ancient Macintoshes...or a number of other systems. It's not quite "write once run everywhere", but it's pretty close. -uso.

On Fri, 4 Feb 2022, markus schnalke wrote: Probably true. Could be that I cut my teeth on an 8-bit computer and did a lot of work on 16-bit systems, so I'm used to working with limited RAM and CPU. There is certainly truth to that. And even human languages tend to adapt in culture-specific ways ("two countries divided by a common language" being a common joke about the US versus the UK, for example). -uso.

I have a subsystem that populates a database from disparate data streams. It's been known to run for years without restarting, thanks to valgrind. From: "Hellwig Geisse" &lt;hellwig.geisse(a)mni.thm.de&gt; To: tuhs(a)minnie.tuhs.org Sent: Friday, February 4, 2022 3:28:10 PM Subject: Re: [TUHS] more about Brian... Hi Thomas, On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: did you ever write a program which does heavy malloc()/free() on complicated (i.e., shared) data structures *and* runs for days, perhaps weeks? IMO it's very difficult to do this without a GC, and you have to exercise quite an amount of discipline to do it right. Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) used a GC, and it did that quite efficiently. Hellwig

Hellwig Geisse wrote in &lt;1644006490.2458.78.camel(a)mni.thm.de&gt;: |Hi Thomas, | |On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: |> I tell you one thing: I never ever experienced any problems with |> traditional malloc()/free(). | |did you ever write a program which does heavy malloc()/free() |on complicated (i.e., shared) data structures *and* runs for |days, perhaps weeks? IMO it's very difficult to do this without Yes. |a GC, and you have to exercise quite an amount of discipline |to do it right. And i fail to see the relationship really. Especially given that all kernels and all daemons i know (he!) are all written in C. Object based programming is surely easier to manage, as containers manage containers manage containers manage whatever allocations. So you have a very natural chain of life, so to say. |> A kernel using GC is a kernel written by inexperienced kids. | |Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) |used a GC, and it did that quite efficiently. Well i have no idea of that also really, so i am not saying anything. I never liked GC; i looked at the source of "that" C GC however (yes, i have forgotten the name). It maybe different to languages like Nim or Lua or, sigh, JAVA, Go and such environments etc., where possibly every object is reference counted. And that where recursive mutexes are declared evil for performance reasons, and kernel code is full of ASSERT(is_locked()) stuff. But this is speculative execution and thus far out of my league. --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)

On 2/5/22 6:56 PM, Larry McVoy wrote: I completely agree. This is ridiculous. Do modern programmer's seriously think that the old code wasn't complex or robust? Sheesh, there's code out there that has run through more millions of transactions an hour for more years than most of these folks have been alive. There's also code that's been running without any updates, for decades. Most code written by the newbreed won't run for a month without surfacing dozens of bugs. Margaret Hamilton would prolly have some choice words for these folks.

 Thank you, Rob. I composed a similar reply, and debated whether to send it. You hit all the right points more succinctly and directly. --Dan H. On 2/5/22 23:52, Rob Pike wrote:

"it's a lot easier, safer, and robust to let the machine do the memory accounting" I disagree. "The machine" is, as you know, is in reality app code built on top of frameworks built on top of libraries built on top of more libraries built on top of malloc/free calls. While the automated testing tools are a lot better than they were when I started coding C back in 1985, we're still talking about a *lot* of complexity and a lot of layers of code, and programmers today know far less about things like boundary conditions, off-by-one bugs, and the like that bit us in the ass - hard - and so we learned to watch for those sorts of things. On 2/5/22, Rob Pike &lt;robpike(a)gmail.com&gt; wrote:

I like the point that malloc()/free() could be seen as a "failure of automation". As to the GC and (Go | Rust) vs (C | Java | C++) earlier in this increasingly-off-topic thread: perhaps it's an issue of whether that automation is applied at runtime or compile-time... (the latter still requiring guidance from the programmer, trading some programmer-brain-time against cpu-execution-time & memory space?) On Sun, 6 Feb 2022, 14:28 Rob Pike, &lt;robpike(a)gmail.com&gt; wrote:

Bakul Shah wrote in &lt;10B8CDC8-12FF-4B93-AD34-3393BA5C13D5(a)iitbombay.org&gt;: |Just ignore the swagger. | |I would go further than Rob in that even for sequential |programs there is no virtue in sticking to malloc/free if you |don't have to. The whole point of automation (for me) is to Well maybe. When i do perl or awk i do not even think about that memory as such exists, mostly. In so far. |delegate all the boring and repetitive work to computers so |that I can focus on more interesting things! And solving |malloc/free related bugs is boring and repetitive. For But, you know, this is a philosophy i do not like. Just like i never understood why Stroustrup gave C++ exceptions the full power of flexibility instead of allowing only a single base class but giving the entire C++ environment a toggle to produce __FILE__/__LINE__ diagnosis out of the box. Or instead of even introducing symbols which go the non-preprocessor if(XY) way and allowing access to these from within code if XY is true. So you have to invent preprocessor mess in order to be able to pass debug info down the call chain, or use non-portable ELF or so related info (which i never did). But if you do have the information at hand, your program could say #?1|kent:steffen$ s-nail -Rf /dev/empty s-nail: /dev/empty: No such entry, file or directory ... #?0!0/NONE#ERROR|:? quit ... s-nail[info]: Count cur/peek/all: 4/ 1658/ 12524 ... s-nail[info]: 0x55ef9a581b50 (72 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064 There are messages in the error ring, manageable via `errors' command??? s-nail[info]: 0x55ef9a581ae0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035 ????????????????E???????P?X??U??E??????? s-nail[info]: 0x55ef9a581420 (48 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064 /dev/empty: No such entry, file or directory???? s-nail[info]: 0x55ef9a5813b0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035 ??X??U??????????,??????? ?X??U??,???^??? even upon receive of a signal. And this is just a silly wrapper, not even a complete thing. It is just like always, "there is no wrong weather, just the wrong clothes". |embedded code in limited space you want to use memory |carefully but for most of userland code we don't have to |worry about saving every byte. Most userland code is not real |time code (and doesn't run on realtime OSes). That doesn't |mean using memory like water -- there is a middle ground. |Don't blame the GC for incompetently programmed websites or |for layers of code using third party libraries using other |third party libraries. All the new languages [offer] [myriads] of [symbol] [annotations] in order to improve things, which also aids in giving more info to the tools. And, what is maybe more important, all programs written in these languages are written from scratch. And even if people tend to produce bugs here and there, and tend to forget the background of a problem now and then, or did not know about it when they wrote the code, ... the experience with programming has improved a lot compared to times that members of these list went through! That is of course only my personal opinion. I like C a lot (like C++ without everything but classes). --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)

Since you made this personal and called me out specifically, I will respond: "In what way is automatic memory management harder, more unsafe, and less robust than hand-written memory management using malloc and free?" Because there's no difference in the two. Someone had to write the "automatic memory management", right? "You seem to think that garbage collection only exists in languages that have a smell you don't like." I said nothing of the kind. You've got me mixed up with someone else. Just because I respond to a thread doesn't mean I agree with everything said in the thread. "Using malloc and free might be a badge of honor to some, but it's also a failure of automation." Again, the automation code has to written by *someone*. It doesn't just appear by itself. "This discussion should probably go to COFF, or perhaps I should just leave the list. I am starting to feel uncomfortable here. Too much swagger." I read through the thread. Just because people don't agree with each other doesn't equate to "swagger". I've seen little evidence of anything other than reasoned analysis and rational, respectful discussion. Was there any sort of personal attacks that I missed? The fact of the matter is, code written with malloc/free, if written carefully, will run for *years*. There are Linux boxes that have been running for literally years without being rebooted, and mainframes and miniframes that get booted only when a piece of hardware fails.

Let's keep it civil and non-personal, I don't think Rob was pointing at anyone, I think he was pointing at some not so forward thinking. I have to side with Rob on this one, even though I'm squarely in the I like C best camp. While I _can_ do all the malloc/free stuff myself (and have decades of working code to prove it), it's become harder and harder to find other people who can. Younger programmers just sort of stare at you with a "I have to do what?" look. They think you are a dinosaur for working like that when other reasonable languages do that work for you. When I did little-lang.org, granted, not widely used but we used it a lot, it did all the memory management behind the scenes, used reference counting so you never had the big GC sweep that some languages used, worked great. And super pleasant to not have to do all that memory management. Having the languages do more for you, and put up guard rails so people can't make stupid mistakes, seems to be the way of the future. It's not my future, I love C, it does what I want and I can live with what it needs me to do to have working code. But I'm a dinosaur and I know it. I'm not trying to push C where people don't want it. On Sun, Feb 06, 2022 at 06:14:36AM -0700, Ed Carp wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

Larry McVoy writes: I look at this from a different perspective. The world needs a lot of programmers these days. It takes a lot of work to have internet-connected refrigerators push advertising, to make washers and dryers sing about their work, to have Bixby piss off Samsung phone users, to ensure that IoT devices are insecure, and of course to leak personally identifying information on government web sites. This is critical work and there just aren't enough "good" programmers to go around. I view people that programming for Android, making web pages unusable, and so on, as if they're using domain-specific languages. The difference is that while many of us grew up loving domain-specific "little languages" these languages are huge. While I'm not an expert here, I'm sure that being an expert in the Android, IOS, Java, or WWW ecosystems involves more "learning" than many of us had to do when we learned our craft. A big problem with our profession is that we have no agreed on terminology to distinguish among practitioners. A story told to me by a co-worker in the '80s illustrates this well. Ken had gone home for Christmas with his family. One of his uncles took him aside and asked something like "Hey, you're a computer guy. Can you help me with this .COM and .BAT stuff?" Ken replied "Don't have a clue what you're talking about." When Ken related this story to me, he said "The funny thing about it was that we both walked away thinking that the other person didn't know anything about computers." I think some of what we're debating here is whether or not "programmers" need to understand fundamentals. Many of us think that they do, but we're not the ones working on a subscription model for starting your car. I replaced my deck last summer. Had to do a lot of contractor interviewing. I didn't choose one who said "I can do it" and showed me photos of work he had done. I chose one who said "I can do it" and looked around and said "You know, won't be able to tell until I get the old one removed but I think that there some things that need fixing underneath." Another example, because I'm also a hardware engineer. Many digital circuit designers think that digital is an isolated domain. There was a time a few decades ago when an analog engineer couldn't get a job. But then there was an awakening when folks realized that everything was analog at its core and all of a sudden "full stack hardware engineers" were writing their own tickets. Sure, many digital designers said "Why do I need to know this stuff? Nobody uses Rubylith anymore and the DRC (design rule checker) software takes care of stuff for me. Analog designers bail those people out when things don't work. To me, a big problem with what I'll call domain-specific programmers is that they get involved in standards and specifications and aren't trained in how to abstract. So standards are produced that result in enlarged, more complex domains. One of the best examples is CSS, a standard that is too complex to be documented. I have no clue as to how many CSS properties exist anymore. It's not cleanly designed, and of course with the addition of each new property the interaction matrix grows exponentially. And the increasing number of mode-switching properties is growing the number of interaction matrices. There are literally thousands of things a CSS "programmer" needs to know, yet people still ask question like "How do I vertically center something" because it's still hard to do. Even the worst programming language is orders of magnitude simpler than CSS. But hey, CSS isn't "programming" so of course it's better. Bottom line to me is that people with serious expertise are always going to be needed. Someone has to design the hardware, someone has to make the tools used to design the hardware, someone has to implement programming languages and operating systems and all that. But that's a different domain than what the majority of the world wants today. Jon

On Sun, Feb 6, 2022 at 12:27 PM Jon Steinhart &lt;jon(a)fourwinds.com&gt; wrote: I personally like having the choices. I don't want to be bothered with malloc/free when I'm hacking together an awk or python script. On the other hand, when it has to run fast or do lots of TPS inside a kernel, I really don't want somebody else deciding when a good time to take a 'hiccup' in performance is... It all depends on what I'm doing since using techniques from the latter to optimize the former is a waste of time. The whole reason I do a GC'd language is to write what I'm writing faster with less hassle... Some days I'm Dan Healy, some days I'm waving diagonal pliers around... :) Warner

Hi Jon, You've brought up an interesting point to start this subthread, but it still isn't TUHS-worthy IME. COFF would welcome it. :-) -- Cheers, Ralph.

And that reminds me of the old "Three Envelopes" joke: A new CEO takes his seat at the helm of a large corporation He finds three envelopes on his desk, numbered 1 to 3, and a note. "Dear successor, On this desk you find 3 envelopes that will help you in times of a crisis. Open them only in the order they are numbered, and only when you face a crisis that you cannot manage. Best of luck". He stores them in his safe and goes to work. But the economy isn't picking up, the corporation isn't doing too well and the board wants an explanation. He decides it's time for the first envelope. He rips it open and reads: "Blame your predecessor". And he does. He steps up at the press conference and blames everything on the shortcomings and nearsightedness of his predecessor and how he just needs a bit more time to turn things around. Everyone is pleased and he remains CEO. But after a while, the displeasure isn't waning and the corporation isn't doing any better. Another press conference is held and he rips open the next envelope: "Call for reorganizations". And he does. He presents a great reorganization project with no stone remaining unturned, this will surely improve productivity and move the corporation into the future. Everyone's so busy reorganizing that nobody can even notice how the corporation is running worse and worse, until there's really no way to cover it up anymore. He reaches for the third and last envelope, hoping for the great reveal that will save him once and for all. He rips it open and reads: "Prepare 3 envelopes and a note". On 2/6/22, Brad Spencer &lt;brad(a)anduin.eldar.org&gt; wrote:

silas poulson &lt;silas8642(a)hotmail.co.uk&gt; wrote: No, he has not. I suspect it would have looked like the ratfor code but with real data structures and recursion, and without the need to build the standard I/O library (getc, putc, etc.). Arnold

Hi Arnold, Well, that's true. I've read every other technical book of his apart from the ‘AMPL: A Modeling Language for Mathematical Programming’. https://amzn.to/3BdQ0dV It was the quality of his writing which meant I could learn C and Unix at home well enough to get a C programming job on Sun OS on leaving school, which is sixteen over here. Within a year or so, work sent me to Sydney as part of shipping the flight simulator to Qantas. Good books have immeasurable worth across all their readers. Thanks, it's ordered, arriving Valentine's Day, which will impress SWMBO. :-) -- Cheers, Ralph.

On 2/2/22 8:00 PM, Will Senn wrote: Graybeards chucking at the follies of youth.

On Wed, Feb 2, 2022 at 9:01 PM Will Senn &lt;will.senn(a)gmail.com&gt; wrote:

On Thu, Feb 3, 2022 at 11:07 PM Ori Idan &lt;ori(a)heliconbooks.com&gt; wrote: Ha! You fell into my trap! getc() returns an int! (I don't know if EOF is _always_ "all bits set", and even if it is, that's only -1 on a twos-complement machine, if we want to head off into some real pedantry...) The need to use feof() and ferror() at least appear in the BUGS section on my Mac. Linux is not so gracious. The real bug, if you ask me, which no one did, is that getc() and pals return an int rather than a char, which is surprising and certainly has tripped me up several times across the decades (and yes, I understand that since any character value is a legal character to have gotten, you need some other way of signalling an error).