Loading ...
Sorry, an error occurred while loading the content.

Re: Obama II

Expand Messages
  • Klaus Stock
    ... 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
    Message 1 of 22 , Nov 12, 2012
    • 0 Attachment
      > 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?"

      - Klaus

      >> 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
      >>
      >>
      >> _______________________________________________
      >> http://box535.bluehost.com/mailman/listinfo/brin-l_mccmedia.com
      >>

      >

      >



      --
      Best regards,
      Klaus mailto:ks@...


      _______________________________________________
      http://box535.bluehost.com/mailman/listinfo/brin-l_mccmedia.com
    • Doug Pensinger
      Actually, bugs/design flaws caught during the design phase cost far less than those discovered during the build. Doug GSV Prior Planning Prevents Piss Poor
      Message 2 of 22 , Nov 12, 2012
      • 0 Attachment

        Actually,  bugs/design flaws caught during the design phase cost far less than those discovered during the build.

        Doug
        GSV Prior Planning Prevents Piss Poor Performance

      • Dan Minette
        ... You know that, in over 30 years of programming, I never really had those types of bugs that become features in software. But, I m very unusual, I program
        Message 3 of 22 , Nov 17, 2012
        • 0 Attachment
          >
          > 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.

          You know that, in over 30 years of programming, I never really had those
          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
          pause.

          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.

          Dan M.



          _______________________________________________
          http://box535.bluehost.com/mailman/listinfo/brin-l_mccmedia.com
        Your message has been successfully submitted and would be delivered to recipients shortly.