Re: Is the Writing on the Wall for Ada?

[David Marceau <davidmarceau@sympatico.ca>]

Hyman Rosen wrote:
> 
> Russ wrote:
> > First of all, Java forces everything into the "object-oriented" mold
> > whether it fits or not.
> 
> Not true. It's easy enough to make class methods be static, and then
> you've got the equivalent of a package with variables and procedures,
> if that's what you want. You can also declare your class methods to be
> final and accomplish about the same thing. So there's no real forcing
> of OOness.
> 
> > it has no separately compiled specification files
> 
> That can be programmed by using interfaces. Write your specifications
> as interface classes, then write the implementations as implementing
> the interfaces. Works fine.

I beg to differ that it works fine just as is.

The concept of the keyword "interface" is something that is highly
documented and truly borrowed from the Microsoft COM/OLE methodology and
probably .NET also.
Interfaces are the way to separating the differences between versions of
components.
The suggested programming lifestyle of COM/OLE/.NET is if you need to
change the behaviour of an existing interface for a component, then it
is usually better actually to create a new interface and keep the old
interface intact.  This is very important for runtime compatibility of
different versions of an application.
The impacts of running an old application with new libaries swept
underneith usually leads to havoc when old interfaces are not preserved.
In fact I would imagine this is where the java developers borrowed the
keyword interface because deep down in the Java Native Interface jni.h
you can see remnants of the OLE/COM variant type structures embedded
into the standard all-encompassing JObject.
If you haven't read Inside OLE I suggest you do it for its perspective. 
There is a much good material in there considering versioned binaries
and architecting forward version binary compatibility.  The recipe you
gave above is exactly the recipe for c++.
In ada it is the case that when you build the app usually you have all
the sources to your disposal so this isn't much of a concern is it? ;)
In java however on more than one occasion I have had my infrastructure
crumble underneith me because the RAD spiral development was spiralling
like crazy.
The interfaces and their behaviours were changing left right and center
without prior notice and completely undocumented.  One advantage over
ada is that much deliberation is placed on thinking about the
specification before implementing it.  Lots of docs support the ada
process usually.  Java is somehow more like visual basic and more
freestyle because it encourages you try a bunch of things on the fly
without much consideration about the impact one's code has on other
members in a team when reinserted into the source control system and
also without any documentation to show for these changes.  Changes like
these would never happen if using ada because usually that assume you
are using process/methodology that explicitly forces you to document
what changes you have made.  The way the dependencies are checked and
built against with an ada compiler is still much better when dealing
with lots of source IMHO.  It's much to do with process also.  When
working with java it is almost as if one was encouraging freestyle
methodology and when you write something is compiles successfully too
easily.  That said it doesn't guarantee that the java application will
run...

I must say the successful construction of an application not only lies
on the language used but also on the methodology/process used.
I like to refer to the methodology/process used as the "programming
lifestyle" which all members of the team must adopt in order to the
project to be a success.

IMHO again Ada will probably succeed more because usually more
deliberation is placed in programming lifestyle when using Ada.  Not all
programmers but there are many freestyle java /c++ coders out there but
when they get together in a team IMHO it's just havoc.

I have placed a lot of effort describing this "interface" feature here
because it is among the most important features any language could have
and to make work efficiently among team developers.  Ada has their way
of doing this stuff and IMHO it is again a better way ;>  I won't waste
my breath repeating the oodles of ada rationale docs.

Cheers,
David