“I am going to a commune in Vermont and will [In my mind I've always heard a 'henceforth' inserted here for some reason] deal with no unit of time shorter than a season”

One of my favorite quotes in the book - when an overworked engineer resigns from his job at DG. The engineer, coming off a death march, leaves behind a note on his terminal as his letter of resignation. The incident occurs during a period when the microcode and logic were glitching at the nanosecond level.

I don't know about an abridged version but it's one of the best books about product development ever written. I actually dotted-lined to Tom West at one point though a fair bit after the events of "the book." (Showstopper--about Windows NT--is the other book I'd recommend from a fairly similar era from the perspective of today.)

Thanks for sharing this. I forgot to add the link in the original post.

I also highly recommend the TV show Halt and Catch Fire. It's not related to the book but very similar spiritually.

I'm about 75% through the audiobook, and it's absolutely fantastic.

The most surprising thing so far is how advanced the hardware was. I wasn't expecting to hear about pipelining, branch prediction, SIMD, microcode, instruction and data caches, etc. in the context of an early-80s minicomputer.

Another great Kidder book is "House", which applies the same perceptive profiling to the people involved in building a single house -- the couple, the architect, and the construction workers. There's an argument that a lot of the best work is done not in pursuit of an external reward but because doing good work is itself rewarding, and one way of viewing these books is as immersive explorations of how that plays out.

The full length version is a really good read

Such a great book… should be required reading for anyone managing engineers.

There is a post Where are they now. In Wired magazine about the team 20 years later https://www.wired.com/2000/12/eagleteam/

It's also the best non-fiction book I've ever read. And won the Pulitzer, I think.

This is essentially the paradigm what Karpathy deemed to be "Software 2.0" in an article in 2017:

https://karpathy.medium.com/software-2-0-a64152b37c35

And the next paradigm shift after that will probably be "programs' own outputs are their input"

> instructions are data.

is an insight I've often seen attributed to von Neumann, but isn't it just the basic idea of a universal Turing machine? - one basic machine whose data encode the instructions+data of an arbitrary machine. What was von Neumann's innovation here?

Similarly, on-board soundcards are notorious for this. Even in my relatively recent laptop I can judge activity by the noise in my headphones if I use the built-in soundcard, thanks to electrical interference. Especially on one motherboard I had, I could relatively accurately monitor CPU activity this way.

There's also audible noise that can sometimes be heard from singing capacitors[1] and coil whine[2], as mentioned in a sibling comment.

[1]: https://product.tdk.com/system/files/contents/faq/capacitors...

[2]: https://en.wikipedia.org/wiki/Electromagnetically_induced_ac...

I have experienced two or three computers in my life (and least one laptop) that produced barely audible sound when CPU activity changed. The most memorable was a PowerBook G4 with a touchpad, and as I slid my finger slowly across the pad in a quiet enough room, I could hear kind of a tick each time the pointer moved a pixel.

My favourite was troubleshooting an already ancient original IBM XT in 1992... The operator was complaining about the screen giving her headaches.

Sure enough - when I went onsite to assist, that "green" CRT was so incredibly wavy, I could not understand how she could do her job at all. First thing I tried was moving it away from the wall, in-case I had to unplug it to replace.

It stopped shimmering and shifting immediately. Moved it back - it started again.

That's when we realised that her desk was against a wall hiding major electrical connectivity to the regional Bell Canada switching data-centre on the floors above her.

I asked politely if she could have her desk moved - but no... that was not an option...

... So - I built my first (but not last) solution using some tin-foil and a cardboard box that covered the back and sides of her monitor - allowing for airflow...

It was ugly - but it worked, we never heard from her again.

My 2nd favourite was with GSM mobile devices - and my car radio - inevitably immediately before getting a call, or TXT message (or email on my Blackberry), if I was in my car and had the radio going, I would get a little "dit-dit-dit" preamble and know that something was incoming...

(hahahaha - I read this and realise that this is the new "old man story", and see what the next 20-30 years of my life will be, boring the younglings with ancient tales of tech uselessness...)

Many years ago, I was a user of an IBM 1130 computer system. It filled a small room, with (as I recall) 16K 16-bit words and a 5MB disk drive, which was quite noisy. I would feed in my Fortran program, then head down to the other end of the building to get coffee. The computer would think about the program for a while, and then start writing the object file. This was noisy enough that I'd hear it, and head back to the computer room just in time to see the printer burst into action.

(Please feel free to reference the Monty Python “Four Yorkshiremen” sketch. But this really happened.)

Some computers ship with an implementation of this using inductor coils which whine depending on the load :D

I remember doing this back on the IBM 1130. We didn't see that there was any value in using it as a monitor.

I really loved that quote in the article. It’s such an excellent description of the “computer voodoo“ users come up with to explain what is, to them, unexplainable about computers.

You’re right though, we’re basically there with AI/ML aren’t we. I mean I guess we know why it does the things it does in general, but the specific “reasoning“ on any single question is pretty much unanswerable.

Are you able to share what these parallels are that you've drawn? I've always thought them to be slightly different processes.

I see this in wikipedia:

"The attribution of the invention of the architecture to von Neumann is controversial, not least because Eckert and Mauchly had done a lot of the required design work and claim to have had the idea for stored programs long before discussing the ideas with von Neumann and Herman Goldstine[3]"

https://en.wikipedia.org/wiki/Von_Neumann_architecture

I believe it was probably a typo, and one that existed in the original paper. The tricky thing about it is, a person might not notice it until it was pointed out. (I didn't - but I verified afterward that it's in Lamport's paper)

I think you’re right, it means something like “if we don’t refuse to accept this”.

That is rather awkward isn’t it.

I really liked that whole block quote though.

Maybe an earlier draft said "We should reject this. If we don't [...]", and was edited to be less harsh.

I don't like to rain on anyone's parade, but this is at least the third time I've seen one of these comments, and if it were me I'd want someone to point out a drawback that these young whippersnappers might be too respectful to mention. Isn't it a truism in modern computer architecture that computation is cheap whereas communication is expensive? That "fancy routing hardware" is what mitigates this problem as far as possible by enabling signals to propagate between units in the same clock domain within a single clock period. Your system makes the problem worse by requiring a number of clock periods at best directly proportional to their physical separation, and worse depending on the layout. If I were trying to answer this criticism, I'd start by looking up systolic arrays (another great idea that never went anywhere) and finding out what applications were suited to them if any.

Please also note that the ENIAC slowed down by a factor of 6 (according to Wikipedia) after it's conversion to von Neumanns architecture. BitGrid is slower than an FPGA, but far more flexible for general purpose computation.

Sorry to burst your bubble but modern FPGAs are already designed this way (latches paired with muxes and LUTs across the lattice). Take a look at the specs for a Xilinx Spartan variant. You still need the routing bits because clock skew and propagation delay are real problems in large circuits.

Happy birthday!

I have no idea what you’re talking about but I’m gonna follow these links.

> for CISC normal to have small number of registers

A very common fallacy. For CISC it's normal to have small number of programmer-visible (architectural) registers. But nothing stops them from having large register files having about a hundred or two of physical registers which are renamed during the execution. IBM has been doing this sort of thing since the late sixties.

Modern x64 have IIRC 180 integer general-purpose registers, and I imagine this number can be increased further: say, AMD's Am29000 from 1985 had 192 registers... and honestly, having more than 16 programmer-visible registers is not that useful when 99.999% of the code is written for the high-level languages with separate-compilation schemes: any function call requires you to spill all your live data from the registers to the memory; having call-preserved registers means that you can do such a spill only once, at the start of the outer function, but it still has to happen. And outside of the function calls, in the real world programs most of the expressions that use only built-in operators either don't require more than 4 registers calculate, or can be done much more efficiently using vector/SIMD instructions and registers anyway.

I don’t think that’s correct. Ideally, your working set fits into the cache, and that doesn’t get smaller or larger when you use a RISC CPU.

(There may be an effect because of instruction density, but that’s not very big, and will have less of an effect the larger your working set)

The definition of organ in this article is closest to the body part definition. The use of organ here relies on a less common definition: roughly a constituent part of some larger whole that performs a specific function.