Re: Future with Ada

["Mark Lundquist" <no.spam@getalife.com>]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9vb24v$7fg$1@nh.pace.co.uk...
>
> I agree that it would be nice to have a large library of stuff just as
does
> Java. In particular, some version of a standard GUI library of some sort.
> One of the problems with doing this is that Ada targets a whole slew of
> computers not all of which would have such a library make sense. Even for
> the platforms for which something like a GUI does make sense, you still
> might have problems specifying something that is portable and still makes
> reasonably good use of what is actually available on the given platform.
> Windows GUI stuff, for example, looks very different from what you get
under
> Motif. Would a "standard" GUI library be able to work on both without
> restricting itself to some unacceptable subset of what is possible? Would
> Windows programmers/users want something that didn't look a lot like a
> typical Windows app?

You're right, AWT/Swing account for a large part of the JCL.  And
cross-platform GUIs are a big hairy rat's nest, for the reasons you mention.
But I think there's plenty a standard Ada library could focus on that's more
fundamental than GUIs.  I'm interested in things that help with programming
the "under the hood" stuff, and I'd just as soon let the GUI stuff alone for
the time being...

> (GtkAda works in a variety of places, but it doesn't
> seem to look a lot like "Windows" when its on that platform. Is that going
> to be a handicap?)

Well, GtkAda is an Ada binding to Gtk, and Gtk was (I think) meant to be
Motif-alike for Linux, not designed as a cross-platform GUI (I could be
wrong about this, I'm sure someone will correct me if that is the case :-).
The point being, whatever can be said about GtkAda in this regard can also
be said about Gtk.  You wouldn't look to GtkAda to solve any problem that
Gtk itself was not designed to solve.

I think any true cross-platform GUI (regardless of implementation language)
is not going to take the approach of building on top of Windows and Motif
bindings and lifting out a "common denominator" subset.  Rather, it would
bypass the Windows and Motif widget sets and go all the way down to pixels.
Its internal architecture might have pervasive capabilities for emulating
Motif of Windows LAF as much as possible, but it would be a stand-alone
native GUI for running inside Windows frames or X-Windows clients.

As a matter of fact, a native GUI is the route that Java chose.  They could
have tried to isolate a "common denominator" subset and then translated it
to Windows or Motif bindings, which would have resulted in the problems you
mention.  Instead they created a new native GUI that was supposed to look
just as good on either platform.  The early versions were a qualified
success -- they did look "just as good" on either platform, that is to say,
not very good -- but things are better with Swing.

>
> So I think there is a problem with getting large libraries of stuff
> "standardized" in Ada.

For the GUI stuff, you mean?

> To get it into The Real Standard, it would have to a)
> reduce itself to the lowest common denominators for the platforms on which
> it was possible and b) exist as an optional annex so it could be
eliminated
> for platforms on which it was difficult or impossible to implement. (I
don't
> see "b" as being a big problem - but there may be other opinions on
that...)

Of course there is a standard library today, specified in the Annexes --
it's just meager, that's all.  But that standard library is not monolithic;
the Predefined Language Environment (Annex A) is required, and the parts of
the standard library specified in the specialized needs annexes are
optional.  I view things like collections as foundational and not dependent
on platform capabilities, so they should go into the predefined environment.
If there were ever a GUI, it would be a special needs annex.

>
> The other alternative - a de facto standard - might be a better choice.
For
> example, you could have a "Windows-GUI" library and a "Motif-GUI" library
> that assumed the capabilities of a given platform and compiler vendors
would
> have to come to some kind of agreement that if they were putting out a
> Windows targeted compiler that they would support the appropriate
"standard"
> library. But this, in and of itself, has problems. It creates portability
> between compilers - but that's not necessarily in the interest of the
> vendors and may not be that interesting to the consumers. It certainly
> doesn't provide portability across platforms - which might be of varying
> levels of interest to the consumers.

For foundational stuff (like collections), I think a de-facto standard would
be OK only if it were perceived as "standards track".

The "package" of a great core language plus a great standard library is just
so much more compelling than that of a great core language plus a lot of
random freeware (a point you make below...).  It's the total package, not
just the core language, that people look at when making a decision.

At SIGAda '99 there was a paper by somebody who had done a study of U.K.
defense firms who had essentially "not chosen Ada", and the study ranked the
perceptions that contributed to that decision.  Lack of a decent standard
library ranked among the top three reasons.

>
> Besides, no matter how much discussion there is around here about the need
> for semi-standard libraries, we never seem to hear anything from the
vendors
> indicating that they are at all amenable to the idea. If they won't get
> behind it, the issue is dead. We already have lots of libraries of Ada
code
> available for the cost of a download, but that leaves the end-user
bumbling
> around, cobbling together a development environment of dubious quality and
> consistency.

Exactly.  "Great environment to be had for the cobbling" just doesn't cut
it.

For the vendors to get behind such an initiative would take one of two
things, either (a) the paying user community clamoring for it, or (b)
incorporation into the standard.  In practice this amounts to much the same
thing, since (a) will have to hold true for any candidate for (b) :-).  In
fact, (b) in and of it self has much less leverage since the dropping of the
Ada "mandate", which "statutory validation" was designed to support.  In
theory, a vendor could say "we don't support the full standard; big whoopie
ding," although even with an attitude like that toward an expanded standard
library, the presence of a freely redistributable/modifiable reference
implementation would probably go a long way towards making it a no-brainer
for a vendor.

> So I'm not sure how to get there other than by doing what is happening in
> one small corner of this newsgroup with respect to the idea of an Ada
> Standard Components Library

I think that's actually a pretty good way to get there.

Best Regards,
-- mark
--

--------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting