* "Forced to Use Ada" @ 1989-02-22 10:56 Edward Berard 1989-02-27 23:28 ` Bob Hathaway 0 siblings, 1 reply; 16+ messages in thread From: Edward Berard @ 1989-02-22 10:56 UTC (permalink / raw) Occasionally, there are postings to various news groups about how awful it is that many people are forced to use Ada. I think that some of these posters would be surprised to know that a majority of Ada users worldwide use Ada because they want to, not because of any mandate. For example, in Europe much more than 50% of the money spent on Ada software is spent by those who have no mandate to use Ada, i.e., they are free to use any technology they wish. Here, in the U.S., I have a significant number of clients who use Ada by choice. Further, they have no connection with the government -- direct or indirect. Some of these clients are implementing real-time systems, others are creating large number-crunching applications, and still others are doing classic business applications. (I have several stories about how these people were able to sell Ada technology internally on its own merits.) Often, commercial users of Ada technology do not come to Ada meetings, or they may come only occasionally. Several, are forbidden by their management to inform the world of their Ada efforts because management does not want the competition to know what is happening. One of the more prominent myths about technology is that if a technology is truly worthwhile that it will be automatically recognized as such, and that users will flock to it in droves. Tell that to Galileo who was threatened because he said the earth revolved around the sun, or to Pasteur and Lister who suggested that infections were the result of ``invisible'' organisms, and had to fight for acceptance. Yes, it is unfortunate that the U.S. Department of Defense had to mandate a technology. However, that does not mean that the mandated technology is without merit. [On another note: Have you noticed how many vendors of Ada technology are totally incapable of selling their technology to anyone who does not have the a gun (i.e., a DoD mandate) held to their head? It is just possible that the technology can stand on its own merits.] -- Ed Berard (301) 695-6960 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-02-22 10:56 "Forced to Use Ada" Edward Berard @ 1989-02-27 23:28 ` Bob Hathaway 1989-03-01 23:49 ` A. Jeff Offutt 0 siblings, 1 reply; 16+ messages in thread From: Bob Hathaway @ 1989-02-27 23:28 UTC (permalink / raw) In article <470@ajpo.sei.cmu.edu>, eberard@ajpo.sei.cmu.edu (Edward Berard) writes: >of these posters would be surprised to know that a majority of Ada >users worldwide use Ada because they want to, not because of any >mandate. For example, in Europe much more than 50% of the money spent >on Ada software is spent by those who have no mandate to use Ada, >i.e., they are free to use any technology they wish. > I decided Ada was the best language after independently studying programming for some time in school. I had to use C and Pascal in coursework and after some asking, Modula-2. So, I was mandated to use alternative languages although I strongly desired and asked to program in Ada. I'm glad to see someone (the government) advocating modern programming languages along with software engineering; the more support the better. Bob Hathaway rjh@purdue.edu ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-02-27 23:28 ` Bob Hathaway @ 1989-03-01 23:49 ` A. Jeff Offutt 1989-03-02 20:04 ` Bob Hathaway 1989-03-09 5:36 ` Harry S. Delugach 0 siblings, 2 replies; 16+ messages in thread From: A. Jeff Offutt @ 1989-03-01 23:49 UTC (permalink / raw) From article <6125@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway): > ... I'm glad to see someone (the government) advocating modern > programming languages along with software engineering; the more support > the better. C'mon, be careful what you say. As a scientist/engineer, I do not want anybody *mandating* the use of technology without clear *technical* proof that that is in every case the best solution. Whether you are an Ada fan, a Modula-II fan, a C fan or even open-minded, it is very clear that the scientific community is not convinced that Ada (or any language) is the best technology for all applications. Or for any application. -- Jeff Offutt Department of CS, Clemson University, Clemson SC (803) 656-5866 Internet: ofut@hubcap.clemson.edu ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-03-01 23:49 ` A. Jeff Offutt @ 1989-03-02 20:04 ` Bob Hathaway 1989-03-03 17:21 ` Paul Raveling 1989-03-09 5:36 ` Harry S. Delugach 1 sibling, 1 reply; 16+ messages in thread From: Bob Hathaway @ 1989-03-02 20:04 UTC (permalink / raw) In article <4624@hubcap.UUCP>, ofut@hubcap.UUCP (A. Jeff Offutt) writes: > From article <6125@medusa.cs.purdue.edu>, by rjh@cs.purdue.EDU (Bob Hathaway): > > ... I'm glad to see someone (the government) advocating modern > > programming languages along with software engineering; the more support > > the better. > > C'mon, be careful what you say. As a scientist/engineer, I do not want > anybody *mandating* the use of technology without clear *technical* proof > that that is in every case the best solution. > > Whether you are an Ada fan, a Modula-II fan, a C fan or even open-minded, > it is very clear that the scientific community is not convinced that > Ada (or any language) is the best technology for all applications. Or > for any application. ^^^^^^^^^^^^^^^^^^^^^^ > -- > Jeff Offutt Its not the language which is important its the facilities it provides. Does any of the above languages provide all of the necessary and desirable constructs to provide well designed software and a method for validating correct compilers? What other language provides concurrency, dynamic exception handling, generics, reasonable encapsulation constructs, Adts, complete control structures, variable number of parameters with defaults, etc; there are some languages which don't even provide the basics for well designed software such as a reasonable type system or dynamic memory management (ie. ForTran) or strong typechecking and choice of parameter modes (C), etc. Ada was designed to standardize software and it could replace almost any language with exceptions being rare. For scientific software, Ada provides Adts to model vectors, matrices, and other mathematical objects and operators can be overloaded to provide high quality code. Ada's methodolgy is an excellent base for well designed software; as a scientist/engineer what doesn't Ada provide for you? Even if other reasonably complete languages could be standardized and validated I wouldn't want to learn X number of languages to read other programmers code, the fewer languages the better. While research languages will continue to explore new ideas, it will be several years before another language replaces Ada. I can't think of any application Ada is poorly suited to with its emphasis on well engineered software, can you justify your underlined claim above? Bob Hathaway rjh@purdue.edu ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-03-02 20:04 ` Bob Hathaway @ 1989-03-03 17:21 ` Paul Raveling 1989-03-05 1:07 ` Bob Hathaway ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Paul Raveling @ 1989-03-03 17:21 UTC (permalink / raw) In article <6153@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: >In article <4624@hubcap.UUCP>, ofut@hubcap.UUCP (A. Jeff Offutt) writes: >> >> C'mon, be careful what you say. As a scientist/engineer, I do not want >> anybody *mandating* the use of technology without clear *technical* proof >> that that is in every case the best solution. ... > >Its not the language which is important its the facilities it provides. >Does any of the above languages provide all of the necessary and desirable >constructs to provide well designed software and a method for validating >correct compilers? What other language provides concurrency, dynamic >exception handling, generics, reasonable encapsulation constructs, Adts, >complete control structures, variable number of parameters with defaults, ... >... Ada was designed to standardize software and it >could replace almost any language with exceptions being rare. Have you suggested that to a hard-core LISP user lately? Standardization is precisely the greatest danger of ADA, particularly because the DOD standard doesn't even permit extensions. If we accept the ADA standard we lose the option to improve as we learn better ways to approach software engineering. As for technical merit, there's plenty of room for argument. Much of it is in the realm of religion for now, but what's clear is that there's no clear agreement. Having written a compiler for an ADA subset, I know of a number of things I'd do differently in the language design if the opportunity existed. I'm not fond of ADA -- neither am I utterly pleased with C, FORTRAN, PL/I and relatives, ALGOL-60, COBOL, and gobs of other languages. Suppose somone designed a language provably better than these -- if we mandate an existing standard, such as ADA or C, we risk preserving a dinosaur at the expense of suffocating mammals. That's my usual comment about UNIX, but it also suits languages. ---------------- Paul Raveling Raveling@isi.edu ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-03-03 17:21 ` Paul Raveling @ 1989-03-05 1:07 ` Bob Hathaway 1989-03-06 16:52 ` Ada vs. LISP Robert Eachus ` (2 subsequent siblings) 3 siblings, 0 replies; 16+ messages in thread From: Bob Hathaway @ 1989-03-05 1:07 UTC (permalink / raw) In article <6153@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: >>... Ada was designed to standardize software and it >>could replace almost any language with exceptions being rare. In article <7682@venera.isi.edu>, raveling@vaxb.isi.edu (Paul Raveling) writes: > Have you suggested that to a hard-core LISP user lately? > > Standardization is precisely the greatest danger of ADA, > particularly because the DOD standard doesn't even permit > extensions. If we accept the ADA standard we lose the > option to improve as we learn better ways to approach > software engineering. A discussion on proposed extensions to Ada has been going on for a long time in comp.lang.ada, I'll assume you're replying from comp.software-eng. Several interesting ideas have emerged and I have hope the better ones will be adopted. > Suppose somone designed a language provably better than these -- > if we mandate an existing standard, such as ADA or C, we risk > preserving a dinosaur at the expense of suffocating mammals. > That's my usual comment about UNIX, but it also suits languages. In X years you may have a point, but by then the next best language will most likely replace Ada unless Ada keeps pace with extensions. But for now, lets at least upgrade the state of the practice to acceptable standards. Since most programs are written in 20+ year old languages (ForTran & LISP in the 50's, CoBOL & Pl1 & C in the 60's) we can begin building *new* software using state of the art techniques and continue to make upgrades in language design and techniques as often as necessary to ensure we maintain the highest standards in the software industry. As for keeping Ada state of the art, I'm sure the sei would like to hear your suggestions for better software design techniques and programming languages. Bob Hathaway rjh@purdue.edu ^ permalink raw reply [flat|nested] 16+ messages in thread
* Ada vs. LISP 1989-03-03 17:21 ` Paul Raveling 1989-03-05 1:07 ` Bob Hathaway @ 1989-03-06 16:52 ` Robert Eachus 1989-03-09 17:22 ` Tim King ` (3 more replies) 1989-03-15 1:33 ` "Forced to Use Ada" Douglas Miller 1989-03-16 14:06 ` karl lehenbauer 3 siblings, 4 replies; 16+ messages in thread From: Robert Eachus @ 1989-03-06 16:52 UTC (permalink / raw) In article <7682@venera.isi.edu> raveling@vaxb.isi.edu (Paul Raveling) writes: >In article <6153@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: >>... Ada was designed to standardize software and it >>could replace almost any language with exceptions being rare. > > Have you suggested that to a hard-core LISP user lately? > >Paul Raveling >Raveling@isi.edu One of the things which I did during the ANSI standardization of Ada was to look for ANYTHING in the standard which would make translation of LISP programs into Ada difficult. There were a few problems in the early drafts, but they were all eliminated by the final draft. As one of the problems for the AdaCan contest I proposed writing a compatiblity package to allow transliterated Common LISP to be compiled by any Ada compiler. (There are certain LISP lexical conventions that are incompatible with Ada, but they are easily dealt with: 'a --> QUOTE(A).) The problem was eliminated from the final list as too easy, but I still recieved two proposed solutions from LISP and Ada programers I showed the writeup to! Not only can you write AdaLISP, but some people already do. Incidently, AdaLISP does look a lot like LISP with the primary structures being nested fuction calls and aggregates, but there is no easy way to close lots of scopes, so don't try it without a good EMACS. It seems that everyone has seen AdaTRAN, but few people realize that the capability to write FORTRAN or COBOL or Pascal or LISP style programs in Ada was not an accident, it was a deliberate design requirement. Robert I. Eachus function TWIDDLE_THUMBS (LEFT, RIGHT: THUMB) return THUMBS is begin return TWIDDLE_THUMBS(RIGHT, LEFT); end TWIDDLE_THUMBS; ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Ada vs. LISP 1989-03-06 16:52 ` Ada vs. LISP Robert Eachus @ 1989-03-09 17:22 ` Tim King 1989-03-09 20:40 ` C++ vs. Ada (was Ada vs. LISP) Archie Lachner ` (2 subsequent siblings) 3 siblings, 0 replies; 16+ messages in thread From: Tim King @ 1989-03-09 17:22 UTC (permalink / raw) In article <45978@linus.UUCP> eachus@mbunix.mitre.org (Robert Eachus) writes: > One of the things which I did during the ANSI standardization of > Ada was to look for ANYTHING in the standard which would make > translation of LISP programs into Ada difficult. There were a few > problems in the early drafts, but they were all eliminated by the > final draft. > ... > (There are certain LISP lexical conventions that are incompatible with > Ada, but they are easily dealt with: 'a --> QUOTE(A).) Now, I'm no world class Lisp hacker, but I do know Ada, and I know enough about Lisp that I almost choked on my tongue when I read this. I showed this article to an associate who is heavily involved with Lisp (eg, as a member of the ANSI Common Lisp standards committee, and as a longtime Lisp zealot). He suggested that you might consider the following points: 1) Lisp's ability to store arbitrary objects in arrays regardless of the type of the object (ditto for lists, hash tables, etc.). 2) The first class nature of functions in Lisp. 3) Lisp's ability to share state among closures (you might be able to do this with Ada tasks). 4) Lisp macros. 5) Lisp symbols (they have plists and function bindings). 6) Lisp's complex type specifiers (e.g. type foo is either an integer or an array). 7) And so on. In a nut shell Ada can't support Lisp's view of typing, and functions are not first class objects in Ada. Even if you could somehow solve these problems, the performance of the resulting "AdaLisp" would be abysmal. If you *really* don't have anything better to do, try to write the following code in Ada: (defun funs (n) (let ((z n)) (cons #'(lambda (x) (incf z x)) #'(lambda (x) (decf z x))))) (setq foo (funs 0)) (funcall (car foo) 10) => 10 (funcall (cdr foo) 3) => 7 (=> is a short hand for evaluates to, and is not part of Common Lisp) ----------------------------------------------------------------- Tim King | Honeywell Systems & Research Center | Are we having fun yet? Mpls, MN 55418 | ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: C++ vs. Ada (was Ada vs. LISP) 1989-03-06 16:52 ` Ada vs. LISP Robert Eachus 1989-03-09 17:22 ` Tim King @ 1989-03-09 20:40 ` Archie Lachner 1989-03-10 3:31 ` Ada vs. LISP John Gateley 1989-03-12 16:22 ` Steven D. Litvintchouk 3 siblings, 0 replies; 16+ messages in thread From: Archie Lachner @ 1989-03-09 20:40 UTC (permalink / raw) From article <45978@linus.UUCP>, by eachus@mbunix.mitre.org (Robert Eachus): > In article <7682@venera.isi.edu> raveling@vaxb.isi.edu (Paul Raveling) writes: >>In article <6153@medusa.cs.purdue.edu> rjh@cs.purdue.EDU (Bob Hathaway) writes: >>>... Ada was designed to standardize software and it >>>could replace almost any language with exceptions being rare. >> >> Have you suggested that to a hard-core LISP user lately? >> >>Paul Raveling >>Raveling@isi.edu > > It seems that everyone has seen AdaTRAN, but few people realize > that the capability to write FORTRAN or COBOL or Pascal or LISP style > programs in Ada was not an accident, it was a deliberate design > requirement. > > Robert I. Eachus I doubt that an object-oriented C++ program can be translated into Ada. Ada does not offer control of the semantics of either assignment or initialization of user-defined types. This capability is critical in most object-oriented C++ programs. C++ is becoming a language of major importance, because of both its wide-spread use and the magnitude of the projects being coded in it. Attempts to dismiss it as a "passing fad," etc., are probably not appropriate. Comments? -- Archie Lachner Mentor Graphics Corporation Beaverton, Oregon ...!{decwrl,sequent,tessi}!mntgfx!archiel ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Ada vs. LISP 1989-03-06 16:52 ` Ada vs. LISP Robert Eachus 1989-03-09 17:22 ` Tim King 1989-03-09 20:40 ` C++ vs. Ada (was Ada vs. LISP) Archie Lachner @ 1989-03-10 3:31 ` John Gateley 1989-03-13 19:23 ` Robert Eachus 1989-03-12 16:22 ` Steven D. Litvintchouk 3 siblings, 1 reply; 16+ messages in thread From: John Gateley @ 1989-03-10 3:31 UTC (permalink / raw) In article <45978@linus.UUCP> eachus@mbunix (Robert I. Eachus) writes: > One of the things which I did during the ANSI standardization of >Ada was to look for ANYTHING in the standard which would make >translation of LISP programs into Ada difficult. Hmmm.... how would the following programs be written in Ada: (I give both Scheme and CL versions, take your pick) Scheme CL (define x (defun x (n) (lambda (n) (function (lambda (m) (lambda (m) (+ n m))) (+ m n)))) that is, how can you write first class functions? These are quite useful for things like writing an interpreter for Lisp in Lisp, or a denotational semantics, or table abstractions where the elements are functions etc. Scheme CL (define print (defun print (x) (lambda (x) (typecase x (cond (integer 1) ((integer? x) 1) (real 2) ((real? x) 2) (complex 3) ((complex? x) 3) (vector 4))) ((vector? x) 4)))) that is, how can you write dynamically typed functions? I do not think you can. These two features of Lisp that I have highlighted are fundamental aspects of the langauge. That is, it is not fair to say that you can translate programs from Lisp to Ada unless you can handle these cases as well. I am assuming that you do not mean you can write a Lisp compiler in Ada (since you can do that in any language), but that you can translate any expression in Lisp into a corresponding Ada fragment. John gateley@tilde.csc.ti.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Ada vs. LISP 1989-03-10 3:31 ` Ada vs. LISP John Gateley @ 1989-03-13 19:23 ` Robert Eachus 0 siblings, 0 replies; 16+ messages in thread From: Robert Eachus @ 1989-03-13 19:23 UTC (permalink / raw) I recieved many responses to my posting about Lisp style programming in Ada. Some were a bit extreme--An Ada program which supports the LISP semantics for (apply (read) (read)) is called a LISP interpreter. That is not what I was talking about. Of course you can write a LISP _interpreter_ in Ada, I was talking about compilable Ada code derived from LISP programs or designs. Now that I have also recieved several civil responses asking how to do it, it seems I had better post an example or two. This posting won't satisfy the skeptics, but then I could probably write a book explaining all the details and not satisfy some of them. The first thing to realize is that, contrary to the way Ada generics are usually taught, instantiation of generics happens during program execution, and that each time the generic instantiation is elaborated it creates a new instance. (If you think you understand this, skip ahead to SKIP_TO_HERE:. But I warn you, most Ada programmers only think they understand what that meant.) Those of you who are left, try this on your favorite Ada compiler: generic type Element is private; type Index is range <>; type List is array(Index) of Element; function Reverse(L: List) return List; function Reverse(L: List) return List is R: List; -- OK since List is constrained; begin for I in L'RANGE loop R(I) := L(L'LAST - (I - L'FIRST)); end loop; return R; end Reverse; There are more elegent ways to write this in Ada, but that is not the point. If you write a program to instantiate this generic in a loop: with Text_IO; with Reverse; with Get; procedure Test is begin loop declare Foo: constant String := Get; subtype Foo_Index is Integer range Foo'FIRST..Foo'LAST; subtype Foo_Type is String(Foo_Index); function Backwards is new Reverse(Character, Foo_Index, Foo_Type); begin exit when Foo'LENGTH < 1; Put_Line(Backwards(Foo)); end; end loop; end Test; On every pass through the loop, subtype Foo_Type has different bounds. Therefore each instance of Backwards expects a different length string. (Defining the function Get using TEXT_IO.GET_LINE is left as an exercise for the reader.) SKIP_TO_HERE: Now most of you are probably saying: "Big deal, we knew that Ada allowed strings with non-static bounds...", but the big deal is that subprograms are allowed as generic formals: generic type Element is private; type List is private; with function Something (E: in Element) return Element; with function "&"(Left: Element; Right: List) return List; with function CDR(L: in List) return List; with function CAR(L: in List) return Element; NUL: List -- Note: in a "real" lisp style Ada program only "Something" -- would be a generic parameter. function MAPCAR (L: in List) return List; function MAPCAR (L: in List) return List is begin if L = NUL then return NUL; end if; return Something(CAR(L)) & MAPCAR(CDR(L)); end MAPCAR; Very useful, but not yet LISP. We sometimes need to be able to pass functions as objects. Fortunately there is a way, but Ada purists will scream: function MAPCAR (L: in List; F: SYSTEM.ADDRESS) return List is function Something (E: in Element) return Element; pragma INTERFACE(System, Something); for Something'ADDRESS use F; begin if L = NUL then return NUL; end if; return Something(CAR(L)) & MAPCAR(CDR(L)); end MAPCAR; Obviously not guarenteed to be portable, but if your compiler supports it, you don't even need to use generics to have (LISP) fun in Ada. (Just substitute whatever language name your compiler requires for System in the pragma. One or two even allow Ada!) The next level of completeness is to create a "real" LISP environment. It is very rare to need to go this far, but it is possible: package LISP is type Element is private; type List is array (Natural range <>) of Element; -- Lists are defined as arrays so that (a,b,c) works. I usually -- cheat and provide visible arrays of Integers, and Float so -- that (1,2,3) and (1.0,2.0,3.0) can be recognized and -- handled. type Element_Type is (Number, Character, Symbol, List, Vector, Structure, Function); -- You may wish to add others, but this is what I use. Note -- that this is actually only provided as a shortcut for a -- special form of my own: function IS_A(Object: Element; Class: Element_Type) return Boolean; function MAKE(I: Integer) return Element; function MAKE(C: Character) return Element; function MAKE(S: String) return Element; -- etc. NIL: constant Element; Apply: Element; Eval: Element; -- Through all the special forms you use... private type Object; type Element is access Object; end LISP; What about the package body? It's fairly simple: Eval looks for a predefined functions with a case statement, and otherwise follows the standard (LISP) rules, and so on. Defun (and this is what keeps things from being unacceptably slow) actually does instantiation, and keeps the defined form available for Eval (see above). If pragma INTERFACE didn't work, you could treat each new function as a new Ada task object but I have had to stoop that low. I prefer to make available several generics in the specification of package LISP: generic with procedure X(L: List); package New_Procedure is New_X: Element; end package; New_X is, of course a new function object which can be Evaled, and the semantics are to invoke (the Ada generic formal procedure) X on the first argument. (In this case it evals to nil, of course.) This allows some functions (or in this case a procedure) to use Ada semantics, and others to use LISP. Robert I. Eachus ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Ada vs. LISP 1989-03-06 16:52 ` Ada vs. LISP Robert Eachus ` (2 preceding siblings ...) 1989-03-10 3:31 ` Ada vs. LISP John Gateley @ 1989-03-12 16:22 ` Steven D. Litvintchouk 3 siblings, 0 replies; 16+ messages in thread From: Steven D. Litvintchouk @ 1989-03-12 16:22 UTC (permalink / raw) In article <45978@linus.UUCP> eachus@mbunix.mitre.org (Robert Eachus) writes: > One of the things which I did during the ANSI standardization of > Ada was to look for ANYTHING in the standard which would make > translation of LISP programs into Ada difficult.... > It seems that everyone has seen AdaTRAN, but few people realize > that the capability to write FORTRAN or COBOL or Pascal or LISP style > programs in Ada was not an accident, it was a deliberate design > requirement. Now how about Simula-67? If only you had applied the same requirement to translating Simula-67 programs to Ada, perhaps Ada might have supported subclassing/inheritance better than it does! Seems like a missed opportunity.... In fact, the significance of Simula-67's class mechanism appears to have been overlooked by nearly everyone connected with the DoD HOL initiative--was it ever seriously considered for inclusion in Steelman? Or did they conclude (mistakenly) that types accomplished exactly the same thing? Steven Litvintchouk MITRE Corporation Bedford, MA 01730 Fone: (617)271-7753 ARPA: sdl@mitre-bedford.arpa UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Those who will be able to conquer software will be able to conquer the world." -- Tadahiro Sekimoto, president, NEC Corp. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-03-03 17:21 ` Paul Raveling 1989-03-05 1:07 ` Bob Hathaway 1989-03-06 16:52 ` Ada vs. LISP Robert Eachus @ 1989-03-15 1:33 ` Douglas Miller 1989-03-15 17:29 ` Paul Raveling 1989-03-16 14:06 ` karl lehenbauer 3 siblings, 1 reply; 16+ messages in thread From: Douglas Miller @ 1989-03-15 1:33 UTC (permalink / raw) In article <7682@venera.isi.edu>, raveling@vaxb.isi.edu (Paul Raveling) writes: > Standardization is precisely the greatest danger of ADA, > particularly because the DOD standard doesn't even permit > extensions. Even?! This is essential to maintain portability. > If we accept the ADA standard we lose the > option to improve as we learn better ways to approach > software engineering. We only give up the option to do software engineering research on our production software --- a good thing. > Suppose somone designed a language provably better than these -- > if we mandate an existing standard, such as ADA or C, we risk > preserving a dinosaur at the expense of suffocating mammals. If ADA is already a dinosaur, what does that make COBOL, a diatom? Come on, what about the real world? Surely it more important to stem the waste of squillions of person-years used to port software between language dialects. ADA is the only language that can currently do this due to the no subsets, no supersets policy. I don't believe anyone is suggesting that ADA should last forever. But it is a quantum leap over existing production languages, and should be adopted as the standard for developing production software, until research produces the next quantum leap. To quote rjh@cs.purdue.EDU (Bob Hathaway) in article <6153@medusa.cs.purdue.edu>: >Does any of the above languages provide all of the necessary and desirable >constructs to provide well designed software and a method for validating >correct compilers? What other language provides concurrency, dynamic >exception handling, generics, reasonable encapsulation constructs, Adts, >complete control structures, variable number of parameters with defaults, >... Ada was designed to standardize software and it >could replace almost any language with exceptions being rare. > That's my usual comment about UNIX, but it also suits languages. An operating system is a fundamentally different thing to a programming language. A programming language is much lower level --- this is where standards are really appropriate (analogy: no two models of motor car are (or should be) the same, yet many of the basic components conform to standards that enables a trained mechanic to do basic work on any car). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-03-15 1:33 ` "Forced to Use Ada" Douglas Miller @ 1989-03-15 17:29 ` Paul Raveling 0 siblings, 0 replies; 16+ messages in thread From: Paul Raveling @ 1989-03-15 17:29 UTC (permalink / raw) In article <163@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes: > >In article <7682@venera.isi.edu>, raveling@vaxb.isi.edu (Paul Raveling) writes: > >> Suppose somone designed a language provably better than these -- >> if we mandate an existing standard, such as ADA or C, we risk >> preserving a dinosaur at the expense of suffocating mammals. > >If ADA is already a dinosaur, what does that make COBOL, a diatom? Maybe a trilobite? Languages that DOD has adopted as standards to my knowledge are COBOL, JOVIAL, and ADA. Looking only at pre-ADA history, DOD's standards haven't exactly dominated the software engineering world on their own merits. I don't mean to pick on ADA specifically -- it's just that in my 26 years in computing people have kept learning how to do a better job at essentially EVERYTHING. One year's state of the art can be the trailing edge of technology after a couple more years pass. In the last 15 years or so though it's been MUCH harder to profit by that learning because the industry has had a heavy dose of standards. The bottom line is that I advocate "necessary and sufficient" standards, keeping them as limited as possible to enable reasonable software portability. If standards are small, software using them can expand by adaptive radiation; if standards are too comprehensive, software will be ecologically specialized. A currently important limit of specialization is the difficulty of building multi-process applications in a "standard" UNIX environment. > >> That's my usual comment about UNIX, but it also suits languages. > >An operating system is a fundamentally different thing to a programming >language. A programming language is much lower level --- this is where >standards are really appropriate (analogy: no two models of motor car are >(or should be) the same, yet many of the basic components conform to >standards that enables a trained mechanic to do basic work on any car). This is an interesting case to consider -- As a former OS builder, I tend to think of it in the opposite sense, with the OS being at a lower level. Typical OS interfaces semantically have a lot in common with abstract data types. In truth, it's something of a chicken-and-egg question and both views are correct in various ways. ---------------- Paul Raveling Raveling@isi.edu ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-03-03 17:21 ` Paul Raveling ` (2 preceding siblings ...) 1989-03-15 1:33 ` "Forced to Use Ada" Douglas Miller @ 1989-03-16 14:06 ` karl lehenbauer 3 siblings, 0 replies; 16+ messages in thread From: karl lehenbauer @ 1989-03-16 14:06 UTC (permalink / raw) In article <7682@venera.isi.edu>, raveling@vaxb.isi.edu (Paul Raveling) writes: > Standardization is precisely the greatest danger of ADA, > particularly because the DOD standard doesn't even permit > extensions. If we accept the ADA standard we lose the > option to improve as we learn better ways to approach > software engineering. True enough, and the same can be said for all standards. They inhibit innovation to some degree, but provide the well-understood benefits of interoperability and a large user base. > Suppose somone designed a language provably better than these -- > if we mandate an existing standard, such as ADA or C, we risk > preserving a dinosaur at the expense of suffocating mammals. > That's my usual comment about UNIX, but it also suits languages. Let me know when you've got a portable (hence, potentially standard) operating system that's arguably better than Unix working. I'd like to have a look at it. Until then, you're simply complaining about something that's become a standard by virtue of its being the only one around that can do it, without offering a viable alternative. -- -- uunet!ficc!karl "An expression of deep worry and concern failed to -- karl@ficc.uu.net cross either of Zaphod's faces." -- Hitchiker's Guide ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: "Forced to Use Ada" 1989-03-01 23:49 ` A. Jeff Offutt 1989-03-02 20:04 ` Bob Hathaway @ 1989-03-09 5:36 ` Harry S. Delugach 1 sibling, 0 replies; 16+ messages in thread From: Harry S. Delugach @ 1989-03-09 5:36 UTC (permalink / raw) In article <4624@hubcap.UUCP> ofut@hubcap.UUCP (A. Jeff Offutt) writes: > >C'mon, be careful what you say. As a scientist/engineer, I do not want >anybody *mandating* the use of technology without clear *technical* proof >that that is in every case the best solution. Can you give examples from any other field of engineering where there is clear technical proof that a particular method is, in every case, the best solution? I suspect that such a proof is impossible. > >Whether you are an Ada fan, a Modula-II fan, a C fan or even open-minded, >it is very clear that the scientific community is not convinced that >Ada (or any language) is the best technology for all applications. Or >for any application. Whoah! Those last two are completely different. Is Ada the best technology for all applications? Of course not. Who would have the unmitigated gall to say that it was? Is Ada the best languate for every application? Can you provide a proof? Can you prove that there is a better language than Ada for every single application? Easy enough, just start with a list of all possible applications, and then tell me for each one what the best language is. :-) My point is that these blanket statements about Ada are all too common. How about some discussion about application areas where Ada is clearly *not* the best language, or some other discussion about application areas where it is better (or at least, as good) as another language you would choose? For instance, there has been a lot of talk about Ada's inadequacies for real-time programs. What are those inadequacies, and what language is better at handling them? These are the kinds of questions I would like to see addressed in this discussion. -- Harry S. Delugach Dept. of Computer Science, Univ. of Virginia, Charlottesville, VA 22901 U.S.A. INTERNET: hsd@cs.virginia.edu BITNET: hsd2x@virginia UUCP: ..!uunet!virginia!uvacs!hsd CIS: 72727,2363 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1989-03-16 14:06 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1989-02-22 10:56 "Forced to Use Ada" Edward Berard 1989-02-27 23:28 ` Bob Hathaway 1989-03-01 23:49 ` A. Jeff Offutt 1989-03-02 20:04 ` Bob Hathaway 1989-03-03 17:21 ` Paul Raveling 1989-03-05 1:07 ` Bob Hathaway 1989-03-06 16:52 ` Ada vs. LISP Robert Eachus 1989-03-09 17:22 ` Tim King 1989-03-09 20:40 ` C++ vs. Ada (was Ada vs. LISP) Archie Lachner 1989-03-10 3:31 ` Ada vs. LISP John Gateley 1989-03-13 19:23 ` Robert Eachus 1989-03-12 16:22 ` Steven D. Litvintchouk 1989-03-15 1:33 ` "Forced to Use Ada" Douglas Miller 1989-03-15 17:29 ` Paul Raveling 1989-03-16 14:06 ` karl lehenbauer 1989-03-09 5:36 ` Harry S. Delugach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox