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