Re: Future with Ada

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:bJsS7.49746$ER5.625524@rwcrnsc52...
>
> 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...
>
True. I could imagine a (semi)standard library that included basic data
structures, various math libraries, text manipulation, possibly interesting
tools for multitasking, etc. Things like that could be done strictly in Ada
syntax and a reference implementation could  be built that the vendors would
perhaps have to adapt for the peculiarities of their compiler.

The problem is that most of the real big leverage items start to become
things that intersect with the OS or machine peculiarities. I could imagine
things like a GUI, file management stuff, networking, etc., all being much
more useful than data structures and math, but then there is some question
about how it could be done in such a way as to be "standard" yet not end up
unimplementable (or simply difficult to implement) on most platforms where
the capabilities exist.

And then its a problem to consider that a handful of dedicated Ada fanatics
aren't likely to be able to produce something that big in a reasonable
timespan and offer the vendors a reference implementation. You'd have to
provide those sorts of things as a "Here's the Unix variant and here's the
Windows variant and here's the Mac variant...." It may not be impossible,
but the bigger the scope gets, the less likelihood it would get done with
volunteers.

So I could see concentrating on the kinds of "under the hood" features you
mention as A Good Start. But would that alone make Ada competitive with
MSVC++ or Java?


>
> 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.
>
Yeah. That's an angle I didn't bring up. I could see that as a potential
solution, but its a dog with different fleas. You'd still have to do some
version of saying "Here's your Unix variant, your Windows variant....." and
it doesn't lend itself to the notion of a reference implementation that the
vendors can just pick up and tweak. It also suffers some from the problem of
having an entirely different look-and-feel than what a native-mode
application might produce. Netscape is a kind of thing like this - it works
fine, but it doesn't look-and-feel quite like a native Windows app. Would
end-users accept having their word processor and spreadsheet look different
from the rest of the OS environment just because they were built from the
Ada Standard GUI Thingamabob? Maybe - it is not clear they would reject it,
since a lot gets done with Netscape.

I mentioned elsewhere the notion that if there were some flavor of an XML
doohickie out there for Ada that it might be possible to use that as the
basis for a portable, standard GUI. So basically, I'm not against the idea -
just that I have some doubts about how easy it would be to get it
incorporated as a "standard" feature and about how it might be met by the
developer & end-user communities.


>
> >
> > So I think there is a problem with getting large libraries of stuff
> > "standardized" in Ada.
>
> For the GUI stuff, you mean?
>
For the GUI stuff - and for other things. Obviously, the less work you
demand of the vendors to incorporate something, the more likely it is to get
in there. Self-contained Ada libraries would be easier to get adopted - but
it is a long way from a shoe-in. Even if you gave the vendors a totally free
shot at a reference implementation and put it in the public domain, they
might be reluctant. Even if its free, they still have to answer telephone
calls about it and make sure it works in their environment. The further away
you get from Ada-only-reference-implementation (do we have a word for
this???) the harder it would be to get it adopted. Unless, of course,
someone with really deep pockets simply paid to have it implemented and
started supplying "The Compiler" (free, naturally :-) that forced everyone
else to play catch-up.


>
> 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.
>
Well, yeah, but I still think you'll discover there is resistance to that
notion. Should some rather large GUI library get incorporated into the
standard as an annex? (Or some other library of sufficient complexity and
not a Native-Ada-Reference-Implementation) I think you'll find resistance to
that because of the difficulty of writing up the annex in a rigorous enough
way that it can be tested for conformance.

Better to shoot for something that is more of a de facto standard because
most compilers have it available with possibly some variance in quality,
behavior or completeness.

>
> For foundational stuff (like collections), I think a de-facto standard
would
> be OK only if it were perceived as "standards track".
>
I'd settle for most vendors supplying it and skip actually getting it into
the ARM. As I said above, this could be difficult.


> 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.
>
Yup. And look at things like MSVC++ and Java to see what the competition has
available. That's what Ada would be measured against. And the problem is
there is a lot more in those implementations than simply things that could
come from Ada-Only code - especially if it is developed by volunteer effort.


>
> Exactly.  "Great environment to be had for the cobbling" just doesn't cut
> it.
>
You need to get it as a fully integrated kit so that its just "there" to be
used. If it were (semi)standard, that makes it so much the better so that
books can be written about it, training can be found for it, and developers
can move from one project to the next and not be stuck relearning a whole
new set of cobbled-together tools. (Either that, or the Deep Pockets answer
would have the same effect.)


> 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.
>
Agreed - but as I said above, there are problems with getting something like
this into the ARM and even if its free, the vendors may still not adopt it
for a variety of reasons.


> > 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.
>
It is A Good Start and might help to make Ada a more attractive language to
many users. But it is still a long way from creating competition for things
like Java.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/