Re: is Ada dying?

[James Rogers <jimmaureenrogers@worldnet.att.net>]

"Robert*@" wrote:
> 
> The Java classes are well documented. Much better than anything Ada has
> actually.

The Java classes are documented about as well as an Ada package
specification documents an Ada package. I am speaking of the HTML
API documentation generated from javadoc.

Of course there are textbooks which expand on that documentation,
just as there are Ada textbooks which expand on the information
contained in the standard package specifications.

> 
> As for the algorithms, why would you want to know the inner algorithm
> for how a class or a method is implemented? The whole idea is to use
> it as a black box. Does the Ada RM describe the algorithm for the
> unbounded string?

Pure black box usage is dangerous. It is particularly so with the
Java standard classes. You might make the mistake of using the String
class for string editing. A clear understanding of the String class
shows it to be very inefficient for string editing. The StringBuffer
class is intended for string editing. What is the difference between
the two? In many applications with a lot of string editing, the
performance increases by a factor of up to 5 using the StringBuffer
class.

> 
> I find that I can much easier find a class in java to do something, than
> I can find a function in Ada to do something.  Have you looked at the
> Java class libraries books by Patrick Chan and Rosanna Lee?  Each
> class and almost each method comes with a usage example. There is nothing
> like the above for Ada (or for almost anyother language actually).

The javadoc tool is very useful. It localizes the documentation of
the standard Java classes. The same can be said for the Ada RM.

It is true that Java has more standard classes than Ada has
standard packages. It is also true that all those standard Java
classes are available to Ada compilers targeted at the jvm.

> >>Having a central single place to get things from is a Good Thing (tm). Examples
> >> of such things
> >>
> >> http://www.sunfreeware.com/   <--- Want any solaris package? go here
> >> http://java.sun.com    <---  Want the JDK? go here
> >> http://www.gnu.org/software/java/  <--- Want the GNU java collection? go here
> >> http://www.gjt.org/  <--- want the Giant Java tree collection? go here
> >>
> >> etc..
> >
> 
> >Wait a minute while I count my fingers and toes. It looks to me like
> >this is a list of more than one place to find everything. Am I
> >missing something here?
> >
> 
> Yes, you are missing something.

Yes I am missing the concept that a list of four sites followed by
"etc.." is exactly one. This is a feature of Java I have always 
found distasteful. The Java white papers, and subsequent Java
supporters, have often made statements which are contrary to the
normal usage of English. The example above declares that four or
more sites is a single location. This is pure nonsense.

The Java white paper uses a lot of unsupported buzz words to
describe Java. Some of my favorite are "simple" and "high 
performance". Java is not a simple language. There are thousands
of standard classes to learn. Java is not high performance.
It is simply faster than a dial-up network connection.

What I am missing is an honest and accurate use of the English
language.

> 
> >This looks a lot like finding the Ada package you want.
> 
> No it is not. Show me an Ada site that is like java.sun.com. I know it
> is not fair for Ada to ask for this, given that even C++ does not have
> anything like that site, and C++ is much more used than Ada.

Well, I would say that adapower.com is pretty close. In fact, I
believe adapower.com is a better starting point in a search for
Ada information than java.sun.com is for Java information. There
are relatively few links to non-Sun sites on java.sun.com.

> >
> >Given what you describe above, I would say that Ada already has that.
> >
> 
> If you think the current state of Ada packages and libraries is good
> enough, I am happy for you. I am not arguing with you, I am only giving
> an advice to the Ada community to help.

You are now changing the subject. The statement I responded to 
indicated that all Java information could be found in one place.
The statement included a list of four places. I still do not agree
that one equals four. 

The current state of Ada standard packages is very good. It is 
not as extensive as the set of Java standard classes. 
Quality and quantity are not the same thing.

For instance, Java provides several GUI packages useable in
applets. The classes in the java.awt package hierarchy are
useable in most browsers. The javax.swing classes are supposed to
be useable in all browsers, but browser support for these
classes varies. Note that applets (and servlets) also require you
to learn another language, namely HTML. If you want to move to
a more modern web server approach you can use JSP's, which
require you to learn XML.

The biggest problem with browser support of java applets is the
differences in HTML required to support the Swing classes.

> >It also has a standard, which Java does not.
> 
> Java has a standard, it is just not an ansi nor iso. But who cares. If you
> think having an iso or ansi stamp on the language will suddenly make it
> popular, then I am afraid you are completly wrong. Show me the
> VB standard out there, yet millions use VB to this day.

This is more Sun propaganda. Sun has a history of avoiding formal
standards. They like to play in the arena of "defacto" standards.
This means that they can produce a product and publish an API
document for it. Once done, they call the product a standard.

Only Sun can decide what is Java and what is not. Only 
Microsoft can decide what is VB and what is not. This is the
antithesis of open source. This is also forcing those using
these tools to put complete trust in Sun and Microsoft. You 
have no input to the new features for the language. You only
have the ability to report language defects if you pay for
that privilege.

> > Most of the Java stuff
> >is in a single place because the language belongs to one company.
> 
> Programmers do not care. Programmers want support, good documentations,
> good packages from one cetralized and managed place. What you call that,
> is not important. The last thing I worry about with Java is that it is
> controlled by Sun.

Yes, but those downloading the free tools do not "get support".
They must buy support, just as they must for other languages.

> 
> >Java is whatever Sun says it is. Given the changes in the language
> >from Java 1.0 to Java 1.1 to JDK 1.2 to JSDK 1.3 to the almost
> >released JSE 1.4, I wonder which language you use when you say you
> >use Java.
> 
> I think your arguments are very week. Java has improvments being
> added to it all the time. More packages and more libraries. You seem
> to think this is bad. I say, a language that does not grow and improve,
> and adopt to the technolgy, will die for lack of use and interest. Note
> also, most of the additions to java are in the libraries, not the
> language anc certinally not in the JVM.  Generic are being now
> added to Java, and will be part of JDK 1.5.  It is a good thing.

Generics may or may not be a good thing in Java. Interestingly,
they will have a definite Ada flavor, rather than a C++ flavor.
This is due in part to the fact that Norman Cohen has been 
actively involved in the definition and development of Java
generics.

I expect JDK 1.5 to be released some time in 2002. In terms
of generics this will allow Java to catch up to Ada after a mere
20 years.

Note that up to this point Java supporters have been claiming 
that generics are unnecessary. They believed their 
inheritance model subsumed all requirements for generics. Could it
be that they were wrong? There must be some reason for adding
generics to JDK 1.5.

This is more evidence to me that Java is a language desparately
working to live up to its press releases. For seven years Java
has claimed the flexibility and extensibility provided by
generics without having generics. Now they are adding generics
to provide what is best provided by generics.

Similarly, Java has staunchly declared no need for a separation
of specification and implementation. There have been several
exceptions to this rule. You MUST create a Java interface to
call a C library from Java. You MUST create a Java interface
to create and deploy Enterprise Java Beans. You MUST
create an interface to use the Java event model.

Such redifinitions of the language make programming in Java
an adventure in learning.

> 
> >Don't forget that you need standard patches to do some of
> >the more useful stuff. For instance, you must patch the JSE 1.3
> >with JSEE 1.3 to be able to use Enterprise Java Bean technology.
> 
> No you dont. I use J2EE 1.3 on JDK 1.3 just of the box.

Look at the java.sun.com web site. You will find that the
J2SE 1.3 download is separate from the J2SEE 1.3 download.
You must first download J2SE 1.3, followed by J2SEE 1.3 if
you want to use Enterprise Java Beans. You cannot simply download
one or the other.

> 
> >This means that your client's Java Runtime Environment must
> >have the compatible libraries also. A big part of your Java system
> >is shipped to your customers as the Java Runtime Environment.
> >This presents you with serious compatibility and upgrade issues.
> 
> I have no idea where you are comming on with all of the above. Millions
> of programmers use Java all the time and each day, yet you seem to have
> a problem with it.

I have nothing against the use of Java in its appropriate domaines.
I do have issues with the way the Java community has misappropriated
the English language. Many people use Java thinking they 
understand what is meant by that language. For instance, one local
manager decided to re-write all his Cobol programs in Java.
This meant retraining his entire IT staff. After making the 
decision he asked the question "What will be my performance
improvement?" Unfortunately the answer to that is about -30%.

Jim Rogers
Colorado Springs, Colorado USA