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

snip

Very closely related indeed, and probably with similar, um, "installed bases".

I should probably also have mentioned that in most of my recent experience with other people's code, the other people have been undergraduates. That may also bias my opinions. Then again, some of those undergraduates have probably done as much programming as junior-level professionals. They start a lot earlier these days than we in my peer-group-as-defined-by-age did ....

snip

Sometimes when Barb tries to clarify the distinction, it seems to me that what she's saying is that it complicates things a lot when you have to worry about concurrency and asynchrony and like that, and that in some sense this makes o-s-level programming fundamentally different from writing programs that are strictly one-thing-at-a-time. I think she has a point there, though I've argued (and still think) that people writing mulbreasthreaded and message-pbutting applications face similar issues and have to develop similar thinking styles.

Come to think of it, my experience is that "try stuff until something seems to work" is, if anything, *less* likely to succeed if the application involves concurrency (mulbreasthreading or message pbutting), in part because of the inherent nondeterminism (I think that's the word I want -- the property that different ends of a program with the same inputs can produce different outputs). I would think this would carry over into o-s-level programming involving concurrency as well. Certainly it carries over into the clbuttical IPC (interprocess communication) problems -- mutual exclusion, dining philosophers, etc. -- which supposedly are trimmed-down versions of problems o-s writers might want to solve.

But there's also a lot of common ground, and you won't get any argument from me about the importance of a sound foundation.

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