Slashdot Mirror
Code is Too Hard To Think About (theatlantic.com)
From a longform piece on The Atlantic: What made programming so difficult was that it required you to think like a computer. The strangeness of it was in some sense more vivid in the early days of computing, when code took the form of literal ones and zeros. Anyone looking over a programmer's shoulder as they pored over line after line like "100001010011" and "000010011110" would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe. The introduction of programming languages like Fortran and C, which resemble English, and tools, known as "integrated development environments," or IDEs, that help correct simple mistakes (like Microsoft Word's grammar checker but for code), obscured, though did little to actually change, this basic alienation -- the fact that the programmer didn't work on a problem directly, but rather spent their days writing out instructions for a machine. "The problem is that software engineers don't understand the problem they're trying to solve, and don't care to," says Leveson, the MIT software-safety expert. The reason is that they're too wrapped up in getting their code to work. "Software engineers like to provide all kinds of tools and stuff for coding errors," she says, referring to IDEs. "The serious problems that have happened with software have to do with requirements, not coding errors." When you're writing code that controls a car's throttle, for instance, what's important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head. "There's 100 million lines of code in cars now," Leveson says. "You just cannot anticipate all these things."
"The problem is that software engineers don't understand the problem they're trying to solve, and don't care to,..."
I think they do understand the problem and that's why things generally work, or don't they? I think they do work on the whole.
The reason is that they're too wrapped up in getting their code to work.
To this, I must rephrase:
"The reason is that they're too wrapped up in getting their code to work, as they should..."
Before a single line of code hits the IDE, you plan out what you're trying to solve, the problems you have to deal with, and how the logic will have to act. Coding happens after the "hard" work has been done, once you have a good idea of what has to be done and how to do it.
If anyone thinks that a true software engineer just sits down, starts slamming on some keys and then says "Oh well, I wrote code, let's see how the throttle handles it", then they don't understand software development or software engineering.
I used to work with a couple of NASA subcontractors who talked about when they would code by flipping 8 switches and then pressing a button to push that single byte of code into the computer.
That wasn't uncommon for early personal computers either. Try this in-browser simulations:
Kenbak-1 Emulator
MITS Altair Simulator
Required reading for internet skeptics
"I didn't bother counting, but I doubt there were more than 10K LOCs in the Apollo code, "
Well, you're wrong. Way off, actually.
Code is available here: https://googlecode.blogspot.no...
Here are some crude stats (from a source tree I know nothing about...)
[boa@localhost trunk]$ for i in Artemis072 Colossus2* Comanche055 Luminary* Solarium055; do printf $i; find $i -name \*.agc | xargs wc -l | grep total; done
Artemis072 64444 total
Colossus237 62565 total
Colossus249 64223 total
Comanche055 65585 total
Luminary099 65058 total
Luminary131 63217 total
Solarium055 30074 total
[boa@localhost trunk]$