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: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: abo@minkirri.apana.org.au (Donovan Baarda) Subject: Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake) Date: 1997/07/04 Message-ID: X-Deja-AN: 254614844 References: <33957A33.1C31AB44@oma.com> <865898351snz@nezumi.demon.co.uk> <339ED54C.215A5F85@oma.com> <5noc8u$a8m$3@miranda.gmrc.gecm.com> <33A032AC.2D8BA85C@oma.com> <5nrn86$cvo$3@miranda.gmrc.gecm.com> <33A1CBBB.B0602EC@oma.com> <5o2uls$ku3$2@miranda.gmrc.gecm.com> <33A6ADDA.2099EEB9@oma.com> <33A7D2DE.545B@polaroid.com> <33A9338D.10BB@polaroid.com> <33B09D64.E7F99DA3@saguarosoft.com> <33B16CBB.417A@gdesystems.com> X-Server-Date: 4 Jul 1997 14:17:48 GMT Organization: Minkirri Internet Access Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-04T14:17:48+00:00 List-Id: On Fri, 04 Jul 1997 00:16:15 -0800, Matthew Heaney wrote: >In article , >abo@minkirri.apana.org.au (Donovan Baarda) wrote: > whoa, I never intended to spark another language war, but I guess I asked for it with that last paragraph :-) >>One of the things that can make Ada pretty inefficient is its pass by copy [snip] >I think there's a misunderstanding here. The language only mandates that >scalar types and access types be passed by copy, and the RM makes it clear >that the implementation is free to choose the mechanism (ie by reference) >for arrays and records. > You are right. However, IMHO, this raises another hairy issue of the language behavior being undefined since pass by copy and pass by reference are semanticly different when parameter aliasing kicks in. For example; procedure mung(R:in out matrix;A:in matrix) is begin R(1,1):=R(1,1) + A(1,1); R(1,1):=R(1,1) + A(1,1); end mung; mung(M,M); the book I've got says that programs that depend on the mechanism used are erroneous. I would take a bloody good compiler to raise an error on a program that does it. >>The biggest problem with Ada compared to C, is the language is so complex. >>The compiler writers have such a hard time just getting it to work that >>they hardly get around to putting in optimisation. C is so small that >>compiling it is easy, so more effort gets spent on optimization. > >I asked Robert Dewar, the principal developer responsible for GNAT (a free >Ada compiler that targets the gcc), a similar question about Ada's putative >complexity, and he responded that it wasn't the front end that was the hard >part, it was the back end. > But the language complexity doesn't just impact the front end, it also makes the back end harder as well. In the case of GNAT, I belive they started with the gcc backend, but had to modify it to meet Ada's specific requirements. Many other compilers for more compact languages manage to use the gcc back end unchanged. >So it would appear that at least one compiler vendor _does_ spend a lot of >time on optimization. > I'd be interested in knowing if the effort spent on the back end was actualy improving optimization, or just trying to shoe-horn Ada into it. The gcc back end already has pretty impressive optimisation. >Also, at least a couple of other compiler vendors in the real-time market >have purchased Intermetric's Ada-Magic front end, so that they too can >spend their time on optimization, because they were able to buy the front >end off the shelf. > what this also means is the front end is non-trivial, and they were better off paying someone else a fortune for it than developing their own. >So again, I am confused by the comment that "compiler writers don't have >time to optimize the code," because there is ample evidence to the >contrary. For which compiler writers specifically is this the case? > What I should have said is; given equivalent time and resources, people developing compilers for simpler languages will be able to put more work into optimization than people developing Ada. This statement clearly points to the fact that in the end, Ada will probably do optimisation at least as good as any other language because there is more time and resources being put into Ada compiler development. >>I find it hard to believe that there are people who advocate Ada purely on >>language merits. As a language, Ada sucks. It is probably better for >>large projects than C, but then C is only a small step above assembler. In >>just about any application you can think of, there are languages better >>than Ada for the task. > >Having programmed in C, Fortran, and Ada, my personal experience with Ada >has been quite positive. In Ada, I am able to specify records for external >device I/O with a precisely defined layout, am able to write date >structures that I can use for any assignable type, have multi-threading >built into the language, etc, none of which I can do in C. > >Don't get me wrong, I like C, but my experience is that Ada is a much more >expressive language, and I am much more productive as a result. > >Perhaps you could provide an small code example of why you think that Ada >"sucks." On what specific basis are you making this statement? > Granted, Ada is better than C or Fortran for most applications. But there are other languages that do it better. However, before I get into a your-gol vs my-gol discussion, I should point out that it is easy to invent a new language that is "better" than any other language for a variety of reasons (especialy with the benefit of hindsite). It is much harder, and more significant, to get that language into widespread use. My original point was that arguing for your-gol based on language merits alone is asking for trouble, because sure as chips there's going to be some-gol out there that does it better. Particularly with a language as old as Ada. I know Ada 95 is more recent, but bolting OO onto a procedural language is always a compromise compared to starting with a clean slate. A more important measure of a languages worth is how many people understand and use it. Eskimo might be the best language to talk about snow, but it's no good if there's no one to talk to (Appologys to any Eskimo's out there). When you start to take this into account Ada starts to look pretty good. Now back to the language war :-) Ada 83 took 63 reserved words and 180 syntax rules to do what modula-2 does in 40 reserved words and 81 syntax rules. The only things missing from modula-2 that are in Ada are generics, exceptions, and operator overloading. However, it makes up for these deficiencys by having late binding (through procedure variables) and a neater, cleaner, simpler syntax. Unfortunatly, Modula-2 and Ada appeared on the scene about the same time. With little difference between them bar complexity, the DOD mandate faded Modula-2 into obscurity. Dispite this, it did briefly have some favor in Europe, and has been an inspiration for many other languages since. Most languages that claim inheritance from Ada usualy owe more to Modula-2. >I ask because I am interested in learning more about C and other languages, >and so maybe there is some feature that these other languages have that Ada >doesn't have, that I am unaware of. > Feature counting alone is not enough to gauge the technical merits. Too many features can also compromise a language. The thing to aim for is the minimum number of features required to cover the maximum number of target applications most comfortably. However, since you asked; Garbage collection, Multiple inheritance, Design by Contract (inheritable assertions) Parametric classes (OK, sort of the same as generics, but more formalised) A complete inheritance heirachy >One application I can think of, and which I've had a some experience with, >is with real-time embedded applications. I can say that having done it >both in C and Ada, my preference is for Ada. > my preference would be modula-2, but you'd probably have a hard time convincing a customer to let you. C might still beat Ada on this one at this stage because of a broader, cheaper, development tool base. When it comes to hard real time, Assembler is still right up there. >Another application is in safety-critical applications such as railroad >control and air traffic control, for which Ada is very highly suited. In >fact, Ada is the language of choice for such systems. (Visit the Ada home >page, , for a list of many companies writing Ada >software for this domain.) > The Ada home page is hardly going to say Ada is a crock. Just like the Eiffel pages aren't going to say Eiffel is. Here's another interesting URL; http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html [snip] > >I think the DOD would prefer you use Ada, but the DOD does not mandate >Ada's use. As a contractor to the government, you are free to use whatever >language you feel is most appropriate (in the context of a systems >engineering analysis). That there is no mandate for the use of Ada should >be interpreted to mean that Ada is a strong enough language that it doesn't >require a mandate. > Ada has probably got enough momentum now to keep going without a DOD mandate. However, now DOD has opened the door... >Note too that the idea that Ada is "used for military applications only" is >a myth. There many safety-critical systems - not military in any way - >written in Ada. For example, the Boeing 777 is an all-Ada system. > >What language do you feel is better than Ada for safety-critical systems? >Can you explain what features that language has that makes it so? I would >like to learn what you know about safety-critical applications. > Eiffel is IMHO a better choice for safety-critical applications without excessive real time requirements. Design by contract obviously (and measurably?) contributes significantly to program safety. Combining this with a complete inheritanc heirachy of library classes with all the contracts defined and inheritable has to make a huge difference. OO and real time never were good bed-fellows, but they are getting more comfortable together all the time. However, I would probably still go for a procedural language becuase most control-systems theory is well formalised to produce a procedural design. >Also, I'm not sure what you mean by the comment that Ada is good because it >means "more money for programmers." As a consultant, my fee is the same >for Ada, C, C++, Java, or whatever other language you ask me to use. > But I bet you get more Ada work because there is currently more demand for Ada programmers per available programmer than for the other languages. A good URL on languages and language comparisons is; http://www.progsoc.uts.edu.au/~geldridg/cpp/ ABO