TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Richard Conn <[log in to unmask]>
Thu, 13 Jul 2000 01:52:53 -0400
text/plain (97 lines)
Comments are interspersed below.  I think John is making several good
but I don't agree entirely.  My comments begin with -- (novel concept, eh?

Richard Conn, Principal Investigator
Reuse Tapestry

-----Original Message-----
From: Team Ada: Ada Advocacy Issues (83 & 95)
[mailto:[log in to unmask]]On Behalf Of [log in to unmask]
Sent: Wednesday, July 12, 2000 5:41 AM
To: [log in to unmask]
Subject: Re: Leveraging MicroSoft's Marketing

>Sorry to go off topic, but one of the things that I like about Ada is that
>it is a Standard with minimal compromise.
-- I'm sorry, but the compromises that took place during the development
-- of the Ada standards were enormous.  Just look at the huge volume of
-- language issues in the archives, and look how long it took to work them

This is very true. It is clear that a lot of effort has been made with the
standard to make it encompass pretty much all the could be needed at the
-- While Ada is pretty thorough, it still misses several basics.  For
-- how about a standard way to access Environment Variables like we can
-- a Command Line (note that Ada83 did not even have Command Line access in
-- a standard way, and it was added with Ada95)

While I agree in principle with your feelings on adherence to standards, if
compiler products adhered strictly to the standards for their respective
languages, it is unlikely that we would ever build any software that did
anything useful. Although Ada is very good in this respect, there are still
great number of implementation defined features that can (and do) reduce the
portability of an application across different compilers.
-- Absolutely.

As far as standards go, ISO Pascal is (was?) a prime case of a language
defined for a specific purpose, and then being hijacked for use in industry.
the Pascal compilers in those days had adhered to the standard, there is a
chance that it would never have been used in industry, as it was pretty much
useless as a production lanaguage! In my early days at Marconi Space
Systems, I
used Tektronix Pascal for 6 months or so for an 8086 target, then moved onto
using VAX Pascal for a couple of years. It was like using a totally
language, sure the basic syntax was the same (well, similar), but the things
could do with it were amazing compared with the Tektronix implementation. To
honest, if it hadn't been for the implementation specific extensions that a
large number of companies (e.g. DEC, Tektronix, Borland etc) had made to
it would not have gained such wide acceptance, and would more than likely
have had such a significant effect on the design of what is now Ada.

My personal view is that an implementation should always provide the
required by the relevant standard. Whether it provides, or should be allowed
provide, an implementation defined superset depends on the application
-- I tend to think that supersets are always a good idea and needed so long
-- a domain may cross platforms.  If the domain does not cross platforms,
-- a different matter, especially if the language is designed for that

It may seem reasonable for example for Microsoft to add implementation
extensions to produce Visual C++, however for something which is less
platform-specific (such as HTML), this seems to me to be unreasonable (as
appears to have been shown with the ASE Community problems).
-- The ASE Community issues are not due to HTML so much as browser features,
-- particularly add-ins.

Ultimately, if the standard facilities are provided by an implementation, is
reasonable to assume that those facilities are all that are required for an
application to work?