From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Any research putting c above ada? Date: 1997/05/20 Message-ID: #1/1 X-Deja-AN: 242906812 Distribution: world References: <5lsjb3$bqc@bcrkh13.bnr.ca> Organization: PSI Public Usenet Link Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-05-20T00:00:00+00:00 List-Id: 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