Goodbye, My Good Friend.

On Mon, 15 Aug 2005 11:33:15 -0700, "Peter Duniho"
wrote:


(getting sucked into an off-topic thread...)

I don't think so. Computers have become such an important part of
flying that we need to address them as much as aerodynamics. Air
Traffic Control, navigation, flight planning, and to a growing extent
our engine controls, are members of that domain.


I think he's talking about the fact that development tools still allow
programmers to do stupid things.

So does the mechanic that forgot to check the last oil line on my
favorite 210. Forced landing and a ruined brand new TSIO-520.

For example, Java and C# add a layer of
protection, making it more difficult for programmers to screw things up.

I tried for years to sell a product called the Input/Output
Requirements Language. In theory it would produce the final code from
the requirement's visual and textual description.

They are still procedural languages, and it may be that programming really
needs a whole paradigm shift to some other sort of programming. Charles
Simonyi was pushing something he was calling "intentional programming" a
while back...so far, nothing real has come of that, but the general thought
that getting a little further from the underlying Turing machine may reduce
mistakes is still valid, IMHO.

I'm not so sure. To me, as a developer, I think that de-humanizing is
the worst solution. Counting lines of code produced per hour is a
good example. We need to get back to individual responsibility for
quality control. And more importantly, individual input for finding
design flaws and their correction. It worked well for NASA in the
1960s. Have we abandonded that work ethic?

That said, most of the problems with programming stem from how careless
people are while doing it. As a programmer myself, I am well aware of the
difference between well-written code and poorly-written code.

I'm a brute force programmer myself. My stuff works.

Most code is
poorly-written, IMHO. This is true through all phases of implementation,
from the original design and architecture, through the actual coding, and
finally with respect to testing, both on the part of the programmer as well
as on the quality assurance folks, should they actually exist.


One of the hardest things that I've done is customer acceptance.
Despite all of the meetings and testing, there is no way we can seem
to just let the system work. There is always something more to do.
That is the point where I would dearly love to start over again with
the latest technology and "do it right".

For the most part, engineering in other technical areas tries to take into
account human error. Structures are built with some margin of extra
strength, machinery attempts to include designs that help prevent the user
from killing themselves, etc. Programming, on the other hand, still pretty
much lets the programmer do whatever dumb thing they want. Protected memory
operating systems (ie, pretty much every operating system in common use
today) do help prevent one bad programmer from messing up someone else's
stuff. But even there, a given application is not protected from itself,
and certain components of the operating system can still bring the whole
mess down (audio and video drivers being a common culprit).


Those are tangible and measurable. With computers it's more like the
fad a few years ago with artificial intellegence. A friend who
studied that at the Phd level explained that the goal was like
defining artificial masculinity. He also looked at genetic
engineering and asked, "What if you changed one line of code in the
most complex program ever written?"

At some point, perhaps programming WILL develop better tools, and maybe even
more stringent standards of quality. I saw an ultrasound machine at the
hospital crash the other day; during a routine exam, this wasn't a problem,
but what if it had been being used during some kind of invasive procedure
(ultrasound-guided fine-needle aspirate, for example). And no, the
ultrasound machine wasn't running Windows (or any other off-the-shelf
operating system). The more pervasive computers become, the more important
it will be to hold programmers to higher standards.


Yes, and that gets back to the individual.

Until then, they are going to keep making the same stupid mistakes every
other careless human being does on a daily basis. And there are a LOT of
careless human beings.


We're human. Thank God. Or at least the incredibly long string of
random events that put us here.

Please note, the above is a broad oversimplification of the issues at hand.
This is the sort of thing that a professional committee could spend a year
talking about and still not come up with a good answer. Pretty hard to sum
up in a single Usenet post, even a long one.

Pete


Mike Weller

Grumman-581 wrote:

Matt Whiting wrote:

Ada is better from a reliability and correctness perspective. So is
Java.


I disagree... You can write crap code in ANY language... I've worked on
Ada and Java projects... Although I have more confidence in Ada than
Java, neither are what I would call "confidence inspiring"... Although
C++ has some nice features, I prefer to stick with straight 'C' from a
portability standpoint... With a statically linked executable, I can
have a pretty good feeling that my executable is going to run the same
each time it is executed... With DLLs and such, this is not possible,
so I avoid them... Unfortunately, sometimes it's difficult to
completely avoide them when you're forced to program for Windoze
platforms...

Sure, you can write lousy software in any language. And you can write
fairly good software in assembly language. However, a language like Ada
makes it harder to make many of the common mistakes made when using
pointers and other memory access and management mechanisms. How many
Ada programs fail by accessing arbitrary memory locations?

No argument with you about Windoze. I gave up software engineering when
RSX and VMS fell by the wayside. After taking a course in C++ and then
one in Windows programming, I just lost all interest in writing
software. C++ is simply a pathetic tool for writing quality software.
When the instructor spent an entire day of a week long course trying to
explain all of the possible nuances of constructor execution, I knew we
were in trouble! :-)


However, I think that longer term model-based development tools
show the greatest promise.


And, exactly WHAT have you been inhaling?

Certainly, not what you are...


rant-mode
The problem that I see these days is that the 'developers' no longer
have to design an entire system... MS has ushered in the age of
fill-in-the-blank programming... These 'developers' draw their user
interface dialogs and how they relate to each other and then all they
have to do is fill in the pieces of code for the various callback
functions...
/rant-mode

Well, yes and no. I also believe the lack of system understanding is a
problem, however, having developers utilize building blocks isn't a bad
deal. If you look at other engineering disciplines, nobody starts from
scratch each time. Most bridges, buildings, cars or airplanes use a lot
of standardized components. Software needed be any different, IMO.

Matt