TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
"W. Wesley Groleau x4923" <[log in to unmask]>
Fri, 18 Sep 1998 12:15:16 +1000
Geoff Bull <[log in to unmask]>
text/plain; charset=us-ascii
Geoff Bull <[log in to unmask]>
text/plain (185 lines)
W. Wesley Groleau x4923 wrote:

> > The "Purity" Measure
> > ====================
> > Conclusion: Java and Ada aren't really so far apart here after all. But I
> > still give Java a slight edge on the "purity" scale. If "purity" sounds too
> > subjective (and thus irrelevant) call it "consistency and ease of use."

I have seen an argument that Ada is not OO because it uses syntax like

method_name (object_name, args ...)  instead of   object_name.method_name(args ...)

> > Dynamic Class Loading
> > =====================
> >
> > Well, help me here. In Java, I can create an object at run-time whose class
> > didn't even exist at compile time. For example, I can prompt the user for a
> > String and then use that String as an argument in the Class.forName method.
> > Once I have the the Class object, I can call its newInstance method. I believe
> > the technical term for this is "Way Cool". That seems like a language feature
> > to me but I realize I may be missing something.

I have seen this sort of "way cool" feature with dynamic linking to shared objects
Java was even a twinkle in James Gosling's eye.
Admittedly Java's mechanism is simple to use.

> > Wacky C Syntax I
> > ================
> >

I suspect that Java would not have been successful if it didn't have the smell of C around
it.So, although I hate the syntax, I believe the language designers made a correct

Java culture seems to generate more understandable identifier names than C.I can't
understand though why white space and underscoring tends to be
used very little to improve readability.

Case sensitivity is not to my taste.
e.g. java.awt.event and java.awt.Event are two different things (a package and a class)

Perhaps a good compromise would have been to enforce case consistency,
and disallow identifiers that differ only in case.

> > Specifications compilable before implementation
> > ===============================================

It is very easy to accidentally change specifications in Java.

> > Enumerated types, non-Zero-Based Array Indices
> > ==============================================

Wonder why they left them out?

> > Object Equality
> > ===============

Personal I find writing "if (a.equals (b))" instead of "if (a == b)" ugly

Numerics Support
Java requirement that answers be exactly the same on all platforms is a definite problem.
E.g. Java won't allow you to take advantage of 80 bit fp on intel platforms.
       Won't allow use of multiply-add instructions that might carry more precision

Representation Specification
The bit bashing that I had to do for one Java project made it very hard to understand
and a pain to change - it would have been fine, except I knew there was a better way.

> > Operator overloading
> > ====================
>  Java takes away a valuable capability because programmers
> > >      abused it.

Trouble with C++ was it allowed overloading of ALL operators and has a wide defination of
operator.Reading code that has () or [] overloaded generally leads to very slow

Overloading on Return Type
Even though return type is included in signature two methods with same name
must differ by more than just the return type. This leads to swags of methods that have
the return
type encode in the name.

> > Access-to-subprogram that is fully type safe and nesting safe
> > =============================================================.
> Java "rejected access-to-subprogram because it wasn't safe." (not in those terms)

You can get an inefficient form, if you use reflection - can't remember if that is safe.

> > Tasking
> > =======
> >
> > The usual points...

What are these?

I find the fact that Thread.setPriority () is not guarantted to have any effect truly
I have one Java program that absolutely depends on thread priority to work - I decided
to sacrifice portability, rather than waste time figuring out a complicated work around.

> > The OOP inheritance mechanism is independent of the encapsulation mechanism
> > ===========================================================================
> > > Java classes cannot share private data like two or more Ada types in one
> > > Ada package.  In Java, the methods and instance variables are encapsulated
> > > within the class, which corresponds to ONE Ada type as well as ONE Ada
> > > package.

You can get a similar effect using inner classes.Unfortunately,  inner classes require an
instance of the outer class to exist before you can use them.
E.g. a class cannot have a static instance of an inner class.
Also, instances of inner classes can only exist within their outer class (am I correct on

Generics /Templates
Lack of this facility leads to code copying, which reduces productivity of both
initial coding and maintenance.

Only unsigned type is char - this is a huge pain when tou really need to do unsigned

Only form of abstraction requires heap allocation - ridiculous for class Complex. This
also deters the performance conscious from using any abstraction.

Bounds checking is limited to arrays only - I have to roll my own for anything else.
Even integer arithmetic silently overflows.

Loose typing of primitives: e.g.
long foo = 0x00000000ffffffff;  // surpise! foo == -1

no package renaming - witness current problems with change of name of
to javax.swing. Also, lack of this leads to importing everything and subsequent
readability pronlems.

no default values for arguments

no named association of arguments - non Ada programmers don't seem to care about this

no explicit elaboration contol - this makes some initialisation issues non-obvious.

interfacing to other languages is very messy (with JNI)

easy to make typos change meaning rather than create illegal program.

performance - BEST I can get out of Java (with JIT compiler) is half as fast as Ada or C.
( I did some tests to debunk claims that Java was faster than C at numerics,
I don't know what code the original claim was for, but it doesn't work for matrix
At least the Java version of my mini benchmark worked first go, which is more than you can
say for the C.

Lastly, I am laughed at everytime I mention Ada:
Ada is HUGE, Ada takes too long to learn, Ada is too verbose, Ada takes too long to write,

Ada is ugly, Ada projects frequently fail, Ada is slow, Ada is not OO, nobody uses Ada,
if we learn Ada we won't get a job anywhere else, etc, etc.

So, I mostly program in Java, which I consider to be an inferior languagein many respects
(to Ada),
although it is generally a great improvement on C/C++.

Personally, I think we should take Ada, call it something else, and claim we have just
the next great thing.