ted@grebyn.com (Ted Holden) (12/01/89)
From: Steve Vestal, Honeywell >As I recall, the Performance Improvement Working Group (PIWG) affiliated with >ACM's SIGAda intended to collect results for their benchmark suite and make >these publicly accessable. Does anyone know whether these results are >conveniently available (e.g., anonymous ftp)? Inconveniently available? >An article in the Nov/Dec Ada Letters by Asplund et. al. gives some benchmark >figures associated with interrupt handling (among other things). Does anyone >know if PIWG is thinking of addressing interrupt-related timings in any way? Just when I get ready to leave off the Ada group for awhile, they toss me something which nobody could resist. Normally I wouldn't cross-post this kind of thing, but I feel the people in the C++ group need to know the scale of the opportunity which is here. The idea of being able to standardize on a single programming language (assuming that language were good enough to standardize on) would be of enormous benefit even to many mundane organizations such as Census, where data has always been generated with mainframes and Cobol and analyzed with Fortran and Fortran related software, and the two groups can barely talk to eachother. The U.S. military has a far worse Tower-of-Babel situation and has attempted to solve it by creating a Frankenstein language for all purposes. The literature and every conversation I have ever had with real-world people who have been forced to actually attempt to USE Ada have totally convinced me of the failure of this project. By the same token, C++ could very nearly, if not entirely, fill the bill. PIWG??? I feel the word "working" should be left out of the group's title; it doesn't really fit, and it just makes the acronym sound bucolic. Kind of like Pappy Parker back in the Ozarks callin the "hawgs". Did you ever wonder why there isn't any such thing as a PIWG associated with Pascal, C, or C++? Why these other languages don't seem to REQUIRE a PIWG? I'll tell you: it's because these other languages were D-E-S-I-G-N-E-D right in the first place. For this reason, practitioners of C++ programming don't need to spend three years of "designing" around a language for every three months of coding to solve problems. They simply solve the customer's problems. Ted Holden HTE
jjs@sei.cmu.edu (Jeffrey Stewart) (12/02/89)
In article <14062@grebyn.com> ted@grebyn.com (Ted Holden) writes: >The literature and every conversation I have ever had with real-world >people who have been forced to actually attempt to USE Ada have totally >convinced me of the failure of this project. By the same token, C++ >could very nearly, if not entirely, fill the bill. Well Ted, I guess you never talked to me or the group I worked with at Hercules Defense Electronics. We have just finished a project to implement all of the control software plus some signal-processing software, in Ada, for a Millimeter-Wave radar seeker for the Maverick missile. Its about 7500 lines of code, based on an object-oriented design, does signal-processing, provides dual-loop control for the antenna, provides mission control for the entire missile, plus some other things. And it does it at 600Hz, on a 10MHz 80286. There is NO ASSEMBLER. The goal was a complete Ada artifact, and the goal was achieved. We wanted a complete Ada artifact because part of the goal was for the implementation to be as portable as possible. We achieved this, in part, by rewriting some of the system requirements to be event, rather than timing, driven. There was zero loss of functionality and performance due to these changed requirements. We had NO problems with the language. We did have one problem with the compiler generating incorrect code for a representation clause, but this was a compiler implementation problem which was easily fixed by the vendor. Projects that DO have a problem with Ada tend to fall into the following categories : The classic "10 pounds of stuff into a 5 pound bag" problem. You won't solve this with C either. Many times, the requirements stack the deck against you. Period. Less than production-quality compilers. I'll admit this was a problem, and is less so every day. Whiners who will use every excuse to blame the language rather than the design. The two ARE different, design and implementation, don'cha know? Many of these projects fail due to poor design, regardless of implementation language. I refuse to assign percentages to these categories. Let that be an exercise for the reader. By the way Ted, part of the rationale for Ada was that the techniques and languages in current use (mid 70's) would be inadequate for the million-plus SLOC systems anticipated for the 90's. What are the successful C-language projects of this size? I like Ada not because it is Ada, but because, in my estimation, it allows the best use to-date of all the software engineering principles I know and have seen used effectively. Most C code still looks like line-noise to me. To sum up, Ada DOES work, for its intended purposes. Maybe you should consider becoming an equal opportunity basher, i.e., cite some C/C++ failures as well. (And don't tell me there aren't any. Your use of absolute terms is part of what detracts from your credibility.) Jeff
trichard@tinman.cis.ohio-state.edu (Terri Richard) (12/02/89)
In article <14062@grebyn.com> ted@grebyn.com (Ted Holden) writes: >Just when I get ready to leave off the Ada group for awhile, they toss >me something which nobody could resist. Please try to resist anyway. >PIWG??? I feel the word "working" should be left out of the group's >title; it doesn't really fit, and it just makes the acronym sound >bucolic. Kind of like Pappy Parker back in the Ozarks callin the >"hawgs". I think most people who read this conference are really tired of hearing this. If you love C++, great. Just don't hassle productive conversations on THIS conference. I for one am extremely tired of hearing it. -=- Terri Richard | We do not guarantee the suitability of this software for Cptr/Inf. Science | any purpose whatsoever. In fact, we can't think of any The Ohio State Univ.| use for it at all. -- trichard@cis.ohio-state.edu
rracine@ajpo.sei.cmu.edu (Roger Racine) (12/02/89)
The PIWG (Performance Issues Working Group) has a very useful set of tests for benchmarking Ada compilers. Ted Holden, you are wasting an awful lot of time and money sending these misstatements around the country. You do not have to like Ada. You may have to use it if you do work on new DoD projects. But what purpose does it serve to answer a request for information on a serious subject with a lot of rhetoric without any facts to back up your statements? Back to the PIWG. To attempt to compare compilers, operating systems, databases, and other software systems, people have been creating benchmarks for years (Whetstones, Dhrystones, etc.), no matter what Ted Holden says. Byte Magazine has a set of tests for comparing computer systems. PIWG created a set for testing Ada compilers and runtime environments. It is not easy to create standard tests for interrupts u knows the hardware. So the last time I used the PIWG, it did not support testing that. However, they have been working on it, and it could be available. The correct person to contact is Dan Roy (301) 464-6800. He chairs the working group. Roger Racine