Re: JAVA and ADA JGNAT

[Robert Dewar <robert_dewar@my-deja.com>]

In article <X_Fj4.425$0o4.13328@cmnws01.we.mediaone.net>,
  Pascal Martin <pascal.martin@iname.com.nospam> wrote:
> No such thing seems to happen to GNAT. I suspect ACT is
protecting its
> business using FUD and obscurity: "if you try to build your
compiler yourself,
> be warned". GNAT is complicated to build, and when you are in
trouble,
> Dewar put the sales hat on. And it is not cheap: the GNAT
trap. Look like
> also they don't want anyone to compete with them.

First, it is quite straightforward to build GNAT, lots of people
do it, the makefiles and procedures are well documented, and
anyone reasonably familiar with GCC can easily do these builds,
and many, many people build GNAT from sources. We don't work
on making this build "simpler", because it's simply not an
issue, I am not quite sure why Pascal Martin has had trouble,
but generally our experience has been that anyone with
reasonable gcc experience has no trouble, so it is not something
that is worth putting work into.

Actually, a lot of the users of the public version of GNAT
use versions not built by us, and that seems fine. We are
happy to cooperate with anyone doing such builds. For example,
ACT cooperates closely with the GNAT/Linux group that builds
RPM's for popular versions of GNU/Linux.

The policy of ACT is the same it has always been, all our
work is placed in the public tree as soon as it is in
releasable shape (we actually will go to more frequent
releases in the next year, as a result of the new contract
with SGI, which calls for quarterly releases -- we will try
to syncrhonize the public releases with these more frequent
GNAT Professional releases).

No company that I know of works by having its internal
development sources and development activity day by day
open, I think that would be chaotic. In particular, it is
quite right that not having access to the ACT test suite
makes it risky to make changes. We certainly never allow
even the most minor of changes to be made without running
the test suite, and this avoids many false steps that would
cause regressions.

It would be nice if there were more activity in contributions
to the public tree, but in practice that does not happen so
much for complex beasts like compilers. If you look at the
gcc changes, a great majority are made by Cygnus or full
time development folks at other companies.

And, despite "belief" sited earlier in this thread, I can
promise you that Cygnus does not work in bazarre mode
internally (anyone really seriously think that the new
Itanium compiler was developed that way? -- you probably
don't even know about it, even though the project has being
going on for quite a while now under non-disclosure -- and
that of course is the point).

Similarly, there are major developments that have not
seen the light of day yet from major Linux companies (and
I think I will use Linux there and not GNU/Linux quite
deliberately :-)

Does this mean that these evil companies are secretly doing
stuff that they should be doing openly? Not at all, it simply
means that these projects are under development, by a well
defined development team, using traditional high quality
software development techniques, but they are not ready for
any kind of distribution yet.

As for public beta tests, I know that this is a common concept
particularly from Microsoft, who even charges hundreds of
thousands of people to be beta testers.

But it's not the way we work for several reasons:

1. We think that beta testers need to be in close contact with
the developers, so that useful input is obtained in a systematic
way. Far too often "public beta" versions are just a way of
getting pre-releases of software that is not really in good
enough shape to release. Hobbyists, magazine reviewers, and
enthusiasts enjoy being able to get their hands on these early
versions, but they don't do much in terms of systematic input.

2. We think it is important that people experimenting with
Ada not find a confusing mess of different versions, many of
which are in some kind of beta stage, or otherwise not suitable
for general release.

3. So far, for the public releases of GNAT, we have been able
to make pretty frequent releases even without wide spread beta
programs, because of the internal field testing procedures that
we use.

Finally, we don't mind at all if other companies get into the
GNAT business. There are lots of gaps to fill in here, so most
likely such companies won't choose to compete in exactly the
same market as ACT, but that's up to them. For example, there
is a company in England that provides support for safety-
critical applications using the ERC32, an environment that
ACT does not support currently. We are working with them to
make sure that their business is successful. Similarly we worked
with Labtek when they were marketing a low cost supported
version of GNAT for NT.

It's certainly much easier to compete with ACT given that
you have our complete sources as a starting point than to
compete with any of the other Ada vendors who continue to
keep their sources highly proprietary!

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.