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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 146b77,d275ffeffdf83655 X-Google-Attributes: gid146b77,public X-Google-Thread: 103376,d275ffeffdf83655 X-Google-Attributes: gid103376,public X-Google-Thread: 115aec,d275ffeffdf83655 X-Google-Attributes: gid115aec,public From: gwinn@ma.ultranet.com (Joe Gwinn) Subject: Re: Ada vs C++ vs Java Date: 1999/01/24 Message-ID: X-Deja-AN: 436477376 References: <369C1F31.AE5AF7EF@concentric.net> <369DDDC3.FDE09999@sea.ericsson.se> <369e309a.32671759@news.demon.co.uk> <77ledn$eu7$1@remarQ.com> <77pnqc$cgi$1@newnews.global.net.uk> <8p64spq5lo5.fsf@Eng.Sun.COM> <782r25$k18$1@nnrp1.dejanews.com> <787f4b$jl9$1@nnrp1.dejanews.com> <78g0oj$8sb$1@nnrp1.dejanews.com> X-Ultra-Time: 24 Jan 1999 23:45:55 GMT X-Complaints-To: abuse@ultra.net Organization: Gwinn Instruments Newsgroups: comp.lang.ada,comp.vxworks,comp.realtime Date: 1999-01-24T00:00:00+00:00 List-Id: In article <78g0oj$8sb$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: > In article > , > gwinn@ma.ultranet.com (Joe Gwinn) wrote: > > Had a formal C language reference been available back > > then, I would have used it. > > > > You keep trying to make it more than I ever claimed for > > it, an exercise in knocking strawmen down. I think I > > accurately described the data point, and leave it to the > > readers to draw whatever conclusions they wish. > > Perhaps naively most readers will expect that if you > describe such a data point, then at least you ascribe > *some* significance to it. That is certainly the > implication from your original post! > > If indeed you agree that this is a nonsense comparison that > tells absolutely nothing of any value at all, then we have > no argument! > > > You keep trying to make it more than I ever claimed for > > it. I think I accurately described the data point, and > > leave it to the readers to draw whatever conclusions they > > wish. > > Again, we assumed that at least *you* thought that your > observation had some value (you did after all spend some > time doing it). In fact neither of these observations says > anything at all useful about language comparisons. > > Producing completely bogus comparisons, and then saying you > have accurately described these comparisons seems > disingenuous. At the very least you were trying to convey > the impression that something useful was being measured! The evidence is what it is, and we cannot do much about it, fifteen year later. > > You have gnu C, C++ and gnat at your fingertips. What do > > the various components weigh? > > It is not something I would spend 30 seconds looking at, > because the answer to this question would convey little of > value! If perfect metric existed, we would use them. Absent perfection, we use what's avaialble. I take it the answer isn't to Ada's perceived advantage. > > But, let's get down to brass tacks, using personal > > experience and whatever expertise and instincts we can > > muster to sort some languages into a rough complexity > > ranking. > > Gosh, it almost seems like you did not bother to read my > last note, the whole point of which was that to lump the > different aspects of complexity into a single metric does > not work. Clearly, I didn't accept the argument, which boiled down to saying that because we couldn't find a perfect metric, we should do absolutely nothing. I know what would happen if I tried that kind of perfectionist argument out on my boss. Rough measures are better than no measures at all. > > 3. Ada83 versus K&R C? Ada83 is a factor more complex, > > by all metrics, than K&R C, by universal experience. > > Since this seems to be your most obvious case for expecting > an unconditional yes vote, I will choose this one to > illustrate. Yep. OK. > First of all K&R C is ill defined. Lack of definition > results in a lot of uncertainty of semantic details, and > this kind of uncertainty leads to significant complexity: We already agreed that Ada83 is better defined than K&R C, so further discussion of that is beside the point. Please answer the original question, yes or no. > For example > > int a[10]; > ... > for (p = a; p < &a[10]; p++) ... > > is this valid K&R C? Difficult to say, probably the answer > is no, but on the other hand, C programmers use this > construct all the time. It is of course legal in ANSI C by > virtue of a very special (and rather odd and non-orthogonal > rule). Yep. But, beside the point. > If we are going by the metric of ease of formal > description, I would say Ada 83 is far simpler than K&R C, > just because so much remains to be done in the latter case. > That work of course is what took the ANSI C committee so > much effort to sort out. Yep. But, beside the point. > As for ease of use, this depends what you are doing, if you > have to write a multi-threaded application in a portable > manner, then in one sense it is impossible with K&R C, but > in pragmatic practice it means struggling with some > pthreads package. These packages are typically ill-defined > and all sorts of non-portable glitches occur. Ada 83 is by > comparison a far simpler environment. The same goes for > code that needs exceptions. Perhaps. But, beside the point. > From an implementation point of view, C may be simpler, > though even there it is not quite cut and dried. For > instance extraction of good aliasing information of the > same quality can require FAR more work in C than in Ada, or > even be quite impossible. Furthermore, the need for good > aliasing information in C is much more important because of > the lack of strong typing of pointers in the Ada sense. Perhaps. This is your area of expertise. I guess this is a "yes", sort of. > About the only place where I would say that C is clearly > simpler than Ada 83 is in the comparison of informal > descriptions, where K&R shows that a fairly short informal > description of C is possible. Has anyone written such an informal description of Ada83 as well? I never saw such a description, simple yet possible to program from, and one has to wonder if it's possible to write such a thing. Joe Gwinn