After stating that he hates the book, he writes, "I have mastered six programming languages from language reference manuals, and my software has been used at five planets and the moon, so I speak advisedly." Ouch.
> struggling for seven years to learn Word Visual Basic using this book as a reference
On the other hand, the "struggling for seven years" part suggests that he might not be a transdimensional supergenius, or at least might not be brilliant about allocating his time. At some point you'd ordinarily just chuck a bad book in the trash.
My heart was in my mouth reading this; what a moment to have been alive. I can't begin to fathom the emotions for all involved. It must have been terror mixed with elation, doubt, fear, hope and wonder. Any small mistake from the ground or space crew regarding any number of tiny details could have ended the mission. I'm in absolute awe of the training and skill involved.
Does anyone else know of similar accounts of early spaceflights? I'd love to know if the audio from the radio is available too.
I'm currently reading "The Dream Machine" [1], about the first evolutions of computing. At the moment it's describing the period during and immediately after the Second World War, with computers like ENIAC. It blows my mind that in the space of around 20 years, we progressed from computers that were programmed by turning shafts and ran computations using systems of wheels and mechanical relays [2] to the Lunar Module Guidance Computer with its pre-emptive multitasking and automatic pilot.
Sometimes the rate of technological advance is just staggering.
IIUC it was a bit of both. A unit of work was meant to be short lived, but if a higher priority unit of work came along it would be pre-empted and its state pushed out to a temporary store.
There's a full description in the article, though it's buried a bit far down. Here's a snippet for grep-ability:
if a low-priority job was executing and a high-priority job was scheduled, the low-priority job was suspended while the higher-priority job executed.
"It would have been easy for us to adjust the parameter that controlled how long the delta-V monitor waited before testing the engine — but nobody told us."
Sleep-and-assume programming is the bane of automation. Ideally, the software people should have gotten the hardware people to install some kind of sensor to detect the right condition, but I guess it was either limited by what could actually be done with the hardware, or maybe they didn't have enough influence to get the design changed...
I think this was instrumental in their success - older people are more cautious their approach. Younger people don't know what can and can't be done and are way more Liberal in taking risks.
I also think of this as related to the second system syndrome - Apollo was the first system for a lot of these engineers, and doing lots of things for the first time ever. People were bold and cautious at the same time. The Space Shuttle was the second system - an way over engineered system that did not reach the targets it was designed for, and was successful only through large amounts of money being thrown at the problem.
I'd also love to see a book by Allan Klumpp. He wrote the ultimate mic drop review on Amazon: http://www.amazon.com/gp/review/R3VJW144Y9YDBQ?ref_=glimp_1r...
After stating that he hates the book, he writes, "I have mastered six programming languages from language reference manuals, and my software has been used at five planets and the moon, so I speak advisedly." Ouch.