Re: Obama II
> This plays into some recent conversations about "efficiency" vs "resilience."Yup. And neither "efficiency" nor "resilience" will help you in the
end if you don't ponder some important questions first. Like: "do we
measure altitude in feet or meters?", or "should we check if the old
guidance system will work okay in the new rocket?"
>> Date: Mon, 12 Nov 2012 20:06:16 +0100--
>> From: ks@...
>> To: brin-l@...
>> Subject: Re: Obama II
>> > I know as a fact that the Defense Department said they
>> > would require that all programming for applications they used would have to
>> > be done in Ada (I think within 5 years) because Ada was a compiler that
>> > automatically eliminated bugs.
>> AFAIK, the Ada compiler can detect many programmer mistakes at compile
>> time. Of course, one might say that Ada that's mainly because Ada
>> imposes so many restrictions on the programmer that the chance to make
>> mistakes is greatly increased (compared to more "relaxed" languages,
>> which do, for example, implicit type conversion). Ada also supports
>> run-time-checks - which detects bugs when it's already too late (or
>> may even cause bugs in extreme cases).
>> Compared to other languages of the time, like Fortran, it's clearly
>> superior in detecting some classes of bugs early. It also reduces the
>> programmer's efficiency, resulting the number of bugs per time compare
>> to more efficient languages.
>> However, the "best bugs" are introduced during programming, but much
>> earlier. Catching bugs at the earliest possible time is expensive, but
>> the ROI is immense and outweighs the cost by several orders of
>> magnitude. Of course, any manager who was reading this dropped out at
>> the word "expensive", so defective software will remain the standard.
>> Okay, the word "standard" reminds to get back on-topic. I suspect that
>> the reason for the choice of Ada was that Ada was the first
>> standardized HL programming language. Oh, the military loves
>> standards. No further explanation necessary.
>> Best regards, Klaus
Actually, bugs/design flaws caught during the design phase cost far less than those discovered during the build.
GSV Prior Planning Prevents Piss Poor Performance
>You know that, in over 30 years of programming, I never really had those
> However, the "best bugs" are introduced during programming, but much
> earlier. Catching bugs at the earliest possible time is expensive, but
> the ROI is immense and outweighs the cost by several orders of
> magnitude. Of course, any manager who was reading this dropped out at
> the word "expensive", so defective software will remain the standard.
types of bugs that become features in software. But, I'm very unusual, I
program as a means of thinking out the physics of the problem I'm trying to
solve. In other words, I write software, where the previous generation, or
even physicists 5 years ahead of me, would work things on on paper.
I recall, back in '81, patientily listening to a post doc explaining how to
do the error anaysis of my data. I patiently listened to him, he knew more
than I did on most things and had earned my respect, until there was a
I then asked him, but isn't this just an approximation, wouldn't running a
Monte Carlo to get the error be more accurate.
He said "yes, but do you have any idea how much it would cost to do a Monte
Carlo error analysis?"
I said "yes, $0.27. I did it this morning."
He looked at me, and said "grad. students have it too easy these days, and I
left his office"
The moral of the story is that if you think carfully about what questions
you ask early, and your job title allows you to do that (as someone who is
expected to come up with inventions that solve problems, you get some
leeway...especially if you have a PhD in physics....it may not be fair that
we get more leeway, but it's my experience), then you can have software that
actually basically works the first time it is tried with a real tool. I've
twice had the experience of "well we'll try this, but we'll have to get back
to you when it fails" and me saying "but, I've tested it pretty extensively
on data in post processing mode, if the same data is in the tool, I'll have
failure modes with unusual data, but it should generally work" and having it
work first time in the tool.