Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!uunet!keinstr!chaplin From: chaplin@keinstr.uucp (chaplin) Newsgroups: comp.software-eng Subject: Re: bridge building (was Re: Documenting OO Systems) Message-ID: <1991May3.142824.208@keinstr.uucp> Date: 3 May 91 14:28:24 GMT References: <1259@grapevine.EBay.Sun.COM> <9105012313.AA23259@enuxha.eas.asu.edu> Distribution: na Organization: Keithley Instruments, Cleveland, Ohio Lines: 29 In article <9105012313.AA23259@enuxha.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes: >In article <1259@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: >>If you can't engineer software well in C, you can't engineer software >>well period! >> > >Tell that to AT&T after their 1-800 blunder. That error would have been >less likely in different language (like Ada - I had to say that.). > >Harry Koehnemann >koehnema@enuxha.eas.asu.edu Baloney! Read what Chris Prael said! The fact that it is *possible* to engineer software well in *any* language does not mean that well-engineered software is guaranteed. Perhaps the blunder would not have happened had AT&T used Ada, but using Ada would not have guaranteed that the blunder would not have happened. If I have a hacksaw but not a wrench, I can still remove a bolt. It may be easier and I may like the result better if I have a wrench. I have programmed large systems using Forth (no flames, please!) and small systems using C. Had it been the other way around I probably would not have spent as much time programming these systems, but the fact remains that they both perform to specs. -- Roger Chaplin / Instruments Division Engineering / uunet!keinstr!chaplin CI$: 76307,3506 / voice: (216) 498-2815 / FAX: (216) 248-6168 "In the last analysis the customer is the independent auditor. In the merciless light of real use, every flaw will show." - Frederick P. Brooks, Jr.