Re: A measure of Ada's death in the database world

Re: A measure of Ada's death in the database world

[John Goodsen]

>
>     There is a new micro/worky/mini database tool out called 
>"Q + E Database Library" from Pioneer Software (919-859-2220).  It's
>getting some good exposure for solving a common problem.  Their product
>is a Application Programming Interface between languages and databases
>for client server applications.  Their one product gives developers much
>independence.
>
>    They support the following databases: Oracle, dBASE, SQL server, Sybase,
>DB2, Paradox, INGRES, SQL/400, Btrieve, Excel, Informix, Netware SQL, 
>OS/2 DBM, Progress, SQLBase, SQL/DS, Text files, Tandem NonStop SQL,
>Teradata, HP SQL, and XDB.  Obviously the company's comprehensive
>coverage reflects market realities of database acceptance.
>
>    They support the following languages: Visual Basic, Toolbook, Power
>Builder, ObjectView, Actor, Smalltalk, CA-Realizer, Plus, SQL WIndows,
>C, C++, Pascal, Prolog, GFA BAsic, Word, Excel, 1-2-3. Obviously the company's
>comprehensive coverage reflects market realities of language acceptance
>and market opportunties in the future.  And Ada isn't on their list.
>

Well, there *ARE* database solutions happening for Ada customers.  In
particular, we are about to release version 1.0 of ITASCA/Ada, the Ada
API to the ITASCA Distributed Object Database Management System.
ITASCA provides a network peer-to-peer, truly distributed, LANGUAGE
INDEPENDENT mechanism for storing object oriented data.  ITASCA/Ada
database schemas are extremely flexible, and can be modified on the
fly while applications are executing without taking down an
application to make the changes.  You can change inheritance
hierarchy, object structures and methods of an object on the fly.
Versioning of objects is supported as is the storage, searching and
retrieval of multi-media data, including images and sound.  ITASCA/Ada
is an active database, which means that methods are stored and
executed within the context of the database.  There's much more
but I think you get the jist.  

Granted, there is a lot apathy in the DoD Ada community, but I 
even so, there are companies like EVB who believe in Ada technology 
and are willing to make the the investment to provide Ada solutions
to the community.  

My complaint (which does not necessarily reflect the view of our entire
company), is that efforts such as 9X are missing the boat on a few
key areas which I consider crucial to maximize the potential of
Ada in the Object Oriented programming community.  In particular,
(once again), "tagged types" is a term which turns stomachs in all but the
most hard core Ada programmers and the lack of *DIRECT* support for
multiple inheritance will inhibit solutions for Ada to interact with
existing Object Oriented systems through a binding layer, in particular
most popular OODBMS systems *and* next generation GUI libraries that
are written in C++.   We can't afford to re-write everything in Ada.
I see a lack of anticipation of Ada integration with next generation 
GUI libraries and ODBMS's in the 9X project, and given that a GUI takes up over
 50% 
of the code in an application, then I might say that Ada 9X is going to 
miss the boat in providing the capability for GUI developers to reuse a large
amount of next generation user interface technology that is now
coming out in the form of C++ and CLOS libraries...

Yes, I've seen the kludges on how to *implement* multiple inheritance
in Ada.  Haven't seen how I can map it to an object code library which
requires an MI Ada binding layered upon it, however, and besides, if
I can do it through a kludge of following a programming style, then
why not just put it directly in the language?  Oh well, maybe in Ada 200x...

for example:

   class type X is new A,B,C;
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
   Which means, create a class type X which directly inherits from
   class types A,B and C.  Simple and to the point.  And given Ada
   compilation rules, a compiler can pull out potential innefficencies
   of an implementation at compile time..., so please think out your
   innefficiency flames before you post them... thanks.

$.02 for multiple inheritance (again)






-- 
John Goodsen                EVB Software Engineering, Inc.
jgg@evb.com                    - Ada & Object Oriented Training/Products
(301) 695-6960                 - Ada GUI & Graphics Tools and Training
                               - Software Reuse, Process & Environments

Re: A measure of Ada's death in the database world

[Robert Dewar]

	class type x is new a,b,c;

Well first of all, that syntax isn't quite right, since it doesn't allow
for extensions, and also we don't use class in 9X in this way, so what I
would expect would be something like:

	type x is new a,b,c with ...;


It's easy enough to write syntax like this, but there are big semantic problems
and big implementation problems (just to mention a couple, what about virtual
base classes, and how do you avoid distributed overehead from the *possibility*
of MI even if it isn't used -- C++ compilers usually pay such a distributed
overhead).

It's these semantic and implementation problems that make one think twice (or 
perhaps ten times) before including MI in 9X. I certainly haven't seen anyone
complete a thorough design for such a feature which addresses all these
problems.

The real question is whether it is worth it. The post that this responds to
talks about using kludges, but one guys kludge is another guys elegant
approach. For instance, to an Ada programmer, having to use classes in C++
for what are better represented as packages, and then having to use multiple
inheritance for what is better represented by multiple package dependencies
is indeed a kludge -- but the kludge is in C++, not in Ada.

Despite a lot of attempts and requests, the discussion of MI in 9X has
generated a lot of suggestions that it should be included, but precious
few examples of programming examples that make this case in even a
semi-convincing form.