Re: Ada vs C++ vs Java

[robert_dewar@my-dejanews.com]

In article <79s889$as4@drn.newsguy.com>,
  mike <mike@newsguy.com> wrote:
> In article <79s23i$ena$1@nnrp1.dejanews.com>,
> robert_dewar@my-dejanews.com
> says...
>
> >The interesting thing is that Ole-Hjalmar in this
> >exchange
> >has not given even a single reason why sort in
> >particular
> >should be standardized.
> >
>
> The argument is simple.
>
> Having a standard function to do X, makes it more
> convenient for the programmer using the language.

That's complete nonsense. It argues for standardizing
every possible function. I do not know anyone in the
language design/standardization field who would make
such an absurd claim. For example, if someone suggested
that the ISO C++ standard should contain a standardized
function for converting Microsoft WORD version 5.0 files
to Word 7.0 format, they would be regarded as eccentric
at best, and off the wall at worst. Yet the general
argument you give would argue in favor of such an addition.

What everyone agrees on is that a language standard should
contain standardized versions of functions whose
specification and implementation are completely standard,
and whose utility justifies their inclusion.

Different languages make different decisions in this area.
For example, Ada considers that control over priority
of executing threads is in this category, but sorting is
not, and C++ makes exactly the opposite decisions.

Which set of decisions is right? Perhaps one, perhaps the
other, perhaps neither, perhaps both (the requirements
may be different after all). Discussion of whether a choice
is right in a particular case is an interesting technical
discussion, but general arguments of the kind proposed here
do not add even epsilon of value to the discussion of a
specific case.

Standardization is a double edged sword, it has the
advantage of creating a single fixed way of doing things.
It has the disadvantage of stifling continued technical
development and improvement and specialization to a
particular requirement. Every standardization effort
involves carefully deciding *what* to standardize to
reap the advantages, and minimize the disadvtantages.

So I will repeat, no one yet has given arguments as to why
sort *should* be standardized, though we have seen some
arguments on the contrary side.
>
> Take Java for example. Java provides a package for doing
> SQL stuff.

If you are trying to say that the Java standard includes
this function, you are wrong. Why? Because there is no
Java standard, just an informal language design, with
several implementations, which conform more or less to
this design.

It is often the case that actual implementations of
languages do include all sorts of useful functionality
(e.g. C programs can almost certainly call unlink even
though ANSI C has no such function, and Ada 95 programmers
using GNAT will indeed find some "standard" sorting
routines in the GNAT library. There are *many* sources of
informally "standard" routines available to anyone writing
in any language, and this kind of reuse is of course
fundamental.

However, this does not mean that everything possible should
be standardized.

Indeed what often happens is that even where everyone
agrees that something should be standardized, the rigorous
requirements of a standard break down the consensus. For
example, everyone obviously agrees that functions like
sqrt, sin, cos should be standardized, but in the Ada
world, even the standardization of these functions was
very tricky -- why? Because Ada is an odd language, it
thinks that the accuracy of floating-point operations
should be defined :-) Given this attitude, you have to
worry about required accuracy of these primitive
operations, and that is not easy.

Another point is that secondary standards are often the
appropriate way to go. Ada has a standard for SQL binding
(one that is incidentally far more sophisticated and better
thought out than the Java implementation), but it is a
secondary standard, since it really required a separate
working group to work out the details. The math functions
for Ada 83 were handled in a similar manner, though for
Ada 95, the decision was to incorporate this work into the
main standard (the SQL secondary standard was not
incorporated).

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own