Re: Any research putting c above ada?

[jsa@alexandria (Jon S Anthony)]

In article <5lsjb3$bqc@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

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

Right _now_ I'd say that SE is kind of a "hoax".  But that's because
no one's actually tried to define it in a rigorous way analogous to
the activity in other engieering disciplines.

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

Well, here you are really climbing out on a (weak) limb.  The "micro
level" aspect of programming is somewhat related to theorem proving:
stuff like what Gries presents in _The Science of Programming_.  And
this is important stuff basic stuff.  Kind of like how an aeronautical
engineer needs to know about fluid dynamics and such.  Or how an EE
needs to know (at a kind of cookbook level) basic QM stuff.

But as everyone knows, this is just the starting point for any
_realization_ of such "micro level" pieces.  And it does not have much
to say about how these pieces can be fit together into a whole which
will function, perform and be useable at the proper levels in the real
world context they are to live in.


> 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.

You missed the true heart of the stuff: real engineers use an
application of science and mathematics to derive first level _ideal_
approximations of the desired end result.  Then you have to face
reality, as it were, and then try to get a _real_ result which comes
in reasonably close to the ideal and which is actually _useable_ in
the desired context.  This is kind of like a sophisticated constraint
based reasoning and experimentation effort.

The point is: software artifacts (applications, components, whatever)
have to live in the real world just like hardware artifacts (engines,
wings, ICs, whatever).  And there is as much of difference in _kind_
between ideals in software construction as ideals in real engineering.
And this major fact is what seems to be lost on most software people.


> 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.

IMO, this is a) a very odd idea of what SE should be and b) one that
is probably shared by most software people.


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

This is rather telling.  Why is there such an emotional reaction to
this???

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com