Re: Any research putting c above ada?

[Craig Franck <clfranck@worldnet.att.net>]

kaz@vision.crest.nt.com (Kaz Kylheku) wrote:

>I would go as far as saying that ``software engineering'' is a hoax.

Or as some would say "a myth and a scam". :-)

>Developing a correct program is much more akin to theorem proving than
>engineering activity. 

I don't agree at all. The metaphor I use for programming is construction.
You literally build a program. I am working on a simulation of a lottery
terminal that will have the same sort of interface (keyboard, screen 
layout) so you can learn to use the terminal with your PC. It will even 
have a mode where it can play customer and ask you for tickets. Anyway,
right now it doesn't do much. The keyboard is all layed out, but there is
only one game and a few reports implemented. When you hit a key that hasn't
been "wired up yet" it will say "Game not active" or "Report not available".

The goal is to have a compilable version at all times. You start with the
framework and add functionality as you go. It works from just about the 
start, and you flesh it out by adding new games and reports and other 
various whatnots to it.

To me, this seems like constructing the frame of a house and adding the 
interior as you go. Checking the program for correctness consists of
critically reading the code, stepping through it in the debugger, and, yes,
actually running it to see how badly it screws up. None of this seems like
theorem proving. I don't know how to prove that the program is correct 
other than reading the source very critically and testing the heck out
of it with various aids. When it performs correctly it is ready. "Getting
into states where it's behavour is undefined" (my favorite software 
euphemism) means there is work to be done. The correctness is demonstrated
by its behavour; there could *always* be a bug lurking. Sitting down and 
reading several thousand lines of code and then "proving" it is correct is 
quite a bit to do. Some things become so complex that the only way to test
them is to simulate them, which is another way of saying "build it and see
what it does".

>There are enough superficial similarities to make the two
>seem the same from a project management perspective. Both the ``software
>engineer'' and the real engineer have to have some creativity, both have
>requirements and deadlines, both work in teams, both assemble systems out of
>more elementary components many of which are designed and built by others and
>so forth.

I don't think that is superficial. At some fundamental level you are doing
the same thing.

>Their fundamental activities are miles apart, however. Software engineering
>merely means the application of the same levels of rigor to software design
>that engineers apply to the design of electrical, mechanical or structural
>systems, and the same standards of quality, accountability and so forth.

That is true, but even an incompetent programmer blundering his way
through the construction of a program is constructing something; how well
it is engineered is another question (I think this is your point).

>From this it does not follow that we should absorb computer science into
>engineering. Phooey!

Well, I don't think it belongs in the hard sciences either! I think if you
grasp how much software and hardware have to interact, there would be some 
justification for creating an interdisciplinary field.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
BBN has the brightest bit-heads on the planet. -- David Goodtree