the new math: old battle of the lovees was: PDP1 3596

snip

Not sure what you mean by "plug 'n' play", but what I had in mind was more making changes that involve opening the (hardware) box -- replacing-adding memory or disks, swapping motherboards, etc. "Plug 'n' play", or "taking apart gear"?

snip

Didn't what? Do both? I have an idea that we've discussed this

Yes. The discussion was about "compiler thinkers" versus "O-S thinkers". As far as I can tell from the parts I reviewed, you and the others who were trying to explain this distinction came up with two things:

(1) O-S thinkers have to be able to think about multiple things happening "at the same time" (in effect or in reality -- by "in effect" meaning "interleaved in arbitrary fashion"). Compiler thinkers don't. Their idea of a program involves a single sequential thread of control.

(2) O-S thinkers have to be able to deal with the realities of the physical hardware. Compiler thinkers don't. (I'm filtering this point through my understanding, which I think is imperfect.)

My claim was then, and is now, that the person who (co?)invented semaphores certainly knows something about (1).

(Aside: The "(co?)" is there because one of my colleagues says the idea was independently proposed by Kenneth Iverson. I haven't researched this myself, but it seems worth mentioning out of fairness.)

I wasn't sure about (2), but I recalled that I had heard something about him being involved with the design of an operating system very unfortunately (in these days of case-insensitive Web searches) called "THE". So I did a little poking around in UTexas's archives of his writings. Two that seem to be of interest:

"The Multiprogramming System for the EL X8 THE" (EWD 126)

"The structure of the 'THE'-multiprogramming system" (EWD 196)

These are both from the 1960s.

Here's a quotation from the second one:

"As captain of the crew I had had extensive experience (dating back to 1958) in making basic software dealing with real time interrupts and I knew by bitter experience that as a result of the irreproducibility of the interrupt moments, a program error could present itself misleadingly like an occasional machine malfunctioning."

I dunno -- that sounds like an O-S thinker to me. But maybe he wasn't very good at it. Maybe someone else can comment on whether any of this work was widely known in industry and how it was regarded.

Certainly the guy is famous in O-S-theory circles, for his work on semaphores and as the originator of the problem that came to be called "the dining philosophers". (Apparently it was CAR Hoare who actually gave it the name.) But maybe whatever you mean by "O-S thinker" isn't the same as being famous in O-S-theory circlees.

snip

I don't suppose anyone can point me to some useful search terms for retrieving that post? it doesn't seem to be in this thread -- at least looking in Google's archives for posts containing "2D" and "3D" and in this thread isn't obviously finding it.

Could be. I usually figured that their advantage had more to do with their being just plain brighter than the average person, plus knowing more math. To go off on even more of a tangent, one "new to me" thinking pattern I sometimes pick up on from physics people is an emphasis on exploiting symmetry.

snip

Congratulations. I aspire to curmudgeonhood, and my chronological age is approaching something that may make it achievable soon.

I was thinking mostly theoretical -- proofs, logic, that sort of thing. What I tell students, though, is that we make them study that stuff in part to develop what I've heard math people call "mathematical maturity", which AFAICT has something to do with the ability to deal with abstractions. I think this is critical to being good at programming beyond a very low level. General problem-solving skills are also important. Whatever kind of math fosters all of that ....

I guess I'm not sure what you mean by "applicable" (a.k.a. "applied", I'm thinking) as opposed to "theoretical".

Specific types of programming require additional math background -- linear algebra for graphics, for example -- but I think we're talking about general stuff here.

Yeah ....

(Does this have something to do with "buttembly code and machine code and circuit design at the level of gates", though? or are we agreed that that's important, and moving on to the next thing?)

On the long-term to-do queue.

I did take some physical-science courses in high school and as an undergraduate (a little biology and chemistry in both, several semesters of undergrad physics). I did well in the clbuttroom part. Labs were another story. Experiments seemed to go wrong -- I would think I understood the overall idea of what they were supposed to do-test, but the results were rarely what they were supposed to be. At the time I blamed some lack of physical coordination on my part. Now I wonder .... (I can almost hear you saying "NOW you're catching on!") Possibly what I wasn't being taught, and couldn't or didn't figure out for myself, was how to figure out where the "experimental error" that supposedly accounted for the bad results was coming from.

Yeah. (I do know that!)

-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.