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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fd6dd,c78177ec2e61f4ac X-Google-Attributes: gidfd6dd,public X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: ada and robots Date: 1997/06/04 Message-ID: <33961528.2A9A@sprintmail.com> X-Deja-AN: 246189864 References: <338CDA96.53EA@halcyon.com> <338F5D7D.6C03@tiac.net> <338F9D05.5EB3@bix.com> <5mqpj3$bc5$1@goanna.cs.rmit.edu.au> <33930245.12A1@sprintmail.com> <5mv984$7kn@news.emi.com> Reply-To: johnvolan@sprintmail.com Newsgroups: comp.robotics.misc,comp.lang.ada Date: 1997-06-04T00:00:00+00:00 List-Id: Joe Gwinn wrote: > Experience with Ada83 shows that it is very bad at direct control of > hardware, especially I/O hardware, and simply does not handle shared > memory correctly. Could you please elaborate a bit on the technical merits of this claim? Your assertion is a curious one, because in my experience Ada83 was very useful for just this sort of application, when applied with a bit of care and good judgment. Before anyone on this group can evaluate the validity of your claim, we have to discount the possibility that your bad experiences might have been due to (1) the admittedly poor quality some early Ada83 implementations (happily now _ancient_ history); (2) poor understanding of the facilities of Ada83, and how best to apply them; (3) willful _misunderstanding_ of the facilities of Ada83, attempting to apply them as if programming in a different language, thereby losing all the advantages of Ada and creating an artificial set of "disadvantages"; (4) forced introduction of Ada83 into a culture openly hostile to its adoption, making its failure in that culture a foregone conclusion; or (5) all of the above. > Ada95 is claimed to be better, but I don't have any > direct experience with it. Hmm ... so what you're saying is you don't really have any useful recent information for us, either way? >Actually, not many people do just yet. Oh, there are a few. I've done my share of low-level bit-twiddling with Ada95, and before that, with Ada83. I've been getting away from the low-level stuff lately, but I know of some other folks with some real heavy-metal experience with Ada95. Jim H., care to chime in here? :-) However, in my experience, it's always been the _abstractions_ that have saved my butt: Because of the (admittedly cultural) tendency in Ada to encapsulate lower-level stuff into higher-level abstractions, when push came to shove on efficiency you could go down into the abstractions, pick a different implementation, and magically improve performance across the board, without having to do a lot of massive ripping and tearing in the application design. But that takes a certain kind of engineering skill sadly lacking in the typical silicon jockey weened on C... > I > suspect that most people are using C (perhaps called from Ada) for direct > control of I/O hardware and the like. Most likely for cultural, rather than technical reasons. > Most "Ada systems" I have seen built recently are actually mixed-language > systems, being a mix of C, C++, and Ada, with the Ada being in the > minority (maybe 25%), if one counts all the purchased COTS code in the > system. Typically, the operating system, middleware, and GUI stuff are > all in C, and the application code is mostly in Ada (with C bindings, and > no Ada runtime). It's really a question of attitude: Is your glass 3/4 empty, or 1/4 full? To me, given the sheer cultural and marketing inertia propping up C, a 25% inroad of Ada on a project sounds like a phenomenal success against enormous odds. It demonstrates what many have been saying: Ada is great for gluing together multi-language code, and for adding a much-needed layer of abstraction over the miserable bit-twiddling that passes for APIs these days. It also shows that Ada is a good choice for the code that you actually have to write and maintain yourself (as opposed to the code you simply buy from somewhere else). > Not all Ada compilers offer adequate support for such mixed-language > systems, especially when it comes time to debug on target (vice host) > systems. This can be a severe problem, because it's generally impossible > to build a competitive offering without extensive use of COTS components, > which are almost always in C/C++, and impossible to get working soon > enough to matter without good debugging support. If the COTS products you bought are so poorly engineered and documented that you need to diddle them with a debugger (of all things) to get them to work, or even just to figure out how to actually interface with them, then you've got some very serious problems that have nothing to do with the quality of your Ada compiler. The fact that such products are written in C or C++ is not exactly a glowing endorsement of either of those two languages. > Whatever set of > compilers and tools you plan to use should be demonstrated to do *exactly* > what you need done, with sufficient performance, before purchase. Don't > assume that anything works until proven. (A year ago, we very nearly > bought an Ada that couldn't even link a mixed-language (C and Ada83) > VxWorks system, let alone execute the code and debug. Insisting on a true > and accurate demo saved our butts.) That was, of course, wise. But I wonder if the same stringent criteria have ever been applied to those wonderful COTS products about which I've heard so much glowing hype^H^H^H^H praise lately... :-) ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Texas Instruments Advanced C3I Systems, San Jose, CA", Work_Email => "johnv@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) "); ------------------------------------------------------------------------