TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

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

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

Print Reply
Subject:
From:
Richard Conn <[log in to unmask]>
Reply To:
Richard Conn <[log in to unmask]>
Date:
Thu, 13 Jul 2000 01:52:53 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (97 lines)
Comments are interspersed below.  I think John is making several good
points,
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
out.

This is very true. It is clear that a lot of effort has been made with the
Ada
standard to make it encompass pretty much all the could be needed at the
moment.
-- While Ada is pretty thorough, it still misses several basics.  For
example,
-- how about a standard way to access Environment Variables like we can
access
-- 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
all
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
a
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
being
defined for a specific purpose, and then being hijacked for use in industry.
If
the Pascal compilers in those days had adhered to the standard, there is a
good
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
different
language, sure the basic syntax was the same (well, similar), but the things
you
could do with it were amazing compared with the Tektronix implementation. To
be
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
Pascal,
it would not have gained such wide acceptance, and would more than likely
*not*
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
features
required by the relevant standard. Whether it provides, or should be allowed
to
provide, an implementation defined superset depends on the application
domain.
-- I tend to think that supersets are always a good idea and needed so long
as
-- a domain may cross platforms.  If the domain does not cross platforms,
that's
-- a different matter, especially if the language is designed for that
domain.

It may seem reasonable for example for Microsoft to add implementation
specific
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
it
reasonable to assume that those facilities are all that are required for an
application to work?

John

ATOM RSS1 RSS2