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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.lang.ada Subject: Re: Looking for PD Ada interpreter Message-ID: <1991Jun15.233022.9308@netcom.COM> Date: 15 Jun 91 23:30:22 GMT References: <31357@hydra.gatech.EDU> <1991Jun14.183916.867@lonex.radc.af.mil> <3309@sparko.gwu.edu> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} List-Id: An excellent post that I would like to reinforce in a few places with comments of my own... >What good is validation? Its main virtue is a guarantee of conformance to >the standard. This means that to an extent greater than with ANY OTHER >LANGUAGE, one can write programs that will compile and give the same >behavior under ANY compiler on ANY platform. Validation does NOT guarantee >100% portability, which given hardware differences and spots where the >standard deliberately allows implementor discretion, isn't really >achievable. Fortunately, the language designers were quite aware of the fact that 100% portability is something of a chimera, and so designed the language in such a way that non-portability is more often than not flagged by the compiler. For example, since the bounds of numerics are defined in a system-dependent package and all numerics descend in one form or another from these base definitions, the compiler can check for type declarations that simply cannot be supported by a particular machine because, say, the range is out of bounds for what the underlying hardware can support. This is a very nice feature, because one discovers these things statically, when the satellite (for example) is still on the ground, rather than at runtime when the satellite starts to spiral slowly into the sun... >With Ada, you can REALLY move stuff around, as long as you stay away from >machine-specific goodies (graphics, say). It works, folks. And the situation even for things that ARE machine dependent is not bad, provided you design an architecture that identifies, factors out, encapsulates, and abstracts machine dependencies into clearly identified separate subsystems. This "virtual machine" approach to machine dependency isolation works quite well--outside the machine-dependent subsystem the interface remains invariant regardless of what platform the software is running on (POSIX, by the way, is essentially just an attempt to do this for UNIX). Of course, thinking like this requires discipline and means that developers have to become less obsessed with bit-fiddling except when it is truly important to fiddle bits (e.g. when writing a device driver). I've seen code so poorly designed for portability that nearly every page of listing contained at least one highly machine-dependent call, usually without any justification whatsoever. >Perhaps, as C compilers mature and adhere to >the ANSI standard, programs that aren't too tricky may be as portable as >Ada programs are. But I have had a enough grief moving C programs from >SunOS to HP/UX to appreciate what validation buys us. When people tell me they write in C, my first question is usually "Which one?". >Someone has to pay the freight for this. The prices are still higher than >for other languages on similar platforms. Indeed. On the other hand, the cost is more than offset by the increased portability and repeatability of the resulting code. I keep saying this: you get what you pay for. For free, one can get a C compiler, which then permits you to run out and write code that costs a small fortune to port to a different platform (just ask Microsoft...). Compared to these sorts of costs, the initially higher cost of an Ada compiler is about a ninth-order consideration. The phrase "penny wise and pound foolish" comes to mind. >Most vendors seem to be in a "be nice to the schools" mood these days. Regarding the educational cost issues, I just had an idea. If the DoD is really serious about fostering the growth of Ada awareness in academia, rather than trying to underwrite the cost of developing a compiler itself (and effort destined to be approximately as successful as ALS-N), why not simply directly subsidize the cost of purchasing Ada compilers by educational institutions. A school would simply buy an Ada compiler/development environment for whatever hardware it happened to already own (VAX, Sun, whatever) and send the bill to the AJPO, who would reimburse them directly. In this way, the schools could choose the most appropriate compiler from all of those that are commercially available, and they could do so immediately, as opposed to after a Big Government Agency finally gets around to producing something a tenth as good for ten times the price. If the AJPO is wondering where it would get the money to do this, may I suggest cancelling ALS-N and using the money thus saved? This seems so straightforward to me it must be illegal. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *