eberard@ajpo.sei.cmu.edu (Edward Berard) (03/11/88)
Judy Bamberger at the Software Engineering Institute raises some important questions in her response to my earlier postings on the commercialization of Ada technology. Her main question is "why is [the introduction of] Ada such a big deal [when compared to the introduction of other technologies which have become "accepted" in the non-Department of Defense community]?" First, Ada technology is multi-faceted. If Ada was "just another programming language," then the best I could hope for would be that the Ada compiler vendors would greatly enhance their third party support programs. However, what about the rest (and much larger part) of Ada technology? Consider the Ada-related software engineering environment efforts (e.g., APSE, KAPSE, MAPSE, CAIS, DIANA, SDME, STARS, KIT, etc.). I have notice an increasing interest in Computer Aided Software Engineering (CASE) in the commercial sector during the past three years. Examining the efforts in both communities (Ada and commercial) shows that each has much to offer the other. I know that there has been some limited communication, but I know of no efforts to systematically inform each community of what the other is doing. (How many Ada technology related presentations have been made at the increasing number of CASE conferences? How many papers have been presented at Ada-related conferences comparing commercial CASE efforts with Ada CASE efforts?) Consider the work being done by the Software Engineering Institute (SEI). The mandate of the SEI is efficient software engineering technology transfer. I would like to assume that someone at the SEI is already examining various mechanisms for technology transfer which have worked in the commercial sector. Assuming that an increased commercial interest in Ada technology would improve and accelerate the introduction of modern software engineering technology, there seems to be some motivation for generating interest in Ada within the commercial sector. One of the larger obstacles to the acceptance of Ada technology (anywhere) is that it only solves a limited number of problems, specifically military problems. The SEI is also designing Ada and software engineering related curricula for colleges and universities. It is difficult to motivate educators and students who perceive a technology as having only limited applications (and military ones at that). The ASEET (Ada Software Engineering Education and Training) group must have similar problems. Consider the work being done by the various working groups in SIGAda and the rest of the Ada community. I feel that the commercial sector would be greatly interested in such the technology being examined by the run-time environment, development methodology, formal methods, and environment groups. In addition, the commercial community could make important contributions to these groups. The second point I wish to raise is that we have different expectations for technology today than we did even five years ago. For example, when I was giving seminars on structured analysis and structured design in the very early 1980s, I got few questions on automated tools. Today, automated tools for a methodology are a requirement. Some of the models and approaches for introducing technology that worked in the past will still work today. However, newer and different approaches should be considered. My final observation is one that there is a very large difference between creating a technology and making effective use of that technology. Some technologists mistakenly believe that if a technology is truly worthwhile, it will naturally gain acceptance. Others are fatalistic, believing that any kind of organized attempt to guide technology can have little or no effect. It seems so strange for there to be such elaborate mechanisms in place for such things as the validation of compilers, and yet few primitive mechanisms for establishing the technology in the commercial sector. I appreciate and understand the Ada Joint Program Office. I do not, however, think it is their function to establish third party programs, advertise in trade journals, conduct conferences, or otherwise actively promote Ada technology outside of the U.S. Defense community. This is the job of the private sector, and we do not have to leave it to chance. -- Ed Berard (301) 695-6960
djs@actnyc.UUCP (Dave Seward) (03/13/88)
In article <330@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: >Judy Bamberger at the Software Engineering Institute raises some >important questions ... "why is [the >introduction of] Ada such a big deal [when compared to the... > >One of the larger obstacles to the acceptance of Ada technology >(anywhere) is that it only solves a limited number of problems, >specifically military problems. > I have heard this before, and not understood it then either. What about Ada makes it inappropriate for, for example, compilers, assemblers, linkers, other text processing applications (such as those I use it for). What makes it inappropriate for a national banking network, such as was done in Finland in Ada. I can think of problem domains in which is unwieldy or useless, but I hardly think they constitute the majority of nonmilitary applications. When the narrow domain view is taken, it is easy to justify the requirement for a big push for acceptance, but when one sees wide ranging applications, one is more likely to wonder what the big deal is. Ada for comercial uses is much more popular in Europe, but then so was Algol. US companies prefered to stick with COBOL and FORTRAN. A large job done properly in Ada will not see production of code until late in the game, relative to what many people are accustomed. This ought to be the case in any language, as the same benefits would accrue, but the rules of Ada virtually require it. Many people are unwilling to accept this, and I think it is more a style of management than the whims of programmers. As Ada is not well suited to use without the underlying model of Software Engineering, it will not play in Peoria until the underlying model is accepted. This, in my opinion, is what the big deal is. Dave Seward uucp.actnyc.djs
wes@obie.UUCP (Barnacle Wes) (03/18/88)
In article <728@actnyc.UUCP>, djs@actnyc.UUCP (Dave Seward) writes: > In article <330@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: > >One of the larger obstacles to the acceptance of Ada technology > >(anywhere) is that it only solves a limited number of problems, > >specifically military problems. > > > I have heard this before, and not understood it then either. What about Ada > makes it inappropriate for, for example, compilers, assemblers, linkers, other > text processing applications (such as those I use it for). What makes it > inappropriate for a national banking network, such as was done in Finland in > Ada. [much deleted] > As Ada is not well suited > to use without the underlying model of Software Engineering, it will > not play in Peoria until the underlying model is accepted. This, in my > opinion, is what the big deal is. There isn't really anything about Ada that makes it inappropriate for writing compilers, assemblers, linkers, etc.; it has been used for this. The NYU Ada compiler, and Ada system compiled itself I believe. The real kicker about Ada is that is was *not* designed to be a general-purpose language! There is a common misconception that the DoD looks on Ada as a programming language for all purposes; they do not. Ada was created as a language that would be suitable for developing imbedded command, control, and communications (C^3) systems. C^3 systems share some features with banking systems (distributed processing, and in some systems, the concept of an "atomic" transaction, the transaction is not completed unless the ENTIRE transaction can be completed. C^3 systems also share many "text-processing" features with compilers, linkers, etc. Indeed, a targeting program for an ICBM is basically a "target set compiler" is it not? But Ada was still CREATED with the idea of using it to develope imbedded C^3 systems. This really shows in some areas, like the limited I/O system - most imbedded systems talk to really STRANGE I/O devices via specially-built interfaces, not to terminals and VMS disk systems. With a run-time library that interfaces to the host system well, Ada can be used to do anything. It's rather like a more powerful version of pascal, or perhaps a verbose C with strong typing (strong typing is for weak minds!). I'm not convinced writing an accounting system in Ada is a good idea, but I wouldn't necessarily want to do it in C either :-). Wes Peters -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
djs@actnyc.UUCP (Dave Seward) (03/29/88)
In article <73@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >The real kicker about Ada is that is was *not* designed to be a >general-purpose language! > >There is a common misconception that the DoD looks on Ada as a >programming language for all purposes; they do not. Ada was created >as a language that would be suitable for developing imbedded command, >control, and communications (C^3) systems. > While I won't argue with the claimed intent of the DoD, I point out that the DoD itself did not design Ada, rather it put out a spec, and then approved the submitted language. IMHO Ada *was* designed as a general purpose language, with specific real time capabilities worked in. THIS IS MY OPINION ONLY, I have no inside information to substantiate it. Dave Seward uucp!actnyc!djs