bob@imspw6.UUCP (Bob Burch) (11/29/88)
From Ted Holden, HTE: ........................................................ Again, I see Ada as the primary programming language in competition with C++, otherwise I wouldn't bother..... From: Thomas Vachuska, HP Roseville Manufacturing Operation >Ted, >you talk (write) too much and you say too little. What is worse, you say that >you do not know what you are talking about. Is this supposed to be an English sentence? I've never accused MYSELF of not knowing what I'm talking about..... >You obviously do not know much >about Ada, for you would not write such non-sense about Ada trying to be an >OS or a 30 line Ada program taking 27 minutes to compile. The computer was a Unisys-Arrete 5000/80 with 4 12.5 mh 68020 processors, the Ada compiler was TeleSoft's Telegen, the watch was an ordinary little black Casio ($15 variety). That was the worst case I ever saw; more normal for small Ada programs on that system was 6 - 10 minutes, still pathalogical. Again, I'd hate to think of three people doing Ada compiles at the same time on that system or on anything like it. >Perhaps 27 seconds >would be more appropriate and even then the program would probably have to >contain at least one generic unit that consists of several hundred lines of >code. The only thing I could imagine compiling Ada that fast would be a Rational (for the uninformed, an $800,000 Ada Software Development work station). Ever wonder why you don't need $800,000 software development workstations for C or C++? Don't worry, it's only the taxpayers' money. From what I hear, good compile speed for Ada on a VAX (DEC's VMS Ada) is measured in hundreds of lines per minute, still pathalogical. Again, I'd hate to see five guys doing it at the same time. Then, there's Ada on the PC (Alsys). Ever wonder why Turbo Pascal, Turbo C, Quick C, Zortech C++ etc. etc. don't come packaged with a LIM board, 2 extra meg of DRAM and a $3500 price tag? From: Erland Sommarskog: ENEA DATA AB, Sweden >And I have seen an Ada compiler compile in just as the same time as any >compiler at that machine. I *have* seen compilers behaving something like >the one Ted describes, but that was five years ago. Things have changed. Translation: "despite the fact that Ada has been out since 1979, Experts are just now getting one or two compilers to perform close to acceptably on today's VAX, 68000 etc. machines..." What about tomorrow's machines, 88000 and SPARK based? Figure they'll have Ada compilers for them by 1999? >Ada wasn't designed to run real-time applications on a time-sharing >system, one should have this is mind. Its real-time primitives were >intended for embedded systems. If you don't believe Mr. Sommarskog, check the Aug 1 88 issue of Govt. Computer News, page 36 "NASA Contractor Finds Ada, UNIX Don't Mix Well". >Probably, with today's computers you >have to resort to the target systems own process handling if you >want to write a fast multi-tasking application in Ada for a system >like Unix or VMS. Not really satisfactory. but what other options >does other langauges offer you? The readers of this group all know the answer to this one and I won't repeat it. The funny thing is, Ada was INTENDED to be the one language which could run on EVERY computer, from embedded system to mainframe, and handle ALL applications; part of the idea was that the same programmers could always go from project A (tank guns) to project B (DBMS system) with no retraining. If Ada CAN'T run intelligently or well on the most common machines which we'll all be living with for the next 15 years (UNIX systems and PC's), then it's obviously failed to meet its primary design objective. What I've been trying to point out is that C++ CAN meet that spec. C++ actually IS the language Ada was supposed to be and never will be, the main language which DOD (and a lot of other organizations) need. Ted Holden HTE
loren@thumper.uucp (Loren S. Rosen) (11/30/88)
I don't want to get dragged too deeply into a debate about the merits of Ada versus C++, but since Rational has been mentioned I thought a few corrections were in order. In article <197@imspw6.UUCP> bob@imspw6.UUCP (Bob Burch) writes: > >From Ted Holden, HTE: > >The only thing I could imagine compiling Ada that fast would be a >Rational (for the uninformed, an $800,000 Ada Software Development work >station). Ever wonder why you don't need $800,000 software development >workstations for C or C++? True, a Rational R1000 can cost $800,000 in some configurations. So can a Vax. A R1000 is not what people usually mean by the term 'workstation': it's a large multiuser system. (In the $800k configuration it has 32 megabytes of memory, and 2 gigabytes of disk, for example). The cost per user is pretty comparable to that of a similarly equipped Vax. >Don't worry, it's only the taxpayers' money. Fact is, R1000's are being used, not just on Government projects where use of Ada has been mandated, but on a number of commercial, scientific, and engineering applications. Nobody forced Ada on these people-- they chose it themselves. >...despite the fact that Ada has been out since 1979, Experts >are just now getting one or two compilers to perform close to acceptably >on today's VAX, 68000 etc. machines... Several acceptable compilers have been around for 2-4 years now. >What about tomorrow's machines, >88000 and SPARK based? Figure they'll have Ada compilers for them by >1999? The answer is undoubtably yes. The big time cost in getting good Ada compilers has already been paid. Now a new target means a new back-end, which, while a non-trivial task, should take less than ten years to develop. I would expect to see several compilers for the 88000 and SPARC appear in the next two years or so. >The funny thing is, Ada was INTENDED to be the one language >which could run on EVERY computer, from embedded system to mainframe, and >handle ALL applications; part of the idea was that the same programmers >could always go from project A (tank guns) to project B (DBMS system) >with no retraining. Ada was primarily designed for use in embedded systems. It so happens that the goals of large embedded systems design are similar enough to those of other large systems that the language is useful for other applications. I think the expectation is that programmers can go from one project (tank guns) to another similar project (airplane guns) with relatively little retraining (or from one DBMS system to another). There are other hurdles in getting from tank guns to DBMS systems than the language(s) in use. -- Loren Rosen Rational 3320 Scott Blvd Santa Clara CA. 95054 (408) 496-3600 internet: loren@rational.com usenet: uunet!igor!loren
sommar@enea.se (Erland Sommarskog) (12/01/88)
Once again Ted Holden, HTE uses Bob Burch's account (bob@imspw6.UUCP): >>you talk (write) too much and you say too little. What is worse, you say that >>you do not know what you are talking about. > >Is this supposed to be an English sentence? I've never accused MYSELF of >not knowing what I'm talking about..... Well, we didn't say you were aware of it. >>Probably, with today's computers you >>have to resort to the target systems own process handling if you >>want to write a fast multi-tasking application in Ada for a system >>like Unix or VMS. Not really satisfactory. but what other options >>does other langauges offer you? > >The readers of this group all know the answer to this one and I won't >repeat it. The funny thing is, Ada was INTENDED to be the one language >which could run on EVERY computer, from embedded system to mainframe, and >handle ALL applications; Now what did I say? I said that you couldn't expect the real-time primitives in Ada to work very well with a time-sharing system. They work, in the sense you can still do multi-tasking, but unless your performance requirements are low, they are maybe not that useful. On the other hand, if you take your beloved C++ and rely on system calls, they may or may not be around when you move from your time-sharing box where you developed to the naked taget machine. So, if you thought you find a good point here, I have to disappoint you: Ada works very well on Unix and VMS for general applications. >What I've been trying to point out is that C++ CAN meet that spec. C++ >actually IS the language Ada was supposed to be and never will be, the >main language which DOD (and a lot of other organizations) need. (Hm, let's see. He intimated that Ada didn't work with Unix since its real-time primitives didn't work well with Unix. Since C++, as far as I know, doesn't have any real-time support at all, that language couldn't be useful either. Or?) Seriously I am not going to argue against the paragraph above. I know too little about C++ to do that. (And Mr. Holden knows little too about Ada to argue against that.) C++ may be a better langauge than Ada, what do I know. Certainly Ada has some drawbacks: * It *is* big and complex, which gives it the advantage of being very powerful. Remember that this is a langauge for *big* projects. But of course the complexity and the varities raise cause to uncertainty. * There is no dynamic binding. This was very unfortunately strongly forbidden in the original requirements. If the language designers had been permitted to design an object-oriented langauge from the start, the could have come up with something much cleaner. And compared to old languages like Pascal and C, I take Ada on day. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.se "Frequently, unexpected errors are entirely unpredictable" - Digital Equipment
rfg@nsc.nsc.com (Ron Guilmette) (12/04/88)
In article <197@imspw6.UUCP> bob@imspw6.UUCP (Bob Burch) writes: >C++ actually IS the language Ada was supposed to be and never will be, the >main language which DOD (and a lot of other organizations) need. I used to be a big Ada fan. Now I'm a big C++ fan. Nonetheless, I have to point out the error in the above statement. C++ *is not* the language Ada was supposed to be. Specifically, Ada is *standardized* while C++ is not (yet). That can be good and bad. Actually, this is probably the main reason that I now prefer C++ to Ada. Everything about Ada (in particular, the warts) was set in concrete long ago. In the case of C++, the language is still evolving and there is still time to prevent it from becomming another hoplessly ugly beast.
marti@ethz.UUCP (Robert Marti) (12/06/88)
In article <8252@nsc.nsc.com>, rfg@nsc.nsc.com (Ron Guilmette) writes: > [ C++ ] is still evolving and there is still time > to prevent it from becomming another hoplessly ugly beast. C++ certainly has its merits and it may be a very useful language for many purposes, but I don't think there is any danger of C++ _becomming_ a hoplessly ugly beast. (If you know what I mean ... ) -- Robert Marti Phone: +41 1 256 52 36 Institut fur Informatik ETH Zentrum CSNET/ARPA: marti%ifi.ethz.ch@relay.cs.net CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (11/26/89)
From pff@beach.cis.ufl.edu (Pablo Fernicola): > In IEEE Software, Vol.5 Num. 3 page 26, we read > "C++ has several advantages over Ada: ..." In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847) writes: > But unfortunately seems to be missing fundamental features > such as exceptions, generics, and concurrency... Exceptions: Dr. Stroustrup just made a proposal for doing exceptions in C++. It looks pretty good. Generics: Dr. Stroustrup made a proposal sometime last year on parametarized types. His exception handling paper uses the same syntax, so presumably he's reasonably comfortable with it. Concurrency: Most of the time, C++ programs (and programmers) should use the facilities of the target platform. Dr. Stroustrup has provided support for "tasks" in both "C with classes" and C++; the AT&T C++ Language System comes with a Task class. That's as close to standard as C++ comes these days. No, there's no direct support in the language (special syntax, etc.) for supporting concurrency, for the same reason there's no direct support for I/O: it's better done in a library. To summarize, C++ has the same support for exceptions and generics that Ada has for inheritance. (The Ada preprocessor you mention is a red herring for DOD contractors, unless you propose they submit the *output* of the preprocessor.) > Bill Wolfe, wtwolfe@hubcap.clemson.edu Paul S. R. Chisholm, AT&T Bell Laboratories att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.
mrb@sei.cmu.edu (Mario Barbacci) (04/10/91)
I would like to get pointers to studies contrasting Ada and C++ and perhaps other languages but at least these two. Does anybody know if there are any such comparisons? ------------------------------------------------------------------------ Mario R. Barbacci, internet: mrb@sei.cmu.edu uunet: ...!harvard!sei.cmu.edu!mrb Software Engineering Institute, CMU, Pittsburgh PA 15213, (412) 268-7704