biesack@falstaff.steinmetz (david j biesack) (02/04/88)
We're interested in the problem of converting Ada code to C.
If anyone knows of any references, please send me mail; I can
post a summary if there's something to summarize.
Specifically, I'm looking at information about implementing Ada features
in C code, such as nested subprograms, dope vectors, exception handling,
etc. I'm not worried about the parsing aspect - assume I'm already
working with an abstract Ada syntax tree.
Things like this *must* have been done before... I'd welcome info
on translating other languages (Pascal, Modula) to C as well.
I've heard that some compiler companies started their implementations
by generating C code as an intermediate step - references to such work
would be GREATLY appreciated.
Thanks;
djb
ARPA: biesack@ge-crd.arpa
Dave J. Biesack UUCP: {uunet|rochester|philabc}steinmetz!desdemona!biesack
Phone: (518) 387-6847conway@hplb29a.HPL.HP.COM (Daniel F. Conway) (02/05/88)
> We're interested in the problem of converting Ada code to C. The Irvine Compiler Corporation Ada compiler system does just this. It consists of an Ada front-end which translates Ada to C. The result is then compiiled and linked on the target computer. Their address is: The Irvine Compiler Corporation 18021 Sky Park Circle, Suite L Irvine CA 92714 (714) 250-1366 > Things like this *must* have been done before... I'd welcome info > on translating other languages (Pascal, Modula) to C as well. A Pascal to C translator was posted to the net several months ago. > Dave J. Biesack UUCP: {uunet|rochester|philabc}steinmetz!desdemona!biesack > Phone: (518) 387-6847 Dan Conway Hewlett-Packard 3172 Porter Drive, Bldg. 29A Palo Alto, CA 94304 hplabs!dan_conway
stt@ada-uts (02/05/88)
Irvine Computer Corporation (address unknown) is the company which started out with an Ada to C translator. I don't know whether the translator was ever validated, but I do know that ICC has validated some number of Ada compilers. (They are presumably located in Irvine, CA)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/16/89)
From article <14033@grebyn.com>, by ted@grebyn.com (Ted Holden): > Journal articles indicate a continuing failure of Ada to work for embedded > systems as well as for large scale projects, a continuing failure to run > with acceptable performance on anything other than parallel or special- > purpose, expensive systems, and an actual gain in cross-system complexity > and decrease in the stated goal of reuseability. This is blatantly false; consider the November 1988 article in IEEE Software ("Large Ada projects show productivity gains"): After years of development and an initial skeptical reception, many people are now using Ada and saying that they like it... The growth in Ada's use has been helped by favorable reports from early adopters ("Ada Catches on in the Commercial Market, Soft News, IEEE Software, November 1986, p. 81) and by the growing number of validated compilers... project results show that Ada can greatly increase productivity for large systems... [in a 1.2-million-line Ada project] reuseable software developed on the project was counted only once. Roughly 13 percent of the delivered software was reuseable. This reuse saved 190 man-months of effort (a 9-percent savings) and reduced the schedule by two calender months (a 4-percent savings)... Productivity for the execution environment -- including the operating system, data management, information management, communications support, and communications interface -- was 550 lines per man-month... Productivity for the applications software... was 704 lines per man-month... the average productivity of the 1,500 systems in productivity consultant Lawrence Putnam's database: 77 lines per man-month (at the 1.2-million-line level)... Sounds like a continuing *success* to me... > In particular, the > ordinary systems which most people will be seeing in front of them for the > next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably. Precisely the point of Dr. Charles McKay, head of the Software Engineering Research Consortium, in his Tri-Ada '88 presentation, "Standards for the Sake of Standards -- A Recipe for Failure". A prime example is Unix; the current POSIX effort aims to standardize 1960's technology, thus resulting in a "lowest common denominator" which locks users into obsolescence. Ada's problem with Unix is that Unix, being 1960's technology, does not properly support lightweight processes. Modernized versions of Unix (e.g., MACH) which are designed to provide such support remove the difficulty. Note that C or C++ programs making use of the same "heavyweight" tasking facility will be equally slow, since they rely on precisely the same system. If one does not have to struggle with the limitations of *Unix*, then there is a wide selection of Ada compilers which run Ada within that environment quite nicely. Some, like the Telesoft TeleGen2 compiler, have global optimization facilities which result in better code than that which can be produced by current C compilers (as of Tri-Ada '88). > C began with real machines, real programmers. The idea seems to have > been: [...] end up with a kind of high-structured, low-level language; > a thinking-man's assembler. Yes, as one Usenetter's .signature states, "C combines the power of assembly language with the flexibility of assembly language". Fortunately, the economics of software development are in favor of using considerably higher-level languages. > C++ appears to BE the very language which Ada was supposed to be > (the spirit of the law) but never can and never will be. Total rubbish; C++ retains all the low-level and dangerous facilities of C, which is obsolescent by modern software engineering standards. As stated by Fairley (Software Engineering Concepts, page 228), Modern programming languages provide a variety of features to support development and maintenance of software products. These features include strong type checking, separate compilation, user-defined data types, data encapsulation, data abstraction, generics, flexible scope rules, user-defined exception handling, and concurrency mechanisms. This chapter discusses these concepts... Now C++ has one useful feature which Ada does not: inheritance. But it is also (as its designer freely admits) lacking in generics and exception handling, and also does not provide a means of expressing concurrency in a standardized, portable way. Since tools such as Classic Ada permit the use of inheritance with Ada (generating *standardized*, compile-it-anywhere code), this is something which can be worked around until Ada 9X brings it in directly. > Ada is what you might expect from a programming language designed by > committee; it is unbelievably slow, an unbelievable resource hog, This has been a property of some early Ada *compilers*, but is not a property of the Ada *language*. Fortunately, compiler technology is now capable of delivering tight, efficient Ada object code, better than that being produced by C compilers. Compilation is slower because the Ada compiler is doing much more work for you; this reflects again the economics of software development in that machine time is cheaper than programmer time. > [...] There is the August 21 89 issue of Government Computer News > describing the problems which the huge FAA Advanced Automation System is > having due to IBM Ada implementations and tools (or lack thereof). Are you saying that this is the fault of the *language*, or of IBM? > There is no real way to call [Ada] from a Cobol program. Ada users can call COBOL or any other language using pragma INTERFACE; COBOL needs to have a similar standardized means of calling other languages. Given that it does not, ad hoc means of calling other languages have been devised; there is no reason why such techniques cannot be used to call Ada just as well as C or any other language. But this is COBOL's problem, not Ada's. > the programming style being promulgated by DOD for Ada [descriptive > variable names] is anti-conducive to the stated goal of readability; To C hackers, who are accustomed to single-letter variables, yes. Software engineering specialists tend to have the opposite perspective. > Second, DOD is often insisting on portability via Ada rather than > portability via UNIX, POSIX calls etc. This amounts to such things as > insisting, for instance, that vendors provide direct Ada hooks to a > database rather than simply writing an Ada -> C -> database hook. Typical > vendor response is either "F... You" or "Manana". And the response of the Ada community is to turn to companies such as The Ada Ace Group, Inc., a technical consulting company specializing in the development of Ada interface to software products and applications. They provide customized pure Ada interfaces to existing commercial software products, such as databases, operating systems, and specific applications such as X-Windows. (Contact information: 4254 Indigo Drive, San Jose, CA 95136; (408) 267-8296) Do you really think the Ada community, with its emphasis on standardization and vendor independence, is going to be stopped by an intransigent vendor? > A military project involving Sun machines and Ada was abandoned after > something like 4 years and $30 million effort because of unacceptable > performance; database screens were taking over a minute to come up. The > design work had all been done according to your formula, the individual > modules had been designed, written, and tested, all according to the > standard military schedules and formulas (2167 etc.). Everything seemed > hunky dory, only when they put the fricking thing together, it was too > damned slow to use. And, the remarkable thing is, the very system the > military insists upon for management of software contracts prevented > anybody from knowing they were in trouble until four years and millions > had been blown. The government people involved were essentially reduced > to the role of actors in a Greek tragedy. > > Asked for a solution, my firm weighed the choice between offering an Ada- > to-C converter and silence, and opted for silence. How about applying a profiler and recoding the "hot spots"? If the slowness of Unix process handling is a problem, then a more modern version of Unix should be used. Your company should have considered more than two options. There are problems in the government management process, but this pertains to the government and not to Ada. Bill Wolfe, wtwolfe@hubcap.clemson.edu
rowe@cme.nist.gov (Walter Rowe) (11/17/89)
Ignore that last one ... got trigger happy ... ---------------------------------------------------------------------- >>>>> On 15 Nov 89 16:06:41 GMT, billwolf@hubcap.clemson.edu (Bill Wolfe) said: billwolf> This is blatantly false; consider the November 1988 billwolf> article in IEEE Software ("Large Ada projects show billwolf> productivity gains"): billwolf> [...irrelevant text deleted...] billwolf> on the project was counted only once. Roughly 13 percent of billwolf> the delivered software was reuseable. Uhmmm ... correct me if I'm wrong here, but if a project is well designed (ie. module specs are written to be general), I think there would be a higher degree of re-usability for those modules, regardless of the language used. That's the purpose of writing generalized code. Any good computer scientist/programmer knows that, right? Imagine having to write sin(), cos(), etc, for every application you needed them for. This would of course be ludicrous, so those in the know wrote good, generic routines to handle these functions and now you take them for granted. What I'm trying to say is that re-usability is not necessarily an attribute of the programming language being used, but more likely it is the result of using good system design techniques. Who cares if its C++, Ada, C, or Pascal? If you approach the design correctly, your solution will be general enough so as to apply to the greatest number of variations of the same problem. Thats what re-usability is all about, isn't it? Not re-inventing the wheel? billwolf> Sounds like a continuing *success* to me ... Sure, but so is Pascal (originally designed as a learning tool), but its not highly used outside of Academia just like Ada is not highly used outside of DoD. Ever wonder why? billwolf> A prime example is Unix; the current POSIX effort aims to billwolf> standardize 1960's technology, thus resulting in a "lowest billwolf> common denominator" which locks users into obsolescence. I disagree. Its not locking into obsolescence. Its forcing one to meet only a minimum set of requirements, which allows a maximum amount of flexibility above and beyond those requirements. As long as you meet these minimum requirements, you still have the freedom to enhance UNIX any way you see fit. They aren't restricting you to these, but saying that you must provide at least these things. billwolf> Modern programming languages provide a variety of features billwolf> to support development and maintenance of software products. billwolf> These features include strong type checking, separate billwolf> compilation, user-defined data types, data encapsulation, billwolf> data abstraction, generics, flexible scope rules, billwolf> user-defined exception handling, and concurrency mechanisms. I have to agree with Bill on this point: more languages ARE beginning to evolve into useful tools for productivity, rather than learning tools, or tools intended for specific applications. However, I think in order to be most productive and efficient for a given application, a language still must cater to that application to some extent (ie. COBOL for record transaction processing, C for systems programming, etc). > [...] There is the August 21 89 issue of Government Computer News > describing the problems which the huge FAA Advanced Automation > System is having due to IBM Ada implementations and tools (or lack > thereof). billwolf> Are you saying that this is the fault of the *language*, or billwolf> of IBM? More than likely its IBM, although most of their projects seem to come out of a committee, and in that respect, draw a striking resemblance to Ada. So, possibly both are at fault since Ada was designed by a committee, too. I think the basic point being made is that too many hands in the pot spoil the soup, and I tend to agree with this. Its good to get outside opinions so that one can be as objective as possible, but I still think that fewer people can supply a much more rational decision. > the programming style being promulgated by DOD for Ada [descriptive > variable names] is anti-conducive to the stated goal of readability; billwolf> To C hackers, who are accustomed to single-letter variables, billwolf> yes. Software engineering specialists tend to have the billwolf> opposite perspective. Admittedly, I fall into the C hacker category, but I think Ted makes a valid point here. I'd much prefer to shuffle through a few pages of documentation at the top of a print-out than have to look at unsightly long variable/procedure/function names. I support giving variables meaningful names, just not unsightly long ones. If the docs are good at the top of a file are good (ie. they clearly and concisely convey the concept of what this code is suppposed to do), then you shouldn't have to clutter the code with paragraph long names. You're trying to infer the logic being applied, not the details of the individual statements (for alone they mean nothing anyway). billwolf> Bill Wolfe, wtwolfe@hubcap.clemson.edu Walter Rowe, rowe@cme.nist.gov --- My opinions are my own, and bare no reflection of the opinions of the United States Government.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/17/89)
From rowe@cme.nist.gov (Walter Rowe): > Sure, but so is Pascal (originally designed as a learning tool), but > its not highly used outside of Academia just like Ada is not highly > used outside of DoD. Ever wonder why? The fact that good production-quality compilers have only been avaliable for the last year or two probably has a lot to do with it... Fortunately, as the IEEE Software article I cited demonstrates, commercial use and acceptance of Ada is growing rapidly, both in the US and overseas. Non-DoD US users include General Electric, Boeing Commercial Airplane, etc.; other companies, such as Arthur Anderson, are considering converting to Ada now that the appropriate compilers and tools are available. Not because the DoD is using it, but as a simple result of business and engineering considerations. Considering that the largest corporation in the WORLD, Nippon Telegraph and Telephone, has maintained a committment to Ada since 1982 (!!!), I'd say that Ada is certainly making excellent progress in the commercial environment. The fact that the DoD is requiring all its information systems work to be done in Ada is creating a great deal of infrastructure (e.g., the RAPID library of reuseable Ada information systems software components), which will further stimulate commercial use. The experience so far has been that "once a team moved to Ada, they stayed with Ada. Once Ada had been successfully used within a company, its use proliferated to other projects within the company and to subcontractors and suppliers of that company within the industry." (Ada Letters, Vol. VIII, No. 5, page 15). Given that high-quality compilers have only been available for a relatively short period of time, and that the US Ada market was already US $1.25 billion as of September 1987, I think the progress so far has been quite substantial. Watch comp.lang.ada for continued updates. Bill Wolfe, wtwolfe@hubcap.clemson.edu
pff@beach.cis.ufl.edu (Pablo Fernicola) (11/18/89)
In article <7088@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > Fortunately, as the IEEE Software article I cited demonstrates, > commercial use and acceptance of Ada is growing rapidly, both in In IEEE Software, Vol.5 Num. 3 page 26, we read "C++ has several advantages over Ada: ..." > > The experience so far has been that "once a team moved to Ada, > they stayed with Ada. Once Ada had been successfully used within > a company, its use proliferated to other projects within the > company and to subcontractors and suppliers of that company within > the industry." (Ada Letters, Vol. VIII, No. 5, page 15). Given ^^^^^^^^^^^^ Not a biased opinion, I hope :-) A common syllogism nowadays is (from the same IEEE Software issue) Ada is good; object-oriented is good; therefore, Ada is object oriented. > Bill Wolfe, wtwolfe@hubcap.clemson.edu BTW, it is good to hear from Bill again after the misc.jobs.misc debacle ... -- pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF IF YOU CARE ENOUGH TO READ SIGNATURES ... I am graduating next year and I am looking for a job. MS/BS EE, my graduate work incorporates OO-DBMS/Graphics/Robotics/AI
marc@dumbcat.UUCP (Marco S Hyman) (11/18/89)
In article <7088@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
Non-DoD US users include General Electric,
Boeing Commercial Airplane, etc.; other companies, such as Arthur
Anderson, are considering converting to Ada now that the appropriate
compilers and tools are available. Not because the DoD is using it,
but as a simple result of business and engineering considerations.
Large corporations such ad GE, Boeing, Arthur Anderson, etc., are not known
for state-of-the-art, pushing-the-envelope solutions to their problems.
These are the companies that buy IBM. Ada is safe, approved by the
government, and, as I once heard Larry Rossler of the HP Language Labs
describe it, doomed to success. Too many companies are throwing money at it
to fail.
The experience so far has been that "once a team moved to Ada,
they stayed with Ada. Once Ada had been successfully used within
a company, its use proliferated to other projects within the
company and to subcontractors and suppliers of that company within
the industry." (Ada Letters, Vol. VIII, No. 5, page 15).
I don't have any facts or figures but I suspect from my own past experience
that this is true of every successful tool/method introduced to a large
corporation. A manager that tries something new usually goes out on a limb
and therefore works twice as hard to make it succeed. When it does succeed
that manager makes sure all of his bosses know that he was the hero that
finally brought a software project in on time and within budget. Since
software projects are not usually on time or within budget the new
tool/method is seen as the solution to all software woes. Alas, it's
usually just better management plus the productivity increase that comes
with doing something new that really saved the day.
I'm not saying the new tool/method, be it Ada, C++, OOP, or whatever, does
not help. I just wish that it wasn't seen as a panacea for all that ails
the current problems in software. (BTW: the current problems in software
haven't changed, IMHO, in the last 20 years -- there's just a lot more
software.) But I've changed the subject. Sorry.
C++ and Ada are just tools, folks. Sometimes they are the correct
tool for the job. Sometimes they are not.
// marc
--
// Marco S. Hyman {ames,pyramid,sun}!pacbell!dumbcat!marcbillwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/19/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: ..." But unfortunately seems to be missing fundamental features such as exceptions, generics, and concurrency... > A common syllogism nowadays is (from the same IEEE Software issue) > > Ada is good; object-oriented is good; > therefore, Ada is object oriented. Written by the designer of C++, whose definition of object-oriented is "Object-oriented programming is programming using inheritance". The definition of "object-oriented" varies widely, but even if we accept this definition, we need only obtain Classic Ada (or some equivalent preprocessing product) in order to use inheritance in an Ada environment, pending more direct support in Ada 9X. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/20/89)
From ted@grebyn.com (Ted Holden): >> Total rubbish; C++ retains all the low-level and dangerous >> facilities of C, which is obsolescent by modern software >> engineering standards. As stated by Fairley (Software > > Those features are there because they are necessary for real world > programming. Would you care to try to prove this, for the benefit of those of us who could really use a few good laughs? (But do us a favor and read a few SOFTWARE ENGINEERING texts before you try, so we won't have to waste too much effort giving you references...) >>> There is no real way to call [Ada] from a Cobol program. > >> Ada users can call COBOL or any other language using pragma >> INTERFACE; COBOL needs to have a similar standardized means >> of calling other languages. Given that it does not, ad hoc >> means of calling other languages have been devised; there is >> no reason why such techniques cannot be used to call Ada just >> as well as C or any other language. But this is COBOL's problem, >> not Ada's. > > Dead wrong. This is a grey area, but Ada tasking basically requires > that the starting point be an Ada program i.e. predictable results/full > Ada functionality are not possible from an Ada module called from a > routine written in another language. The requirements to link > low-level kinds of routines into Cobol programs are very real. Every > Ada manual I've seen says that results from such code are unpredictable. Is this the Ada Reference Manual (and thus pertaining to Ada), or specific manuals for specific compilers? If the latter, then this may be a property of particular compilers, but is NOT an inherent property of Ada. Thus, it becomes the user's responsibility to find a vendor which will provide a compiler which will satisfy the user's requirements relative to SOME OTHER LANGUAGE in addition to the requirements of the Ada LRM. > First, the problem with performance didn't involve UNIX. Second, to my > knowledge, the vender only offers the one version for the machine. > Again, the customer was not John Rockafeller. Oh, I see. It is somehow Ada's fault that compilers are not available for pennies (if that) which will do everything imaginable on all possible machines, particularly when management failed to do a good job of compiler evaluation before starting the project and now needs to find a better compiler than the one MANAGEMENT selected in order to save the project. C'mon, Ted, admit it!!! You're trying to blame Ada for everything under the sun, REGARDLESS of whose fault it really was. Get a life... > The obvious implication is that these other machines, which are quite > powerful, yet lack the capability for serious Ada development. Why is > that? IBM, DEC, and Sun computers can easily be used to develope > software in C, Fortran, Pascal, C++, Cobol... And Ada. Rational offers a very powerful CASE environment which far surpasses anything being used by the C, Fortran, Pascal, etc. crowd. One major reason for this is that users of those languages generally operate as programmers, whereas Ada users generally operate as software engineers. This results in Ada users having much higher standards, both for their language and for their CASE environments. Competition is arising for Rational in the form of the TeleArcs CASE environment for the Suns and VAXen; given Telesoft's association with IBM, it will probably soon be available there as well. And of course there are other vendors playing the game as well. So although Ada software has long been developed on all of the above platforms without advanced CASE environments, that era is quickly departing. % Aside from myself, who is saying that the end is near for Ada? % Possibly, a certain Mr. Gorbachov in the CCCP, who is basically % declaring the cold war to be over, and a Mr. Cheney in Washington D.C. % who is talking about cutting 180 Billion from the U.S. defense budget % over the next five years (Wash. Post, A1, Nov 18, 89). Anybody care to % bet that Ada doesn't become one of the first casualties of all this? Yep. % The last figures I've read indicated that 65 percent of all % software development in this world was being done in C, and the next % highest figure for any other language was around six percent. Are % Borland, MicroSoft, Lotus, Ashton-Tate, WordPerfect, and all of % those companies just that stupid? Considering the number of articles I've read recently in the Wall Street Journal about the software crisis at Microsoft, et al., this would seem to be a rather reasonable conclusion. Bill Wolfe, wtwolfe@hubcap.clemson.edu
ark@alice.UUCP (Andrew Koenig) (11/21/89)
In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > Written by the designer of C++, whose definition of object-oriented > is "Object-oriented programming is programming using inheritance". Where on earth did you pick up that notion? -- --Andrew Koenig ark@europa.att.com
matsl@nada.kth.se (Mats Luthman) (11/22/89)
In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > Written by the designer of C++, whose definition of object-oriented > is "Object-oriented programming is programming using inheritance". As far as I recall Bjarne Stroustrup supports the widely accepted definition of "Object oriented language": A language that supports: * Data abstraction (encapsulation) * Inheritance * Dynamic binding I guess that people who claim that Ada is object oriented don't agree with this definition, at least not with the third requirement, but saying what I cited above is (and was probably meant to be) an insult to B.S. and his intellectual capability. Mats Luthman
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (11/23/89)
From ark@alice.UUCP (Andrew Koenig): > billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >> Written by the designer of C++, whose definition of object-oriented >> is "Object-oriented programming is programming using inheritance". > > Where on earth did you pick up that notion? From his article "What is Object-Oriented Programming", IEEE Software, May 1988... it's a direct quote. Bill Wolfe, wtwolfe@hubcap.clemson.edu
sakkinen@tukki.jyu.fi (Markku Sakkinen) (11/23/89)
In article <10171@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: -In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: - -> Written by the designer of C++, whose definition of object-oriented -> is "Object-oriented programming is programming using inheritance". - -Where on earth did you pick up that notion? I would say that is the main theme of Stroustrup's paper from ECOOP'87 (What is "Object-Oriented Programming), a little simplified. So, where on earth = in Paris (site of ECOOP'87) :-) Obviously, it is hard to maintain that languages such as Ada and CLU are not "object-oriented" in the least, unless one takes inheritance as the single most important concept of OO. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
matsl@nada.kth.se (Mats Luthman) (11/23/89)
In article <7171@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From ark@alice.UUCP (Andrew Koenig): >> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >>> Written by the designer of C++, whose definition of object-oriented >>> is "Object-oriented programming is programming using inheritance". >> >> Where on earth did you pick up that notion? > > From his article "What is Object-Oriented Programming", IEEE > Software, May 1988... it's a direct quote. > > > Bill Wolfe, wtwolfe@hubcap.clemson.edu The article is 21 pages long, and is a thorough explanation of what the author means by 'object oriented programming'. The trick of chosing one sentence, ripped out of its context, is used again. Mats Luthman ***
AMXMC-SEL@WSMR-SIMTEL20.ARMY.MIL (Mark Oestmann) (01/19/90)
> Date: 17 Jan 90 18:49:41 GMT > From: zaphod.mps.ohio-state.edu!uwm.edu!srcsip!falcon!ostlund@tut.cis.ohio-state.edu (John Ostlund) > Subject: ADA compilers > Message-ID: <54198@srcsip.UUCP> > > Anyone know of any ADA compilers for a PC and/or SUN workstations??? > > (any ADA interpreters available?) > > Please reply to: OSTLUND@SRC.Honeywell.com > > Thanks in advance, John. I imagine that you have received a bundle of mail in reference to your message. If you are interested in staying abreast of validated Ada compilers, I would suggest subscribing to the "Ada Information Clearinghouse Newsletter" AdaIC c/o IIT Research Institute 4600 Forbes Blvd,. Second Floor Lanham, MD 20706-4312 This newsletter is also available online from the Ada Software Repository (ASR). The following info was extracted from the September 1989 issue of the Ada IC Newsletter: AETECH (PC compilers) IntegrAda compiler David Dewitt 619/755-1277 Alsys (PC and Sun compilers) Lee Ehrlichman 617/270-0030 DDC-I, Inc, (PC and Sun compilers) Mike Turner 602/944-1883 GEC Software Ltd (Sun compiler) now Marconi Software David Howells +44 1 953 2030 IBM Corporation (RT PC compiler) Anna Dahan 416/448-2649 Meridian Software (PC and Sun Compilers) Eric Olsen 800/221-2522 714/380-9800 New York University (Sun interpreter(?)) Bernard Banner 212/998-3480 R.R. Software, Inc. (PC Compilers) JANUS/Ada Paul Fuller 608/244-6436 Tartan Laboratories Incorporated (Sun Compiler) Susan Englert 412/856-3600 Telesoft (Sun Compilers) Tom Dent or Karen Johnson 619/457-2700 Verdix Software Engineering Limited (Sun Compilers) Paul Moskowitz 703/378-7600 Any errors or omissions are inadvertent. Mark Oestmann School of Engineering and Logistics Red River Army Depot Texarkana, TX 75507-5000 moestmann@simtel20.army.mil -------
jj@cup.porthole.com (jj) (03/09/90)
PLEASE YOU WILL PARDON ME BECAUSE I AM A NEW USER AND THIS IS MY FIRST POST. FROM WHAT I HAVE READ IN THIS BBS IF YOU USE ADA YOUR PROGRAMS WILL NOT HAVE ANY BUGS. I THINK THAT WOULD BE A VERY GOOD THING. I THINK EVERYONE SHOULD USE ADA SO THEIR WILL NOT BE ANY MORE BUGS. PLEASE TELL ME HOW TO GET ADA FOR MY RADIO SHACK COLOR COMPUTER (I USED IT AS A TERMINAL TO TYPE THIS IN).
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/12/90)
From article <19452@grebyn.com>, by ted@grebyn.com (Ted Holden): > Object-oriented programming is the only thing which could possibly > help some of the giant projects which are now mandated to be done > in Ada. Ada doesn't have it now. Ada probably won't have it with > the 9x version, which will likely include mostly fixes for some of > the present bugs and woes, and given the speed of the process > involved, the 9x standard will probably be out in about a year, a > first compiler in four years, and first near-reasonable compilers > in seven or ten years. This probably says 14+ years for object- > oriented Ada. Regrettably for Mr. Holden, object-oriented Ada is available right now. Software Productivity Solutions has a product called Classic Ada which serves as a Smalltalk-based object-oriented preprocessor for Ada-language software developers. Another object-oriented approach along the lines of Zetalisp's Flavors (InnovAda) will soon be on the market as well. But Ted Holden will never let reality interfere with his point of view, as he has so repeatedly demonstrated. > Ada "gurus" are constantly talking about the advantage of Ada for > team projects, but here Sommerville/Morrison are making the point > that the do-everything language is so complex that the only team > likely to succeed at doing anything at all with it is the local > chapter of Mensa. Well, Ted, if you aren't bright enough to handle Ada, I suggest that you stay away from it. However, you should keep in mind that STANFINS-R has recently demonstrated that even COBOL programmers can be turned into effective Ada software engineers. Perhaps you should therefore see to it that you refrain from using any language more sophisticated than COBOL! Bill Wolfe, wtwolfe@hubcap.clemson.edu
tyler@procase.UUCP (William B. Tyler) (03/16/90)
In article <8322@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > Regrettably for Mr. Holden, object-oriented Ada is available right > now. Software Productivity Solutions has a product called Classic > Ada which serves as a Smalltalk-based object-oriented preprocessor > for Ada-language software developers. Another object-oriented approach > along the lines of Zetalisp's Flavors (InnovAda) will soon be on the > market as well. But Ted Holden will never let reality interfere with > his point of view, as he has so repeatedly demonstrated. > Wolfe's response serves to reinforce Holden's point. Ada, the language, has no capability for object oriented programming. Use of these extensions amounts to use of a different language, especially since Ada admits no extensions by definition. > Well, Ted, if you aren't bright enough to handle Ada, I suggest that > you stay away from it. This seems to be an admission that Ada has failed in a very important area of language design. If it requires brilliance for proper use, it is certainly inappropriate as a vehicle for implementing large projects with many programmers, some at least of whom will be of average intelligence. Why don't you give it a rest, Wolfie? At least try keeping out of the C newsgroup. -- Bill Tyler ...(tolerant|hpda)!procase!tyler
oconnordm@CRD.GE.COM (Dennis M. O'Connor) (03/16/90)
"[...*...]" below means I've deleted something I consider an ad-hominem, that IMHO added nothing constructive to the conversation. My apologies if I offend anyone. tyler@procase (William B. Tyler) writes: ] In article <...> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: ] > [...*...] ] > Software Productivity Solutions has a product called Classic Ada ] > which serves as a Smalltalk-based object-oriented preprocessor ] > for Ada-language software developers. Another object-oriented approach ] > along the lines of Zetalisp's Flavors (InnovAda) will soon be on the ] > market as well. ] > [...*...] ] ] [...*...] Ada ... has no capability for object oriented programming. My understanding is that "support for OOP" is not a YES-NO question. IMHO, Ada does support objects, if not OOP : does not a package represent a passive object, and a task represent an active one ? Doesn't a "task type" has all the characteristics of a class (and even more) ? What Ada doesn't support is inheritance. So, Ada's support for OOP is limited, not non-existant. It's support for Object-Oriented Design (OOD) is a different issue. ] Use of these extensions amounts to use of a different language, especially ] since Ada admits no extensions by definition. However, if you believe that the primary benefit of OOP is found in the design stage (OOD), then using something like Classic Ada for design, and then automatically translating it into Ada (which is, I believe, how these products work) is probably an option even in an "Ada-only" project. (Any DoD project participants care to comment ?) It is certainly an option for those who use Ada because they like the features of the language, not because of a DoD mandate. Yes, such people exist. ;-) ] > [...*...] if you aren't bright enough to handle Ada, I suggest that ] > you stay away from it. ] ] This seems to be an admission that Ada has failed in a very important ] area of language design. If it requires brilliance for proper use, ] it is certainly inappropriate as a vehicle for implementing large ] projects with many programmers, some at least of whom will be of ] average intelligence. What is this "you gotta be smart to use Ada" stuff anyway ? Let's face it : if you are using the complex features of any language, it should be because the design is complex, not because of the the language you are implementing in. And if the design is complex, you'd better be smart no matter what language you use. If a language forces you to implement a simple design in a complex way, I`d say it's flawed. Feel free to point out such flaws in Ada to the Ada-9X commitee, please ! In a large project with programmers of varying degrees of talent, "average" (yuck I hate that word) programmers should be assigned tasks of "average" difficulty, and the tough stuff should be done by the most talented people. This, like many other issues, is language-independant. It has to be admitted, of course, that many languages wind up associated with a particular design methodology and project management philosophy. But "correlation is not causation", eh ? ] Why don't you give it a rest [...] try keeping out of the C newsgroup. I don't really understand the emnity between some of the C and Ada proponents. Why the emotions ? What are people afraid of ? So one or both languages doesn't take over the world, so what ? Eventually (I hope) both will be obsolete in their present forms. Hopefully, both can learn form each other, and evolve into something better. Nobody should mind constructive criticism, eh ? -- Dennis O'Connor OCONNORDM@CRD.GE.COM UUNET!CRD.GE.COM!OCONNOR "Let's take a little off the top ... a bit off the sides ... trim the back a bit ... Surprise ! You've been bald-ed !"