From: Bob Leif
To Tucker Taft et al.
I believe that the a relevant question is in which market is Ada competing
These two "languages" really have little to do with each other. My question
is how do we get Ada to interact with HTML, XHTML, and ultimately XML? Can
embedded systems, a major need is to simply be able to use HTML forms with
an Ada compiler. HTML including its forms is sufficient for the User
interface for many embedded applications.
My cursory studies of Java indicate one minor advantage over Ada. The Ada
community, because of previous negative reactions to the size of the
language, has had a reluctance to increase the number of reserved words. I
believe that we might consider some synonyms for "New". These could be
borrowed from Java.
The back-up option for Ada is to create XML_Script. This would be a
combination of XML syntax and Ada semantics. I do NOT like the use of
HTML-XML ="argument" for an argument. I much prefer => argument. However, at
least, XML ends its structures. Amusingly, one could probably raise big
bucks on developing this product.
From: Team Ada: Ada Advocacy Issues (83 & 95)
[mailto:[log in to unmask]]On Behalf Of Tucker Taft
Sent: Monday, November 01, 1999 8:57 AM
To: [log in to unmask]
Subject: Re: Java for Real Time? (was Re: Re: you heard it
Ben Brosgol wrote:
> BTW I am perfectly well aware of the large number of omissions from Java
> (such as range constraints on variables, strongly typed scalars, generics,
> operator overloading,...), and I also understand the argument that such
> omissions may make the application programmer's job more complicated and
> thereby lead to less safe programs. So I can argue this issue either way.
> But I have seen some folks from the Ada community dismiss Java as just a
> bunch of hype, and this is a serious delusion.
Perhaps. On the other hand, Java is loaded with ideas that sound
good in theory, but which end up being less than ideal in practice.
Perhaps it is just a question of maturity, or waiting until Java 4.0.
Examples include the supposedly portable GUI aspects of Java, which really
have not worked out very well (most sophisticated Java programs
still only work well on one or two JVM implementations), or the
Just-In-Time compiler technologies, which tend to be buggy and
not that much of a speed improvement, or the switch from file-oriented
textual include to module-oriented "import," sullied by the fact that each
text file may contain only a single public class, resulting in hundreds
of files when a smaller number of conceptual modules would be more
I sense that the effort to push Java into the real-time market is somewhat
trying to force fit a round peg into a square hole. You can succeed
if you push hard enough, but you may not be very happy with the result.
Java will almost inevitably, ultimately, play a role in real-time systems.
But I suspect it will have to be combined with a fair amount of
gorddy C glue to make it all work, and the garbage collector will be
turned off in many cases, with awkward coding conventions adopted
in its stead (e.g. only create objects at class initialization time).
On the other hand, maybe the RT Java groups will produce something
that resolves all of these issues. It will be interesting to see whether
some of the language simplicity ends up resulting in significant library
complexity to achieve effectiveness as a real-time tool.
> Ben Brosgol
> [log in to unmask]
-Tucker Taft [log in to unmask] http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.) Burlington, MA USA