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: 103376,91c7c63c23ef2d0c X-Google-Attributes: gid103376,public From: gwinn@res.ray.com (Joe Gwinn) Subject: Re: Beware: Rep spec on an enumeration type ... Date: 1997/12/12 Message-ID: #1/1 X-Deja-AN: 297711350 References: Organization: Raytheon Electronic Systems Newsgroups: comp.lang.ada Date: 1997-12-12T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > I actually think that more important than whether glitches exist is the > support a vendor gives in helping you find and fix glitches. To me, one > of the nice things about the specific discussion of enumeration types was > the note from Intermetrics that the next version of the compiler would > indeed fix the failure to recognize the confirming rep clause as a special > case. It's that kind of responsiveness that users really need, and in this > case will get. Support after the blunder is very nice, but it's a lot less painful if we can avoid the blunder in the first place. And, my complaint was never about lack of post-blunder support. > < allowing one Ada customer after another to blunder into such well-known > beartraps. Most customers are domain experts, not language experts. > Telling them after the fact that they should have known better just makes > them angrier and angrier, and drives them away.>> > > Well I must say this giant population of angry Ada users who don't know > what they are doing must either be smaller than Joe thinks, or they must > not be using GNAT :-) Well, let me tell you another saying from the retail world: For every customer that complains, there are ten who will simple never come back. Silence is not golden. > Seriously, I think Joe way overstates the problem here. Perhaps his shop has > just had bad luck, but I think the kind of problem he worries about is a > relatively minor issue in the overall success picture of the use of Ada. Of course we were in a sense unlucky, but ... On a project of any size, the language will be well explored, and most such blunders will be made somewhere, so it isn't really a matter of luck. > You do not have to be a language expert to have the background to have a > feeling for many of these issues. A basic graduate course in programming > language design and compiler techniques, should be quite adequate, the > sort of education that any CS graduate should have. If you have an entire > project with no one with this kind of background, then I think that is > definitely asking for trouble! Well, this certainly allows us to size the problem: One must have a graduate degree in language design and compiler techniques to use Ada. That's quite a revelation. We would have never suspected that Ada was that hard to use. This gets to the heart of the problem. Our programmers, being domain experts, would rather take graduate degrees in their respective fields of interest, in their chosen professions. If they were interested in being compiler experts, they would have instead studied compilers, and they would probably work for a compiler vendor, not a system vendor, because few system vendors build compilers. Nor would they be experts at other than compilers; there are only so many hours in the day. Domain expert and compiler expert are very different fields. > That being said, there are definitely some areas where Joe's wish for some > standardized advice would be useful. For example, all Ada programmers should > understand the two models of implementing variant records with default > discriminant values, and all Ada programmers should be aware of the > consequences of using controlled types. This sounds interesting. Could you expound further? Joe Gwinn