The revolution will not be standardized

The revolution will not be standardized

[Ted Dennison]

There's an article on zdnet about Sun dropping their standardization
efforts for Java.

http://www.zdnet.com/pcweek/stories/news/0,4153,2405787,00.html

I guess the definition of Java is just going to be "whatever Sun says it
is".

This seems like a good oppertunity to promote Ada as an "Open"
alternative, that is in many cases more portable as well.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Ed Falis]

In article <82p7hu$l1q$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> There's an article on zdnet about Sun dropping their standardization
> efforts for Java.
>
> http://www.zdnet.com/pcweek/stories/news/0,4153,2405787,00.html

> This seems like a good oppertunity to promote Ada as an "Open"
> alternative, that is in many cases more portable as well.

Once we have the 1001+ amazing standard API's and figure out how to get the
cool factor.  Haven't ever managed to do that last one myself.

- Ed


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Ted Dennison]

In article <82ppc9$1u6$1@nnrp1.deja.com>,
  Ed Falis <falis@my-deja.com> wrote:
> In article <82p7hu$l1q$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> > This seems like a good oppertunity to promote Ada as an "Open"
> > alternative, that is in many cases more portable as well.
>
> Once we have the 1001+ amazing standard API's and figure out how to
> get the cool factor.  Haven't ever managed to do that last one myself.

Perhaps if we had a hard rule that all Ada-related products have to be
palindromes... :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Geoff Bull]

Ed Falis wrote:
> 
> Once we have the 1001+ amazing standard API's

Since Java is now free, in the monetary sense, we have 1001+
amazing standard APIs simply by calling Java's APIs.
We just need an easy standard way of doing this.
A bit of compiler support (e.g. circular references) would make
building bindings easier.

>and figure out how to get the
> cool factor.  Haven't ever managed to do that last one myself.

Me neither.
Mind you, Java programmers think Ada's package renaming is cool,
especially when someone changes the name of a package in a library.
(there is a good reason for doing this)

Cheers
Geoff

Re: The revolution will not be standardized

[Robert Dewar]

In article <385252E8.FF140CD2@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:
>
>
> Ed Falis wrote:
> >
> > Once we have the 1001+ amazing standard API's
>
> Since Java is now free, in the monetary sense, we have 1001+
> amazing standard APIs simply by calling Java's APIs.
> We just need an easy standard way of doing this.
> A bit of compiler support (e.g. circular references) would
make
> building bindings easier.

This is at least partially in place, GNAT supports a form of
with type, precisely for this purpose.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Geoff Bull]

Robert Dewar wrote:

> This is at least partially in place, GNAT supports a form of
> with type, precisely for this purpose.

I had seen this in the JGNAT bindings for Rapid, but there is
no mention of this in the documentation, not even obscurely
placed under the heading "With Type Clause" :-)

I had thus assumed it was JGNAT only. In retrospect this was a
silly assumption, why would you make the front end different?

Through the wonders of open source, I find:

      ----------------------
      -- With_Type clause --
      ----------------------

      --  This is a GNAT extension, used to implement mutually recursive
      --  types declared in different packages.

      --  WITH_TYPE_CLAUSE ::=
      --    with type type_NAME is access | with type type_NAME is
tagged

I will try this.

Thanks
Geoff

Re: The revolution will not be standardized

[Larry Kilgallen]

In article <3854EBD4.6B100D52@acenet.com.au>, Geoff Bull <gbull@acenet.com.au> writes:
> 
> 
> Robert Dewar wrote:
> 
>> This is at least partially in place, GNAT supports a form of
>> with type, precisely for this purpose.
> 
> I had seen this in the JGNAT bindings for Rapid, but there is
> no mention of this in the documentation, not even obscurely
> placed under the heading "With Type Clause" :-)
> 
> I had thus assumed it was JGNAT only. In retrospect this was a
> silly assumption, why would you make the front end different?
> 
> Through the wonders of open source, I find:
> 
>       ----------------------
>       -- With_Type clause --
>       ----------------------
> 
>       --  This is a GNAT extension, used to implement mutually recursive
>       --  types declared in different packages.
> 
>       --  WITH_TYPE_CLAUSE ::=
>       --    with type type_NAME is access | with type type_NAME is tagged

If your comment about the "wonders of open source" means finding
features that are not documented, I "wonder" about the wisdom of it.

Often a feature that is not documented is also not supported (although
in this particular case, Robert indicates it is supported).  Typically
the documentation, however, is the indication of what is supported and
what is not.  I recall discussions of some GNAT features provided only
for building GNAT.

Open source would be useful if you were going to support yourself on
a feature, of course.

Larry Kilgallen

Re: The revolution will not be standardized

[Geoff Bull]

Larry Kilgallen wrote:
> 
> Often a feature that is not documented is also not supported 

I use the public version of GNAT, so *nothing* is supported!

> I recall discussions of some GNAT features provided only
> for building GNAT.

This particular feature is obviously there for JGNAT - I haven't
seen JGNAT, but I have seen the JGNAT port of Rapid and it extensively
uses the with type feature.

> 
> Open source would be useful if you were going to support yourself on
> a feature, of course.

I don't pay anyone for support, so other than freebies I get 
on gnat chat, I'm on my own.

Geoff

Re: The revolution will not be standardized

[Ted Dennison]

In article <385252E8.FF140CD2@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:

> Since Java is now free, in the monetary sense, we have 1001+
> amazing standard APIs simply by calling Java's APIs.

Yes, but is it free in the freedom sense?

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[reason67]

In article <8333q3$9rh$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> > Since Java is now free, in the monetary sense...
>
> Yes, but is it free in the freedom sense?

Yes it is. You have the freedom to choose to use Java under the
restrictions put on it by Sun. You do not have the freedom to force Sun
to not put restrictions on it. Since Sun can not force you to use it,
Java is free in the freedom sense because no one can initiate force in
its use.
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Aidan Skinner]

On Mon, 13 Dec 1999 16:06:54 GMT, reason67@my-deja.com
<reason67@my-deja.com> wrote: 

>Yes it is. You have the freedom to choose to use Java under the
>restrictions put on it by Sun. You do not have the freedom to force Sun

OTOH only Sun says what "Java" is, and they've recently removed it
from the standardisation process.

One of the major things about Ada that I prefer over Java is that it's
standardised, and that that standard is freely available.

- Aidan (who would, frankly, be lost without the LRM and refers to it
more often than any of his text books)
-- 
http://www.skinner.demon.co.uk/aidan/
http://www.gla.ac.uk/Clubs/WebSoc/~9704075s/
"I could always suspend a few hundred accounts and watch what happens"

Re: The revolution will not be standardized

[Geoff Bull]

Aidan Skinner wrote:
> 
> On Mon, 13 Dec 1999 16:06:54 GMT, reason67@my-deja.com
> <reason67@my-deja.com> wrote:
> 
> >You have the freedom to choose to use Java under the
> >restrictions put on it by Sun.

In that sense, just about anything is free!

> One of the major things about Ada that I prefer over Java is that it's
> standardised, and that that standard is freely available.
> - Aidan (who would, frankly, be lost without the LRM and refers to it
> more often than any of his text books)

Me too.
But Java is standardised too.
There is a language specification for the core language.
The libraries are extensively documented, so that can be considered
a standard. And of course, the JVM has a standard.
All of these standards are freely available on the net.
Does it really matter whether they are Sun standards or ISO standards?
I agree it affects who has power over the language, but in either case
that power doesn't lie with me!


I have lots of reasons for preferring Ada over Java,
ISO standardisation is a long way down the list.

Cheers
Geoff

Re: The revolution will not be standardized

[Ted Dennison]

In article <38561D9A.70B61403@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:
> But Java is standardised too.

I disagree.

> There is a language specification for the core language.

But if Sun decides tomorrow that Java now looks just like Python, who's
to stop them?

If someone makes a completely non-conformant JVM, and pays Sun a ton of
money, what's to stop Sun from declaring it a valid JVM?

If someone makes a perfectly conformant Java but Sun doesn't like them
for some other reason, what's to stop Sun from refusing to declare it a
valid Java implementation?

> The libraries are extensively documented, so that can be considered
> a standard. And of course, the JVM has a standard.

Being documented does not make something a standard. By that logic,
every commercial API in the world would be a "standard".

> Does it really matter whether they are Sun standards or ISO standards?

That's the rub. I think it matters a great deal whether a "standard" is
at the mercy of any one vendor. In fact, I think that situation is a
good answer to the question: "When is a standard *not* a standard?".

Look at it this way. Unlike ISO, Sun is not in the business of
developing and shepherding standards. Sun is in the business of selling
hardware and some software. If they have an oppertunity to muck with the
standard in a way that will help their sales or hurt a competitor's,
they *will* do it. If I happen to be that competitor, or just an
innocent bystander who also happens to get hurt, that's just too bad for
me. If you think this isn't likely to happen, just take a look at what
Microsoft has historicly done with their de-facto standards.

Now, how is someone going to accomplish the same feat with the Ada
standard?

I notice sales materials touting conformance to open standards in
products all the time. I would think the principle should a apply
equally well to languages as it does to communications protocols.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Geoff Bull]

Ted Dennison wrote:
> 
> In article <38561D9A.70B61403@acenet.com.au>,

> > There is a language specification for the core language.
> 
> But if Sun decides tomorrow that Java now looks just like Python, who's
> to stop them?

A few million unhappy customers.

> If someone makes a completely non-conformant JVM, and pays Sun a ton of
> money, what's to stop Sun from declaring it a valid JVM?

That would seem like a pretty dumb thing to do in the long term,
particularly considering the Sun v Microsoft cases.

> If someone makes a perfectly conformant Java but Sun doesn't like them
> for some other reason, what's to stop Sun from refusing to declare it a
> valid Java implementation?

I'm not a lawyer, but I can think of a few legal angles on this one.
To start with, in Australia, that would be a breach of our
Trade Practices Act. And I am under the impression that US laws are
tougher than ours in this regard.

> > The libraries are extensively documented, so that can be considered
> > a standard. And of course, the JVM has a standard.
> 
> Being documented does not make something a standard. By that logic,
> every commercial API in the world would be a "standard".

True - but if something has a few million users it is a defacto
standard.

> 
> "When is a standard *not* a standard?".

When nobody uses it.

Re: The revolution will not be standardized

[Preben Randhol]

Geoff Bull <gbull@acenet.com.au> writes:

| Ted Dennison wrote:

| > Being documented does not make something a standard. By that logic,
| > every commercial API in the world would be a "standard".
| 
| True - but if something has a few million users it is a defacto
| standard.

Which is also the problem. A different angle. Many users use Microsoft
Words. The file format Word uses change from version to version and is
of course kept secret. But people still upgrade and use Word because
everybody else does even though it is not in their best interest.

So having Sun "own" Java and being the "benevolent" ruler of how Java
is supposed to work is not a thing I would like for the future.

I would think Sun strategy is not to get people to use _their_ OS, but
that everybody should use Java. Then Sun gets a monopoly through that.

So having Java as an ISO standard where Sun does not control it is
IMHO a better solution for the future.

See also:

http://www.osopinion.com/Opinions/GeoffreyRobinson/GeoffreyRobinson2.html

| > "When is a standard *not* a standard?".
| 
| When nobody uses it.

I don't see the logic here.


-- 
Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/]     
         "Det eneste trygge stedet i verden er inne i en fortelling." 
                                                      -- Athol Fugard

Re: The revolution will not be standardized

[Richard D Riehle]

In article <38561D9A.70B61403@acenet.com.au>,
	Geoff Bull <gbull@acenet.com.au> wrote:

>But Java is standardised too.

Of course it is.  It is standardized just the way 
MS Visual Basic is standardized.  

Oh, and notice how nicely English is standardized (-ised) 
from one country to another.

Richard Riehle
 

Re: The revolution will not be standardized

[Marin D. Condic]

Richard D Riehle wrote:
> Of course it is.  It is standardized just the way
> MS Visual Basic is standardized.
> 
Standards are such a wonderful thing that everybody wants to have one of
their own, eh? :-)

I'd think that for the term to be useful, it needs to imply some sort of
agreement between a collection of autonomous and even adversarial people
to adhere to some reasonably well defined set of rules.

How's that for kicking off another language war? ;-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: The revolution will not be standardized

[Greg Martin]

On Tue, 14 Dec 1999 10:00:18 -0800, "Marin D. Condic"
<mcondic-nospam@quadruscorp.com> wrote:

>Richard D Riehle wrote:
>> Of course it is.  It is standardized just the way
>> MS Visual Basic is standardized.
>> 
>Standards are such a wonderful thing that everybody wants to have one of
>their own, eh? :-)
>
>I'd think that for the term to be useful, it needs to imply some sort of
>agreement between a collection of autonomous and even adversarial people
>to adhere to some reasonably well defined set of rules.
>
>How's that for kicking off another language war? ;-)
>
I certainly hope it doesn't Marin because I believe you are quite
right. A standard is to be measured against and has to be open and
used to be of meaning.. The U.S. still clings (to some degree) to the
British Standard of weights and measure while most of the rest of the
world has gone metric. End result: more flotsam (or is that jetsam) on
Mars. 
Regards,
Greg Martin.

Re: The revolution will not be standardized

[Marin D. Condic]

Greg Martin wrote:
> I certainly hope it doesn't Marin because I believe you are quite
> right. A standard is to be measured against and has to be open and
> used to be of meaning.. The U.S. still clings (to some degree) to the
> British Standard of weights and measure while most of the rest of the
> world has gone metric. End result: more flotsam (or is that jetsam) on
> Mars.

The "language war" I refer to is the one that seems to get started up
here occasionally concerning defining terminology. Personally, I may
prefer not to spend too much time trying to get a consensus going on
what constitutes a "Standard" because I think I'll know one when I see
one. When I look at the ARM, I see something with a relatively high
level of standardization. Micro$oft Visual Basic on the other hand, has
a relatively low level of standardization. (I can't count on what it
contains from one moment to the next.)

As for flotsam on Mars, I thought I heard the latest problem was being
blamed on VxWorks. But I don't always have my ear firmly enough to the
ground to get the accurate dope on these rumors. (Maybe we could blame
the whole mess on the fact that VxWorks wasn't written in Ada? Or would
that be kicking someone when they're down? {It is, after all, the safest
way} :-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: The revolution will not be standardized

[Greg Martin]

On Tue, 14 Dec 1999 17:08:57 -0800, "Marin D. Condic"
<mcondic-nospam@quadruscorp.com> wrote:


>
>As for flotsam on Mars, I thought I heard the latest problem was being
>blamed on VxWorks. But I don't always have my ear firmly enough to the
>ground to get the accurate dope on these rumors. (Maybe we could blame
>the whole mess on the fact that VxWorks wasn't written in Ada? Or would
>that be kicking someone when they're down? {It is, after all, the safest
>way} :-)
I was refering to the previous attempt, blamed on a contractor who
didn't realise that the measurements given were in Metric. I hadn't
heard who was catching the blame for the most recent one. Personally I
believe all NASA's problems would be solved if they would only hire
middle aged programmers as astronauts (but I guess I should take that
to alt.pipedreams :-)
Regards,
Greg Martin.

Re: The revolution will not be standardized

[Ted Dennison]

In article <3856EA29.7B4C0A95@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:

> The "language war" I refer to is the one that seems to get started up
> here occasionally concerning defining terminology. Personally, I may
> prefer not to spend too much time trying to get a consensus going on
> what constitutes a "Standard" because I think I'll know one when I see
> one. When I look at the ARM, I see something with a relatively high
> level of standardization. Micro$oft Visual Basic on the other hand,
> has a relatively low level of standardization. (I can't count on what
> it contains from one moment to the next.)

Right. And the Windows API I'd say is even lower, because you can't
count on it even between releases, and if you are a competitor you *can*
count on it changing to hose you. What I see is Sun positioning
themselves where they *could* also do that if they so choose.

To try and drag this back to my original point, I think lack of open
standardization has just doomed Java. Perhaps it isn't obvious from
external signs right now, but  a little knowledge of history will make
it quite clear. (If you don't buy my argument, go read "The Last
Dinosaur and the Tarpits of Doom", particularly the "Historical Detour:
The Open Standards Steamroller" and "Microcomputers: The Valley that
Time Forgot" sections, at
http://members.tripod.com/adrianomerlotto/docs/lastdino.html )

Anyway, *given* that Java is doomed, wouldn't it be a good idea to be
positioning Ada as the alternative? The language itself is nearly as
portable, in some cases moreso. The portable API functionality is a bit
lacking, but certianly no moreso than any of the other alternatives.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Marin D. Condic]

Ted Dennison wrote:
> Anyway, *given* that Java is doomed, wouldn't it be a good idea to be
> positioning Ada as the alternative? The language itself is nearly as
> portable, in some cases moreso. The portable API functionality is a bit
> lacking, but certianly no moreso than any of the other alternatives.
> 
In the same sense that Visual Basic is "doomed"? ;-)

I think it would be useful to position Ada as a standard, portable
alternative to Java. The big problem is, as has been observed in the
past, that Ada doesn't come with fifty bazillion predefined, "standard"
classes and Ada doesn't come with a full-up, integrated development
environment. To some extent, this is changing, but it still remains a
hodge-podge collection of stuff that you have to pull together for
yourself.

What would you suggest as the strategy for positioning Ada as a
competitor to Java?

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: The revolution will not be standardized

[Geoff Bull]

Ted Dennison wrote:
>
> Anyway, *given* that Java is doomed,

Did you mean to post this to alt.what.have.you.been.smoking ?

Re: The revolution will not be standardized

[Robert Dewar]

In article <385F6039.65A1B1B4@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:
>
>
> Ted Dennison wrote:
> >
> > Anyway, *given* that Java is doomed,
>
> Did you mean to post this to alt.what.have.you.been.smoking ?


Well the statement in this generality is of course bogus, but
it is generally agreed that client java usage is decreasing
rapidly, and that this technology will not survive. Java will
likely find its place pretty much exclusively in server apps
and telephones :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Richard D Riehle]

In article <83od9d$1i8$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:


>Well the statement in this generality is of course bogus, but
>it is generally agreed that client java usage is decreasing
>rapidly, and that this technology will not survive. Java will
>likely find its place pretty much exclusively in server apps
>and telephones :-)

Robert,

Since you are the one who posted this, I find it credible. However,
I wonder if you can cite some sources.  It would be quite helpful
when dealing with current clients who have been deluded into thinking
they can replace some of their Ada efforts with Java.

Thanks in advance,

Richard Riehle
http://www.adaworks.com 

Re: The revolution will not be standardized

[Robert A Duff]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

> Since you are the one who posted this, I find it credible. However,
> I wonder if you can cite some sources.  It would be quite helpful
> when dealing with current clients who have been deluded into thinking
> they can replace some of their Ada efforts with Java.

Speaking of which, I've heard many people say that Java is just like
Ada, except that it uses C syntax.  That is nonsense, in my opinion:
Java inherits many error-prone "features" not present in Ada.

- Bob

Re: The revolution will not be standardized

[Robert Dewar]

In article <wcc66xruh8n.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
> Speaking of which, I've heard many people say that Java is
just like
> Ada, except that it uses C syntax.  That is nonsense, in my
opinion:
> Java inherits many error-prone "features" not present in Ada.


Naturaly it goes without saying that it would be VERY useful
if yoou could expand on the above statement :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Richard D Riehle]

In article <83sb2d$r1i$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>In article <wcc66xruh8n.fsf@world.std.com>,
>  Robert A Duff <bobduff@world.std.com> wrote:
>> Richard D Riehle <laoXhai@ix.netcom.com> writes:
>>
>> Speaking of which, I've heard many people say that Java is
>just like
>> Ada, except that it uses C syntax.  That is nonsense, in my
>opinion:
>> Java inherits many error-prone "features" not present in Ada.
>
>
>Naturaly it goes without saying that it would be VERY useful
>if yoou could expand on the above statement :-)

I did not originate that assessment of Java.  I think it was
part of some other posting earlier.  It is now so far from the
source, nested within some other reply, that I am not sure of
its origins.  

Java is not "just like Ada" with C syntax.  According to Tucker,
he sees some Ada semantics in Java.   Although Java has tightened
up some of the problems associated with C syntax and eliminated
some of the ambiguities, it is still fundamentally C syntax. 

Richard Riehle  
 

Re: The revolution will not be standardized

[Robert A Duff]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

> In article <83sb2d$r1i$1@nnrp1.deja.com>,
> 	Robert Dewar <robert_dewar@my-deja.com> wrote:
> 
> >In article <wcc66xruh8n.fsf@world.std.com>,
> >  Robert A Duff <bobduff@world.std.com> wrote:
> >> Richard D Riehle <laoXhai@ix.netcom.com> writes:
> >>
> >> Speaking of which, I've heard many people say that Java is
> >just like
> >> Ada, except that it uses C syntax.  That is nonsense, in my
> >opinion:
> >> Java inherits many error-prone "features" not present in Ada.
> >
> >
> >Naturaly it goes without saying that it would be VERY useful
> >if yoou could expand on the above statement :-)
> 
> I did not originate that assessment of Java.  I think it was
> part of some other posting earlier.  It is now so far from the
> source, nested within some other reply, that I am not sure of
> its origins.

I'm the one who wrote the "Speaking of which..." quote above.  Robert
replied challenging me to expand on that statement.  I could write a
book on the subject.  I didn't answer Robert because I don't have time
to be writing books right now.  ;-)

Anyway, here are some examples of what I had in mind.  These are cases
of error-prone features in Java that are not present in Ada.  Some (not
all) of these features are inherited from C.  My contention is that Java
went to a lot of trouble to eliminate problems in C that would cause
*security* problems, but Java didn't try very hard to eliminate plain
old *bugs*.  Or "programming mistakes", if you prefer.  ;-)

The dangling else problem.

Alternatives of a switch statement fall through, unless you use break --
but you almost never want to fall through.

No full-coverage rules on switch statements -- if there's no default,
it does nothing.

Everything's a reference, so everything is aliased.  (Well, *almost*
everything.)  Who knows what might hang on to a pointer to so-and-so?
In other words, the whole point of local variables is defeated -- local
variables can sneakily escape their scope, and you can't tell by reading
the code.

Elaboration/initialization rules.

Wrap-around semantics on integer arithmetic.

The integer types are, in general, very machine-oriented.  Bit-wise
logical operators and shifts have the same status as addition and
subtraction.  Ada's modular types have the same problem, but at least in
Ada, you can usually use a signed integer type for counting things and
whatnot, and get more reasonable semantics.  (Modular types are not my
favorite Ada feature.  Shall I post a diatribe on that point? ;-) )

21 is a different number than 2l.

0011 is different from 11.

Java encourages side-effects buried within expressions.

Container types lose compile-time type checking.  This is because there
are no generics.  (On the other hand, I must say: it's nice to have lots
of container types predefined and standard!)

No proper constant declarations (in the Ada sense).
No 'in'-mode parameters (because everything's a pointer).

No packing.

No named-notation calls.

I hate reading 10000000 when I could read 10_000_000 instead.

No subranges.

No new integer types.

No enumeration types.

================================================================

On the other hand, there are some counter-examples to my point above.
For example, Java makes a distinction between boolean and integers.
This is not necessary for security, but it does help prevent bugs, make
programs more readable, and all that good stuff.

Java also has some features that are *less* error-prone than Ada:

Garbage collection.

Treatment of uninitialized variables.

Declaring what exceptions are propagated.  (Although the design is
imperfect -- it leads to "crying wolf" too often, IMHO.)

No dead code allowed.

Fewer implementation-dependent cases.  Implementation dependence causes
trouble because it's easy to write code that accidentally depends on
some implementation-dependent thing, but happens to work using the
current compiler on the current machine.  Then the bug is found later,
after the original programmer has forgotten or gone.

================================================================

I guess the one thing I admire most about Java is its strict insistence
on portability.  I think that's a Good Thing.  On the other hand, in
practise, what matters is what implementations do, which is not
something the language designer can control.

- Bob

Re: The revolution will not be standardized

[Robert Dewar]

In article <wcc7lho9n4g.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
================================================================
>
> I guess the one thing I admire most about Java is its strict
> insistence on portability.  I think that's a Good Thing.  On
> the other hand, in practise, what matters is what
> implementations do, which is not
> something the language designer can control.

It is well known that complete portability can be achieved
with high level languages, the kind that people usually regard
as interpretive languages, e.g. SNOBOL-4. [side note, the work
on SPITBOL shows that it is possible in fact to compile such
languages successfully].

My feeling about Java is that it falls between two desirable
points, and thus is a bit of a failure in this regard.

If you want to take the hit for 100% portability, then do it
properly, and produce a proper high level language (something
with the flavors of SNOBOL4, SETL, APL, PROLOG, ABC, Python).
Don't end up with a low level machine oriented language which
still has 32-bit wrap around integers :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> It is well known that complete portability can be achieved
> with high level languages, the kind that people usually regard
> as interpretive languages, e.g. SNOBOL-4. [side note, the work
> on SPITBOL shows that it is possible in fact to compile such
> languages successfully].

"Complete portability" is impossible.  Different machines run at
different speeds, and have different amounts of memory.  Clearly the
speed at which a program runs, and whether or not it runs out of memory,
are user-visible properties.  But it is clearly impossible to define
them portably in a language standard, so of course no standard tries.

Of course, I know what you mean -- you mean *assuming* we don't run out
of resources, we can achieve complete portability, at the expense of
efficiency.  Fine.

Also, I think it is impossible, or at least infeasible, to achieve
portability with respect to interactions with the outside world that
depend on timing.  Any program that has a delay statement in it is
potentially non-portable, as is any program that uses true parallelism.
Any program that depends on the timing of mouse clicks or keystrokes is
potentially non-portable.  SNOBOL-4 isn't a multi-threaded language, if
I remember correctly.

Most of the computer science theory I learned in school imagined a
computer program as taking some input, grinding upon it, and then
printing out the answer -- a Turing machine or equivalent.  But real
programs nowadays interact with the outside world over a period of time,
which is a different thing.

> My feeling about Java is that it falls between two desirable
> points, and thus is a bit of a failure in this regard.

Yeah.  For example, it's strange to force almost everything into the
heap, and require garbage collection, and require growable arrays, but
then not have growable (arbitrary-range) integers.

But I actually don't think a language design *has* to choose a point on
that spectrum.  It can support many points on that spectrum.  Kind of
like Ada has chapter-13-ish kinds of stuff, but also allows you to
program at a much higher level when you so desire.

> If you want to take the hit for 100% portability, then do it
> properly, and produce a proper high level language (something
> with the flavors of SNOBOL4, SETL, APL, PROLOG, ABC, Python).

Well, I don't really want 100% portability, even in the sense of
ignoring timing and memory use and so forth.

The trade-off between efficiency and portability is an engineering
decision.  What I would like is to allow the programmer (rather than the
language designer) to make that decision, and to make it differently in
different parts of the same program.  In other words, I don't like (say)
Ada because it forces me to use efficient, machine-oriented,
error-prone, non-portable integers all the time, but I don't like (say)
Smalltalk either, because it forces me to use inefficient, portable,
safe integers all the time.  What I want is a language that gives me the
choice.  And I don't want to bias that choice against portability.  Of
course you *can* do arbitrary-range arithmetic in Ada -- it's just a
huge pain for various reasons.

> Don't end up with a low level machine oriented language which
> still has 32-bit wrap around integers :-)

I agree completely about integers.

But I was thinking of things like order-of-evaluation of actual
parameters.  In that case, Ada allows bugs to lurk where Java eliminates
them.  And I'm not convinced it *needs* to cause inefficiency.

- Bob

P.S. What would happen if this thread were cross-posted to
comp.lang.java, or comp.java.advocacy or whatever it's called?  ;-)

Re: The revolution will not be standardized

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> If you want to take the hit for 100% portability, then do it
> properly, and produce a proper high level language (something
> with the flavors of SNOBOL4, SETL, APL, PROLOG, ABC, Python).

Some of the above languages you mention are very special purpose, so
they don't count, in my mind, when discussing the design of general
purpose languages.  I don't think SNOBOL should be a "language"; it
should be a set of library routines inside a general-purpose language.
In fact that's exactly what you've done with GNAT.  And I'd rather use
those GNAT libraries than use the real SNOBOL4.  Important things like
reasonable control structures are missing from SNOBOL4.  Similarly,
PROLOG is often embedded in Lisp, is it not?

- Bob

Re: The revolution will not be standardized

[Robert Dewar]

In article <wcc7lhmizbc.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
>Some of the above languages you mention are very special
purpose, so
> they don't count, in my mind, when discussing the design of
general
> purpose languages.  I don't think SNOBOL should be a
"language";


You just don't know SNOBOL4 well, or you would not make this
statement. Of *course* SNOBOL4 is a general purpose language.
Yes, people who only have a surface acquaintance with the
language think of it as being specialized to string processing
and that pattern matching is the only interesting feature, but
this is bogus.

Indeed Robert Dewar's important rule for writing SNOBOL-4,
well known in that community is "Don't use pattern matching".
What this rule means is that unlike the case in SNOBOL-3, it
is wrong to write complex algorithms as pattern matches in
SNOBOL-4.

The most interesting features of SNOBOL-4 to me are the
generalized mappings (the TABLE function), a VERY important
feature in programming languages as is known well from the
SETL family of languages (SETL/ABC/Python), and the DATA
facility for creating programmer defined data types. The
latter are particularly interesting, they are record types,
where member names are functions that can be applied to
any record type sharing the same member name. This can be
used to construct quite interesting structures, including
for example the possibility of multiple dispatching.

Finally, the most important feature of SNOBOL4 is its highly
dynamic nature. Someone once said that the design of SNOBOL4
is "never do anything at compile time if it can be left till
runtime". The dynamic definition of functions, and the
EVAL/CODE functions, familiar from the LISP family of languages,
are very powerful additions to expressive power.

The SPITBOL packages in GNAT are handy for providing a very
limited subset of the SNOBOL4 capability, namely string pattern
matching, but please please do not confuse this with providing
anything approaching the expressive power of SNOBOL4. That's
simply not possible in a low level language like Ada :-)

I would guess that Bob's other comments about my list of
languages being specialized is also based on inadequate
familiarity with these languages. For example, people who
don't know APL often dismiss it on the grounds that it is
just a specialized gizmo for dealing with arrays, but in
fact APL also is a powerful general purpose very high level
language with extremely interesting ideas on data aggregation.
APL demonstrates that you can replace a lot of traditional
algorithm messing with complex data structures by powerful
manipulations on much more regular data structures.

It's a pity how unfamiliar people are with the general notion
and feel of very high level languages (calling them simply
high level languages is admittedly deliberately provocative :-)
And it is surprising how much programming is done in low level
languages.

Java is a particular disappointment. If we are at the stage
where we can afford the kinds of fundamental inefficiencies that
the Java approach involves (and that people have run into with
Java), then we could have had a far higher level language that
would have allowed Java applications to be written far more
compactly and reliably. As it is Java suffers from most of the
disadvantages of both worlds -- the need to write things down
at a low level, worrying about data structures, and the
inefficiencies of generalized "interpretive" execution. The
"intepretive" is in quotes here, because of course Java can
be compiled, but then any interpretive language can be compiled
(SPITBOL/360 demonstrated that a long time ago, and the
technology of compiled APL is well established at this stage).

I believe that if Java had been designed from the start with its
eventual deployment in mind, it might have turned out very
differently. Of course the emphasis on reference rather than
value semantics is a matter of taste. For me, going more in
the direction of reference semantics is a huge mistake.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Robert Dewar]

In article <wcc7lho9n4g.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
================================================================
>
> I guess the one thing I admire most about Java is its strict
insistence
> on portability.  I think that's a Good Thing.  On the other
hand, in
> practise, what matters is what implementations do, which is
not
> something the language designer can control.

--------------------------

Well sure you can get complete portability if you sacrifice
efficiency. For instance, in the case of floating-point,
the Java rules have drastic effects on efficiency of
floating-point code on the x86, and *that's* an IEEE machine,
you don't even want to think about Java on a non-IEEE machine.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Ehud Lamm]

|In article <wcc66xruh8n.fsf@world.std.com>,
|Robert A Duff <bobduff@world.std.com> wrote:
|> Richard D Riehle <laoXhai@ix.netcom.com> writes:
|>
|> Speaking of which, I've heard many people say that Java is
|just like
|> Ada, except that it uses C syntax.


Yeah. The generics Java has are of course a direct translation from Ada. 
Now if only they were documented somewhere...

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

gnat 3.12

[Michael Ben-Gershon]

Has anyone found a way to build gnat 3.12 on top of gcc-2.95.2?
The distribution has instructions for gnat-3.10, but not for
the more recent 3.12.

Many thanks,

Michael Ben-Gershon
mybg@netvision.net.il

Re: gnat 3.12

[Robert Dewar]

In article <3862044A.2A1E06AA@netvision.net.il>,
  Michael Ben-Gershon <mybg@netvision.net.il> wrote:
> Has anyone found a way to build gnat 3.12 on top of
gcc-2.95.2?
> The distribution has instructions for gnat-3.10, but not for
> the more recent 3.12.


There is no point in messing around with this. Even if you
managed to get it working, there are some significant bugs
in gcc-2.95.2 so you would get an unreliable result.

GNAT version 3.12 is specifically designed to be built with
GCC 2.8.1. Right now, there is concentrated work going on
to create a unified gcc build that will contain all the
necessary fixes and patches from GCC 2.8.1, as well as the
new features and fixes from the EGCS development. A future
version of GNAT will be built using this merged version.

Meanwhile, the advice is to use GNAT as distributed and
built with GCC 2.8.1. If you want to use g++ built with
gcc-2.95.2, that's fine, and if you want to link gnat and
g++ stuff together that also works fine, see GNAT documentation
for details.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Ted Dennison]

In article <3856d861.30417176@news.netidea.com>,
  gregm@netidea.com (Greg Martin) wrote:

> world has gone metric. End result: more flotsam (or is that jetsam) on
> Mars.

Perhaps we need a new word for space debris, like "nassam". :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[reason67]

In article <38561D9A.70B61403@acenet.com.au>,
  Geoff Bull <gbull@acenet.com.au> wrote:

> > On Mon, 13 Dec 1999 16:06:54 GMT, reason67@my-deja.com
> > <reason67@my-deja.com> wrote:
> >
> > >You have the freedom to choose to use Java under the
> > >restrictions put on it by Sun.
>
> In that sense, just about anything is free!

This is a bit off the Ada topic and I would be happy to go into more
detail in private email. Freedom is the absense of coercion. So, anytime
someone initiates force or a threat of force, you are not free. Free
market agencies always leave people free. Coercive monopolies (those
licensed by a government) would limit freedom.

The reason I responded orginally is that it bothers me when people claim
that they are not free when companies have restrictions on what they
produce. Some goes as far as the advocacy of forcing people to "free"
their code.
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The revolution will not be standardized

[Geoff Bull]

Ted Dennison wrote:
> 
> > Since Java is now free, in the monetary sense, we have 1001+
> > amazing standard APIs simply by calling Java's APIs.
> 
> Yes, but is it free in the freedom sense?
> 
No. Sun want to keep *their* freedom, which is why they bailed out of
the ECMA standardissation process (and ISO before that).

Read the licence and see what it means for you.
You can get the source too, but of course there are
strict conditions on what you can do with it.

Cheers
Geoff