From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,25d5234e7b6ca361 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 2003-02-27 16:13:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!sjc70.webusenet.com!rip!news.webusenet.com!cox.net!news-hub.cableinet.net!blueyonder!internal-news-hub.cableinet.net!news-text.cableinet.net.POSTED!53ab2750!not-for-mail From: "Karen" Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada References: <3E4E8F8C.9C096985@adaworks.com> <9fa75d42.0302250710.5549baaf@posting.google.com> <3E5C7033.BD5DC462@adaworks.com> <9fa75d42.0302260618.7506cba7@posting.google.com> <3E5CF5C6.84822F57@adaworks.com> Subject: Re: Ada versus language-X and "getting real work done" (was): 64 bit addressing and OOP X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Message-ID: Date: Fri, 28 Feb 2003 00:13:29 GMT NNTP-Posting-Host: 80.193.1.203 X-Complaints-To: abuse@blueyonder.co.uk X-Trace: news-text.cableinet.net 1046391209 80.193.1.203 (Fri, 28 Feb 2003 00:13:29 GMT) NNTP-Posting-Date: Fri, 28 Feb 2003 00:13:29 GMT Organization: blueyonder (post doesn't reflect views of blueyonder) Xref: archiver1.google.com comp.lang.java.advocacy:59437 comp.object:58565 comp.lang.ada:34698 Date: 2003-02-28T00:13:29+00:00 List-Id: Absolutely. Anyway, processing comunications received from other systems is not trivial even in Ada. The inevitable issues of interface hardening, addition of explicit prototols etc and problems with endianism means that interface processing will always be difficult.... Unless... You can standardise inter system protocols against families of languages using code generation - the real benefit of ORBs. Ada is without doubt a solid language. Its the only language I have found where you can teach it through the structure of teaching software engineering. (Teach s/w eng. goals -> principles -> language constructs, so the students know why to do something, not simply the syntax). The real benefit of other languages is the leverage it can give you to interface / exploit COTS products that provide services in only another language. For ages the only way to integrate a commercial GUI into a system, was to go via C and later C++. We had to wait so long for native Ada GUI services it was laughable. Only with Ada 95 was the "Ada - I'm the centre of the world and if you can't play Ada, I won't play with you" view changed, and decent mixed langage systems could be built - openeing the way to exploit commercial tools but still use a decent language for the 'business logic (e.g. defence) s/w. My organisation routinley roll out multimillion lines systems (soft real-time) for the defence industry - and it works. Increasingly we exploit commercial s/w products, embeded into out systems, but the core is Ada, and we have no intention of changing that. "Marin David Condic" wrote in message news:b3l0oe$7to$1@slb9.atl.mindspring.net... > While I agree with much of this post, I've got to observe that > communications between systems or programs is *not* the issue. (Nor was it a > consideration when the DoD started down the path of Ada) Ada can no more > guarantee that data representation is consistent between applications than > anything else. Different compilers are free to implement primitive data > types in any way they like provided they meet certain criteria. Two > different versions of the same compiler might have different representations > for the same data. Machine architectures differ. Communications mechanisms > differ. A single programming language is *not* going to fix that. > > The biggest consideration for the DoD initially was that they would get out > of spending money to support dozens or maybe even hundreds of different > languages in the various programs they funded. They would get some > transferability of skills from one project to the next and quit having to > pay for the learning curve. They also wanted higher reliability and other > noble objectives. Its just not the case that they expected to get > consistency in inter-process communications as part of the bargain and if > that *is* what they expected, they certainly didn't get it. > > MDC > -- > ====================================================================== > Marin David Condic > I work for: http://www.belcan.com/ > My project is: http://www.jsf.mil/ > > Send Replies To: m c o n d i c @ a c m . o r g > > "Going cold turkey isn't as delicious as it sounds." > -- H. Simpson > ====================================================================== > > Kent Paul Dolan wrote in message > news:a3eaa964.0302261422.4d166fa1@posting.google.com... > > > > It helps to remember the context. The DoD had, and has to > > this day, a situation where battlefield computers programmed > > in different languages couldn't talk to one another. A > > couple of obvious results of this kind of situation are that > > people die from friendly fire problems, and that people die > > from corrupted transmissions. It was, and still is, > > important that the computer software share a single > > language, with that language's exact semantics for > > primitives and user declared types, so that communication > > succeeds and at least the people fighting on our side get to > > claim they got killed by the enemy instead of friendly > > forces or computer glitches. > > > > >