Brooks and his MMM had greater influence on me as a software engineer than any other person/book in the field. The chapters on conceptual integrity put into crisp words how I felt about software design but did not have the vocabulary to express my feelings. His books also made me realize that the precision of expression in the spoken language can be as powerful as in programming languages.
Also the person that gave us 8bit bytes.
Wow, can you imagine dealing with 6 bit bytes? Every bit-related calculation would be a lot trickier, and we’d be doing everything in octal!
Why would they be trickier with six bits?
Because six is not a power of two, probably. I haven’t yet thought of a realistic calculation where that would be relevant, but I feel there must be one.
Reminds me of a conversation I had with my mentor 20 years ago or so. I asked him why he used octal so much, when hex was so much more efficent. His answer surprised me at the time. One of the first machines he worked with was from Honeywell and used 60-bit words and presumably 6-bit bytes, so octal was widely used there. Old habits die hard.
A few years later, I had a lot of fun playing around with PDP-10 emulators, where there were 36-bit words and 6-bit characters. As it happens, you can represent 6 characters in a PDP-10 word, and that would seem to explain things like 6-byte identifier limits in older C standards.
Hmm. In C for TOPS-20, char is 9-bit, 1/4 of the 36-bit word. What languages used 6-bit ones?
I think Burroughs machines might.
What languages used 6-bit ones?
What languages used 6-bit ones?
The assemblers. Pretty sure the linker used 6-bit bytes too, but it’s
been a long time. I never did anything with C. I was more interested
in the assemblers and whichever Lisp implementation shipped with the
Panda distribution back then.
I have to admit I can’t remember how PDP-10 addressing worked. I was under impression that the reason C for it used 9-bit char was that 18-bit half-words and 9-bit quarter-words were directly addressable. UTF-18 RFC seems to confirm that idea.
Many of the lessons of The Mythical Man-Month are true nearly 50 years later. I consider it mandatory reading for new engineers, and I often encourage engineering managers to read it.
It’s a sad statement about the software engineering industry that people still need to learn these lessons.
I’m not sure if I agree - some of it is not obvious. Hey I’m not saying the industry isn’t a shit show :)
I am saying that I don’t think people are taught (very often anyway) the engineering part of software engineering: how to work on a team, why accountability and dependability really matters, how to concisely and accurately communicate to both tech and non tech colleagues… so much more.
Still the most vital book on software engineering, and it’s a sad state of affairs that many of its lessons fail to be learned. Another of his books - the Design of Design - is also absolutely excellent, though few seem to have heard of it, let alone read it.
His writing was inspirational and helpful for me and countless others. I think I’d be quite happy to even have 1% of the positive impact that he was able to achieve. Things to aspire to! Thanks, Fred!