Re: Future with Ada

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

"Mark Lundquist" <no.spam@getalife.com> wrote in message
news:cVPT7.3856$xl6.637425@rwcrnsc54...
>
> If a foundation library included some of those things, and they were (a)
> optional, and (b) straightforward to implement on both Unix and Windows,
> then I wouldn't lose too much sleep over the other platforms.
>
Are we talking about putting them into the ARM as an annex? Or simply
documenting some kind of pseudo-standard that gets implemented & finds wide
acceptance?

I'd agree that covering Windows and Unix would account for most things.
However, I still think there might be a least-common-denominator problem. It
would probably be better for Ada to have its own kind of GUI engine -
althought that (like anything else) has its own set of problems.


>
> It'd be an important step in the right direction, especially for
> implementers who appreciate the strengths of Ada but are realistic about
the
> state of affairs regarding GUIs and IDEs.  For them, some more beef in the
> "under-the-hood" area might tip the scales in the scenario of
> "backend/engine in Ada, UI in Java" (or UI in VC++ if a different team's
> doing it and that's what they know), or for web development where the UI
is
> one of the web scripting languages.
>
No doubt that adding *any* additional capabilities to Ada makes it more
attractive. However, I have not seen many projects that deliberately go out
and say "Lets use language X for the GUI and language Y for all the guts..."
Sometimes that happens by evolution, but not very often by design. Typically
a project is going to have the view that if it has to use language X to do
the GUI, it might just as well use language X to do everything - especially
since it is common that the GUI is most of the really hard work anyway.

So I think if Ada wants to compete in the markets where people develop apps
that are GUI based, it needs to have a GUI or it won't likely get chosen.
(Oh, yes, certainly. Of course there *will* be exceptions and people can
point to projects where this is the case. I'm suggesting that this will be
the *general* case.)

> Let's not equivocate on the subject under consideration, which is
> libraries... while IDEs are important, and also part of the "total
package"
> along with libraries, we should still observe a separation of concerns
> between them.  So the aim of a library effort would be to make Ada more
> competetive with C++/STL, and also more competetive with Java+JFC modulo
the
> GUI issue (on that score, Ada and C++ are on a par anyway; that is to say,
> you can develop using Claw, Gwindows etc. on Windows and be using the same
> GUI as if you were writing in C++, and if you use Gtk on Linux with C++,
you
> might just as well use GtkAda).
>
In some ways Ada is better off than C++ when it comes to libraries. One of
the things that struck me about the MFC when I first started looking at it
was that you could typically divide things into two categories: A) Stuff
that was constructed to make up for weaknesses in the Win32api and B) Stuff
that was constructed to make up for weaknesses in C++. Most of the stuff in
the B category, Ada wouldn't need.

Still, having better libraries that were "commonly implemented" (rather than
"standard" - since I think that is an overly optimistic goal) would make Ada
more attractive. We could probably describe them as belonging to one of
three classes:

a) Libraries that can be constructed entirely in the Ada language and don't
depend on any particular OS or platform or compiler in any significant way.

b) Libraries that can have a common interface and a common behavior across
implementations, but depend on the back-end being platform specific. (GtkAda
is a good example)

c) Libraries that are designed to provide access to specific capabilities of
a platform or OS. (CLAW is a good example)

Things that fit into category A are obviously the easiest things to get
constructed and distributed. Concentrating on those things would be good,
but I don't think they would in and of themselves be enough to really
promote Ada use where it doesn't already exist. Its things in the B or C
category that languages like Java offer that makes them attractive for
development in domains where Ada doesn't find much acceptance.

Personally, I think that Ada could do well by finding its way into the
Digital TV Set Top Box because its an area that isn't already "owned" by
some other language. Because its relatively new, no one language has any
sort of huge toolset that makes it impossible to replace without a billion
dollars and ten years of development time. Unfortunately, I don't think Ada
will find its way into this domain because most of the guys who know
anything about it and are inclined to build software for it are all pretty
much die-hard C-heads. But it would be a great opportunity....

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/