bw10@prism.gatech.EDU (WILLIAMS,BRYAN D.) (06/14/91)
I'm looking for a public-domain Ada *interpreter* that will run under BSD 4.3 or SysV.3 on HP/Apollo workstations (for those in the know, we're running Domain/OS SR10.3). Of course I'd prefer something that is known to be fast and robust, but I fear the real question is whether ANY such PD software is available. If anyone out there can point me to a source, I'd be very grateful. Please send responses by e-mail; I'll happily summarize any information I receive.
vanderwerkend@lonexb.radc.af.mil (Dan Vanderwerken) (06/15/91)
In article <31357@hydra.gatech.EDU> bw10@prism.gatech.EDU (WILLIAMS,BRYAN D.) writes: >I'm looking for a public-domain Ada *interpreter* that will run under [rest of message deleted] I keep seeing messages like this in this Ada group, and I keep seeing messages about how _expensive_ Ada compilers, etc. are. A great many people out there are asking about PD Ada compilers/interpreters but I've seen no answers. Do *any* PD Ada compilers/interpreters exist? Or are all of these people asking the same FAQ and not getting any answers? I don't see how any PD Ada compilers could exist. Ada is a rather large language and for DoD work must be periodically certified. -- + Captain Daniel F. Van Der Werken, Jr., USAF | I do not speak for the Air + Rome Laboratory/OCDS | Force, otherwise I'll be + Griffiss AFB, NY 13441 | in Kansas making big rocks + (315) 330-3575/DSN 587-3575 | into little rocks!
mfeldman@seas.gwu.edu (Michael Feldman) (06/16/91)
In article <1991Jun14.183916.867@lonex.radc.af.mil> vanderwerkend@lonexb.radc.af.mil (Dan Vanderwerken) writes: >In article <31357@hydra.gatech.EDU> bw10@prism.gatech.EDU (WILLIAMS,BRYAN D.) writes: >>I'm looking for a public-domain Ada *interpreter* that will run under >[rest of message deleted] > >I keep seeing messages like this in this Ada group, and I keep seeing messages >about how _expensive_ Ada compilers, etc. are. A great many people out there >are asking about PD Ada compilers/interpreters but I've seen no answers. > >Do any PD Ada compilers/interpreters exist? Or are all of these people asking >the same FAQ and not getting any answers? > >I don't see how any PD Ada compilers could exist. Ada is a rather large >language and for DoD work must be periodically certified. ^^^^^^^^^ > As one who has complained as loudly as anyone about the high price of compilers, I feel obliged to take the other side for a moment. Bear with me. First, let's get some terminology straight. The word is "validated." What does it mean? First, that the compiler developer has tested the product using the current ACVC (Ada Compiler Validation Capability), several thousand programs that test conformance to the standard, and found the compiler to be in conformance ("passed" all the relevant tests). Second, that a DoD designee has visited the developer site and repeated the tests. There used to be a user fee for this of a number of thousand dollars, to defray the cost of the site visit (is the fee still in effect?) The labor to create a validated compiler, and pay the fees for the official validation process, makes creating a validated compiler expensive, and so most developers feel they should collect some revenue to offset these costs. That is one important reason that there aren't a lot of shareware or PD Ada systems out there. Essentially there are none. The only approximation is the various Unix/VMS/DOS versions of Ada/Ed, developed by New York University with DoD funding. (I can supply contacts by e-mail if anyone is interested). 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. I believe this is especially useful in the education world, where students move from OS to OS to get experience in lots of them. Try moving a Turbo Pascal program (even one that doesn't use PC goodies) from your PC to Unix to see how hopeless the Pascal standard is. (The Pascal standard is a joke.) Try moving your Turbo program to Quick Pascal, staying on the same machine. I can tell you from personal experience that it ain't easy. With Ada, you can REALLY move stuff around, as long as you stay away from machine-specific goodies (graphics, say). It works, folks. We in the Ada community expend LOTS of effort picking apart those areas of non-portability, and sometimes lose sight of the fact that validation offers a far higher degree of machine independence than has ever been achieved before. Perhaps, as C compilers mature and adhere to the ANSI standard, programs that aren't too tricky may be as portable as Ada programs ar But I have had a enough grief moving C programs from SunOS to HP/UX to appreciate what validation buys us. I still hear questions from people who used interim compilers 5 years ago like "does compiler XYZ do tasking?" or "does compiler PQR do generics." The answer is "if it's validated, it has to." Validation covers ALL of the language (though some machine-specific things like the stuff in Chapter 13 may not be tested too thoroughly, because they are machine- specific anyway.) Validation does NOT buy perfection, because validation is TESTING and we know that "testing only shows the presence of bugs, not the absence of bugs." Validation does not buy speed, either, because correctness is not the same as efficiency. "It's easier to make a correct program fast than a fast program correct." Since 1983 (my first encounter with Ada compilers), I have watched Ada compilers on VM, VMS, Unix, DOS, and Macintosh mature and stabilize very nicely over the successive versions. They are MUCH more correct, and they are MUCH more efficient. Maturity yields correctness; competition yields speed. Current versions of compilers typically have both. Someone has to pay the freight for this. The prices are still higher than for other languages on similar platforms. There's no GNU Ada (yet, though this might very well happen...). On the other hand, if you're in an educational institution, have you checked the prices recently? $149.00 for a DOS or Mac compiler is surely getting into the right ballpark. And server licenses for Unix compilers are, I think, around $1000. these days, which is higher than I wish it were but still kind-of affordable for a school, considering the number of users it would have. I believe that for multiple servers the price comes down below that. And I have heard (though not from primary sources) that DEC and Sun will provide Ada compilers essentially free to their educational hardware customers. I believe this is also the case for the IBM mainframe compiler, if the school has the right arrangement with IBM. I have used this last compiler recently, and it's quite a respectable piece of software (TeleSoft built it). Most vendors seem to be in a "be nice to the schools" mood these days. I hope this little discourse has at least provided some understanding of the issues. I'll archive it and ship it by e-mail to anyone who posts the question again. Cheers - Mike
jls@netcom.COM (Jim Showalter) (06/16/91)
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++. *