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:
Geoff Bull <[log in to unmask]>
Reply To:
Geoff Bull <[log in to unmask]>
Date:
Fri, 18 Sep 1998 12:15:16 +1000
Content-Type:
text/plain
Parts/Attachments:
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
longbefore
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
decision.

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
through.


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
understanding.

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
amazing.
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
this?)

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

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

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 com.sun.java.swing
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
though.

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
multiplies).
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
invented
the next great thing.

cheers
gb

ATOM RSS1 RSS2