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: 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/20 Message-ID: #1/1 X-Deja-AN: 435058072 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> X-Ultra-Time: 21 Jan 1999 02:34:35 GMT X-Complaints-To: abuse@ultra.net Organization: Gwinn Instruments Newsgroups: comp.lang.ada,comp.vxworks,comp.realtime Date: 1999-01-20T00:00:00+00:00 List-Id: Well, I can always depend on Robert for a fight... In article <782r25$k18$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com wrote: > In article > , > gwinn@ma.ultranet.com (Joe Gwinn) wrote: > > I think the point being made was that plain vanilla C was > > less complex than Ada (83 and 95) and also C++. > > Not so fast! Complexity/Simplicity can talk about many > things. > > Complexity of implementation > Complexity of formal definition > Complexity of informal definition > Complexity of learning language > Complexity of programs written in the language > > Often these are in direct competition. For example, adding > exceptions as a primitive feature can complicate the > definition and implementation, but it may very well > simplify programs written using this feature. Hmm. I was reminding people what the other poster said, and he didn't talk of these details, and may not care to go that deep. > > A data point. In the 1980s, this same issue came up with > > respect to K&R C and Ada83. To avoid unresolvable > > theological debates, I "weighed" the DEC Ada and DEC C > > compilers on VAX/VMS. The Ada compiler was ten times > > larger. This is roughly the ratio of the sizes of their > > respective language reference manuals as well. > > K&R C is NOT a reference manual, the proper comparison is > the ANSI C standard vs the Ada standard. There is nothing > LIKE a factor of 10 in this. By comparison with either of > these standards, K&R is simply an informal description. > Note that this comparison is on just one dimension, namely > complexity of informal/formal definition. A data point is a data point, not a universal law. I stand by what I said. The K&R White Book was the sole C manual for many years, so it'll have to do. ANSI C is not quite the same langauge, and came many years later. > As for the size of the compilers, you were at that time not > looking at modern optimizing compilers. If you repeat this > experiment with modern optimizing compilers, you will find > that for all the languages, the majority of the complexity, > and weight of the compiler is in the optimizer. For > example, even when using the GNAT front end, there are more > lines of code in the gcc backend than in the front end. So > you couldn't even reach a factor of 2 in that context. Is the optimiser common to both languages? Back in 1980s, I couldn't isolate the parts of the two compilers, and nothing was shared anyway. So, tell us, what are the weights of the various front ends, and the optimiser or optimisers? Is there still a pure "C" front end, or has it been subsumed into the C++ front end now? It used to be that C++ was a preprocessor that generated C source code that was compiled by this front end. > And of course this also measures only ONE of the components > of complexity, namely complexity of implementation. Yep. One would assume that all these complexities are more or less proportional to each other. In particular, complex syntax has got to cause complex compiler code. Have you suitable numerical metrics for the other components of complexity? > > Assembly language is simpler than any high-order > > language, but it's lots more work to code in assembly. > > Now let me guess. The last time you looked at machine > language was in the 80's, right? Yes, in those days, the > semantics of machine language was pretty simple. No, 1998. We do read and sometimes write PowerPC assembly code. Many 1980s machines had more complex instruction sets than the PowerPC. > I am afraid that things have changed. At this stage the > full execution semantics of a modern chip with extensive > instruction-level parallelism is remarkably complex along > ALL the dimensions I mention above. A chip like the Pentium > II, if you include efficiency issues, which are indeed not > fully documented publicly, let alone formally specified, > you have something far MORE complicated than any of the > languages we are talking about here. All true, but what has all this to do with the original question, the relative complexity of C, C++, Ada83, and Ada95? > >> Yet, people still use assembly. > > Well barely ... We try to avoid it, but don't always succeed. Another variant is to code in a high-order language (HOL), inspect the generated assembly, paraphrase the HOL source trying to improve the assembly, iteratively. This can be very effective, but it does give a false impression that the code is in a HOL. It isn't really, because a new compiler will force a repeat of the tuning steps just described. Joe Gwinn